API coverage
MikroTik MCP does not cover every RouterOS command yet, and it does not pretend to. The API coverage checklist compares the tools with the official RouterOS manual, command by command, so you can see what is covered and what is still planned.
Where to find it
The checklist lives in the project repository, and the manual it is measured against is MikroTik's own.
What the checklist shows
- Commands, grouped by area. The RouterOS menus the project covers, such as interfaces,
IP, IPv6, queues, users, system, files and routing, each with the commands the manual lists for it
(
add,print,set,removeand so on). Menus that are deliberately left out are listed too, under out of scope. - The tools behind each command. An implemented command names the MCP tools that cover it.
For example,
printon/interface/vlanmaps tolist_vlan_interfacesandget_vlan_interface. - A status for each command. Every command is in exactly one of these states:
| Status | Meaning |
|---|---|
implemented | A tool exists and maps to the command. |
partial | A tool exists, but some of the behaviour it advertises is missing. |
planned | In scope, but there is no tool yet. |
legacy | A tool exists only for the older RouterOS v6 path. |
not applicable | The command does not exist on RouterOS 7. |
How to read it
- A checked box means a tool exists and its declared parameters map to the manual. It does not prove the command works on every RouterOS version.
- The progress figure at the top counts commands, not tools, and only for the menus the project has declared. Menus outside that scope are not part of the total.
- Legacy RouterOS v6 commands count as not implemented, because MikroTik MCP targets RouterOS 7.
- The version of the manual the checklist was compared against, and when that manual was built, are recorded at the top.
How it stays accurate
The checklist is generated, never edited by hand. A validator in the repository checks that every tool the server registers is declared in the coverage manifest, and that every declared tool really exists. A separate workflow, started by a maintainer, compares the manifest with a pinned snapshot of the manual and reports drift, such as new menus or arguments, for review.