Who can do what, which devices they can see, and how to put a second factor in front of the login.
Every user has exactly one role. It decides what they may do; the site scope in the next section decides which devices they may do it to. The two are independent, and both apply.
| Role | What it can do |
|---|---|
| superadmin | Passes every permission check and always sees the whole fleet — a site scope cannot be applied to it. Some actions are reserved for this role alone, including resetting another user's two-factor authentication or passkeys. The account created on first install has this role. |
| admin | Manages devices, sites, users, backups, upgrades and settings. Can be scoped to specific sites, and additionally sees devices that belong to no site. |
| operator | Day-to-day work on devices: commands, upgrades, backups, configuration changes. No user management, no settings. |
| viewer | Read-only. Sees status, interfaces, logs and history, and changes nothing. |
Pick the lowest role that lets someone do their job. An operator who needs to read one setting is still an operator; the fix is not to promote them.
A user is either unrestricted — the whole fleet — or scoped to an explicit list of sites. There is no in-between, and the distinction matters more than it looks:
Devices that belong to no site are a separate case: they are visible only to superadmin and admin. An operator or viewer will not see them however their scope is set, which is a good reason to put every device in a site.
Access is granted from the site, not from the user. Open Sites, edit a site, and use User access to tick the users who may see its devices.
TOTP adds a six-digit code from an authenticator app — Google Authenticator, Authy, 1Password, Microsoft Authenticator or any other — to the sign-in.
Each user turns it on for themselves under Settings → Two-factor auth. The setup shows a QR code and the secret in text, for apps that cannot scan.
When you enable it you are shown eight backup codes, once. Each is single-use and they are stored hashed, so nobody — including a superadmin — can read them back to you later. Save them somewhere that is not the laptop you sign in from. You can regenerate the set at any time from the same screen, which invalidates the previous one.
A passkey — WebAuthn or FIDO2: an Apple or Google passkey, a YubiKey, Windows Hello — can be used as the second factor instead of typing a TOTP code. Register one under Settings → Passkeys.
There is a hard requirement worth knowing before you try: passkeys need a registrable domain over HTTPS. The WebAuthn specification forbids an IP address as the relying-party identity, so an installation reached as https://10.0.0.5 cannot offer them no matter how the certificate is set up. The interface says so rather than failing obscurely. A reverse proxy with a real hostname and a certificate — Let's Encrypt, or a dynamic-DNS name — is what makes the option appear.
Registering or removing a passkey signs you out, by design: the next sign-in proves the change took effect.
A user who has lost both their authenticator and their backup codes cannot recover on their own. A superadmin resets them from Users:
Both actions are recorded in the activity log. If the locked-out account is the only superadmin, there is no in-app path back — which is the argument for having a second superadmin account, and for keeping its backup codes somewhere separate.
Machine access does not use a user's password. Issue a key under Settings → API keys; a key carries its own role and its own site scope, resolved by the same rules as a user's. A monitoring integration should get a viewer key and nothing more — that is exactly what the Zabbix template asks for.
The manager can answer questions from an AI assistant directly, without anything installed alongside it. Turn on Settings → MCP endpoint and point the assistant at /mcp with one of your API keys. Until you turn it on, that path does not exist as far as any caller is concerned — it answers 404 whether or not they present a valid key.
What an assistant can ask for is a fixed list of ten questions, not the API. The manager has around ninety read endpoints; mirroring them one to one would leave an assistant choosing between near-identical tools instead of answering. Each of these is shaped around something a person actually asks, and each answers in plain text or a small table rather than raw JSON.
| Tool | Answers |
|---|---|
mikr_issues | Everything flagged right now, in one reply: devices not reporting, RouterOS and firmware behind their channel, PoE budgets over 80%, devices where the manager only has a read-only RouterOS account, CVEs matching installed versions, backup problems. The one to start a morning with. |
mikr_fleet | The overview: how many devices, the breakdown per site, the spread of RouterOS versions and models, and who is not reporting. |
mikr_device | One device in detail — model, versions, uptime, CPU, memory, temperature, PoE draw against its budget. It can also pull ports, discovered neighbours, routes, DHCP leases or wireless clients live from the device; each of those costs a round trip to the hardware, so they are asked for explicitly. |
mikr_search | Find a device by name, IP, RouterOS identity, model, board, version, tag or note. Answered from the manager's own database, so it is instant and touches nothing. |
mikr_upgrades | Who is behind, what they run, what is available, and the latest release per channel. It reports stored poll results: it does not make devices re-check, and it cannot start an upgrade. |
mikr_backups | Backup coverage: healthy, never backed up, overdue against their schedule, unscheduled, or whose most recent backup was truncated. |
mikr_cve | Known RouterOS CVEs matched against the versions actually installed, with the affected devices named. Filterable by severity. |
mikr_metrics | Recorded history of one metric on one device — CPU, memory, temperature and the rest of the health sensors — over 1h to 30d. Without a metric named, it lists which ones have samples. |
mikr_syslog | Search the syslog the manager has collected, newest first, filtered by device, text, topic or maximum severity. |
mikr_topology | Discovered neighbour links with the ports they land on. Links are held per site, so ask for a site; the fleet-wide call lists nodes only. |
Devices are addressed the way you would say them out loud — by name, by RouterOS identity, or by IP. There is no internal id to look up first.
It reads and never writes. There is no tool for upgrading, rebooting, running a command or changing a setting, and the module behind the endpoint has no code path that sends anything but a read request. An assistant that decides a device should be rebooted can tell you so; it cannot do it.
The key decides the rest. Everything the tools read passes through the same checks a browser session goes through, so an assistant using a viewer key scoped to one site sees that site, as a viewer — the same page a person with that key would get. Issue the key you would be comfortable handing to whoever operates the assistant, and revoke it in the same place.
Configuration differs per assistant, but they all want the same two things: the URL https://your-manager:3000/mcp and a header X-API-Key: mikr_…. The transport is HTTP; there is no separate port and nothing to install on the server.