Using AI to help configuring RouterOS and scripting

Hey @anav, this is a mcp package which you need to load it in your AI, for example if you are using Claude AI, you need to download the Claude Desktop and follow this documentation and also the README of the Mikrotik-Mcp to understand how to use this.

If you are using any other AI or LLM, I belive they also should support MCP, just search **“How to add mcp to my ${LLM Name}“.

What is the process?** Once you add the Mikrotk-MCP to your AI(rather it’s claude or etc), you would be able to talk with your AI to configure your Mikrotik device, you can find a video at README, where I’m using Claude AI to configure my Mikrotik device.

How it will help? Well this is very depend, the world of mcp-servers are growing every day, enabling AI and LLMs to connect and integrate with anything in the real life and development life cycle. Imagine MCP as a Hands which enable AI to do stuff rather then just providing information for you or answering your questions

Hey @Amm0, thanks for your feedback.

1. Compiling Python into EXE:

Actually, an MCP page will usually integrate with AI using a JSON file (like claude_desktop_config.json in Claude Desktop), so you can integrate it with your AI by creating a sample JSON file like this:

{
  "mcpServers": {
    "mikrotik-mcp-server": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e", "MIKROTIK_HOST=192.168.88.1",
        "-e", "MIKROTIK_USERNAME=sshuser",
        "-e", "MIKROTIK_PASSWORD=your_password",
        "-e", "MIKROTIK_PORT=22",
        "mikrotik-mcp"
      ]
    }
  }
}

Please check the README to see how you can integrate it with your desktop AI.

2. The results so far:

Here you can find lots of examples of how you can use AI to change your network configuration in your MikroTik. However, lots of tools and functions are NOT SUPPORTED in the mikrotik-mcp yet, but I believe the community will grow and we will support more tools from MikroTik.

Your high-level thought is right, especially with new LLMs like Claude 4.5 Sonnet, AI is doing pretty well in almost all areas. The mikrotik-mcp only provides a way for AI to apply (with user permission) configuration to the MikroTik.

Regarding your feedback about "mapping RouterOS's CLI/API directly into MCP tools may not offer much but IDK" actually, mikrotik-mcp is using SSH connection to the MikroTik, and each tool is separated into different areas. Please check here.

For example, for DNS settings in MikroTik, here is the implementation for the mikrotik-mcp you can find in dns.py. As you can see, we are running direct commands and not only communicating with APIs. So the more tools you add to the folder scope, the more features and capabilities AI will have to integrate with your MikroTik network configuration.

Your assumption is correct, currently we are not covering all of the features, tools, and areas in MikroTik. You may ask your AI to perform a request that needs not only DNS or firewall areas, but also another area which is not supported (YET) in the mikrotik-mcp*. That's why I would like to encourage the community to participate and create issues [here], so the existing developers at mikrotik-mcp, like me, can follow up on the issues and create valid PRs to improve the mikrotik-mcp.*

By combining network engineers' knowledge from this community (by creating issues) and developers (by implementing and addressing the issues), I think we can eventually set up an AI Agent for managing MikroTik devices.

I really believe that soon we will need to enhance AI Agents with MCP to handle any engineering tasks. In the networking area, I believe MikroTik has a lot to offer, so it's good to have its MCP ready for future AI agents!

Hello

I suggest that you read here https://www.kctech.dk/notes/mactelnet and maybe here https://www.kctech.dk/method/the-self-evolving-engineering-system

This is my daily life running a large wisp

Hey @KimC, thanks for sharing the links! just to let the community know, I also steup a landing page with documentation of mikrotik mcp so I belive it would be much easier to figure out the exisitng tool coverage and how to work with mikrotik mcp and use AI to configure RouterOS

https://www.mikrotik-mcp.com/

Picking up the thread on why LLMs struggle with RouterOS — and what actually helps — I've spent the last while turning the hand-waving into measurements. It's all open at tikoci/bench-routeros-tools, a small benchmark that compares six ways of helping an agent: a bare model, curated skills, a docs-retrieval layer, an MCP "do everything" server, and combinations. Same prompts, same scoring, run against a live CHR so the numbers reflect what a router actually accepts, not what looks plausible. The write-ups are in the REPORT and the forward-looking AGENTIC_FUTURES if you want to poke holes in the methodology.

A few things fell out that are directly relevant to what @Larsa and others raised above:

  • /console/inspect is necessary but not sufficient. The thread's instinct to validate generated config before showing it is exactly right — but inspect is a static gate. Our sharpest example: /ip route add dst-address=… blackhole (a bare flag) is the device-valid form, yet /console/inspect happily accepts the invalid blackhole=yes, and type=blackhole is a pure hallucination that 30 of 36 model runs produced. Only live device execution catches that gap. So you really want two gates: parse/inspect and a dry run on hardware. (My hope is that the new manual.mikrotik.com grows a proper CLI reference with more data than /console/inspect exposes — enums, value constraints, deprecations — which would close a lot of this on the static side.)

  • This isn't a weak-model problem you can scale away. We ran the same trap up a ladder from small models to the current frontier. The best model still scored 0/9 on it. A grounding/validate→run layer is a permanent correctness floor, not a crutch for cheap models.

  • More tools is not more help. This is the gentle part re: the mikrotik-mcp server that's been recommended around here — it's a genuinely useful project and the only one of the six that can execute. But measured honestly, its ~166 SSH-backed tools cost roughly 28K tokens of always-on context, create real tool-selection ambiguity, and ship ~27 destructive operations with no dry-run. By contrast, a read-only docs layer buys most of the planning accuracy for a fraction of the context. The data points away from "stack one giant executor" and toward an explain → validate → run split.

That split is what the TIKOCI projects are built around, and it's all public:

  • rosetta — RouterOS docs (pages, properties, the command tree, device specs, changelogs) as a SQLite/FTS RAG exposed over MCP. This is the cheap, read-only "explain/plan" layer.

  • routeros-skills — curated, grounded skills (firewall, scripting, containers, netinstall, …) usable from Claude Code or Copilot. That includes a MAC-Telnet skill, which grew out of the wire-format work a few of us did upthread — so an agent can reach a device by MAC on L2 with no IP yet.

  • quickchr — CLI + library to download, launch and manage CHR VMs under QEMU. This is what makes the "dry-run on hardware" step cheap: spin a throwaway 7.x router, validate against it, throw it away.

  • centrs — the in-progress scoped-verb MCP that realizes the recommendation: a handful of verbs (explain, validate, retrieve, execute) over a canonicalize→validate→run core, with validate running both :parse and /console/inspect, and execution gated per-device read-only/read-write. It's the deliberate alternative to a 166-tool firehose — and MAC-Telnet is being folded in as one of its transports, so the same scoped verbs work whether the box is reachable by API or only by MAC.

None of this replaces MikroTik publishing a formal grammar — that would help everyone, and I'm still firmly in that camp. But you don't have to wait for it to get reliable agent help today: ground the model in real docs, validate against the command tree, and dry-run on a CHR before anything touches a production box. Happy to share the full report and methodology with anyone who wants to dig in.

Drafted and final reviewed by me, edited by Opus 4.8

I just saw this thread and wanted to briefly share my experience here:

I built my entire network and MikroTik setup using an AI assistant. I can highly recommend this to anyone who doesn't know how to code or isn't particularly technically savvy.

The only important thing—just as in any conversation with an expert—is to provide all the necessary information and context about the hardware and used end devices.

When debugging, you can simply enter error messages and code, and approach a problem piece by piece—at times in ways never seen before. That is impressive.

I have had good experiences with AI and MikroTik products. My approach was to use AI to understand how things can be configured. I never blindly generated configuration by AI.

Here are a couple of things that I noticed along the way:

  • ChatGPT 5.4 was generally better at diagnosing things. That is, going through log output and configuration snippets to find out what is actually going wrong. It is very helpful because at every stage you can ask specific questions about how something should be working (i.e. OSPF if you're not familiar). You can also do things like capture packets and export them in text form with Wireshark and let AI explain that to you in detail. That is very helpful if you know the concepts but not the implementation details to the last detail.
  • Claude seems to be the better programmer
  • Your chats to diagnose problems will become so unwieldingly large that they will be incomprehensible at a later time. You need to make sure that AI explains its plan and uses small steps. Otherwise you'll loose focus easily. For example: "help me diagnose xyz. Provide a short plan how we're going to approach this. Use small steps (i.e. ask only one thing at time) so that I can answer more easily"
  • It is difficult to distinguish between RouterOS 6 and 7 for AI. But that is nothing compared to that mess that you get into when you every try that with Cisco products
  • AI does not have a clear understanding how IPSEC works on RouterOS, especially how policy templates come into play if you have multiple dynamic end points. It does not really grasp that MikroTik currently does not support VTI. I believe that if the IPSEC chapter in the documentation was more fleshed out and offered more context, there would be a lot better support by future models
  • I was surprised how good the programming results were (though none were perfect) and how bad RouterOS scripting is at giving good error messages with precise locations
  • I was amazed at how easily it deducts your network topology from small snippets, log outputs, ... and that it can provide proper answers that fit your scenario well
  • It is absolutely annoying how certain it feels about its answers when in fact it has no clue.
  • Diagnosing problems gets tricky very fast. Suppose you're using a zone based firewall with a couple of vlans and there comes the time to provide firewall rules to AI. It is hard to create minimal samples that can be used for diagnosis but that do not offer a lot of unnecessary information.

I would imagine that better and more comprehensive documentation will improve that experience a lot.

@robmaltsystems

Grok 4.x is very good with RouterOS scripting ... The Musk org have quite a few Tik devices which is why - however the directives it produces must be closely inspected because it does have some issues especially when the info you provide it is lacking in accuracy or is vague.

Microsoft copilot is also very good with Tik scripting if and when the detail provided is comprehensive an accurate. The better one defines ones requirements the superior will be the result.

Garbage in equals garbage out ...

MY OPINION: Within the next 5 years or less the IT industry will be dominated by AI replacing 80% to 90% of human resources.

:rofl:

Great input on your AI experience infabo! NOT

My experience thus far is that none of them are better than rextended yet. :slight_smile:
With reasonable input (as mozerd noted is a basic requirement), I can get three different answers and the others will state the other two are wrong.

Claiming Grok is better at ROS scripting because "Musk has some Tik devices" is close to AI hallucination. If you want to improve your AI output quality, better stay at facts -> Using AI to help configuring RouterOS and scripting - #65 by Amm0

@anav

Have you tried Grok 4.x ? Currently it’s free but will cost when it hits v 5 …

Have you tried Copilot ? … it’s free so far

Both are far superior to rextended … but msatter still is the very best :grinning_face:

It seems to me not an allucination, I think that it was valid on v6.x, i.e.:
v6.x -> add distance=2 dst-address=10.1.1.0/24 type=blackhole
v7.x ->add blackhole distance=2 dst-address=10.1.1.0/24

:woozy_face:

Please leave me out of these moron kids games.

Also, to make a comparison:

  1. On what?
  2. Who judges?
  3. A three must always be given for Artificial Deficiencies.

That's the case with most AI programming responses. Older experienced programmers often produce better results than the inexperienced programmer as we know whether it's produced garbage. Which is a bit of a problem for society going forward but that's a different debate.

I gave up on free Grok because it was always saying the service was busy. I'm guessing that was a way to make you pay. I'm using Copilot with my Microsoft 365 subscription - that's still limited but seems okay so far.

Reminder to self, do not wax eloquently about rextendeds scripting acumen, in fact he's probably just average.

FYI (for those who are mentioning Copilot), Copilot is not AI model, it's a service which wraps different AI models depending on prompt if is in Auto mode or it uses specific model supported by service (Claude, Gemini, GPT models...) that can be set explicitly depending on subscription, similarly to Perplexity for eg.

Yes, you are correct ... thank you for pointing out what Copilot is ...

True. All my tools assume v7. LLM already seem to favor V6 without extra tools, likely since there must be more training data v6. But given v6 is essentially deprecated (or at least not "forward looking") and it's V7-specific stuff it gets wrong more often (although I have no done much testing on v6). But I should have noted the v7-only implicit assumption in post ( rosetta/routeros-skills/centrs all inform agents "v7 only"...so commentary may be a bit harsh on "backhole".

Point being there are dozens (maybe more) concepts that LLMs do often get wrong. And, a lot it does get right... And why having some benchmark tests helps. I could have come up with more problematic things, like commands that need once/duration, etc etc. Since my tests include high end models use credits, and I was more interested in coming up with working semi-generic "agent benchmarking framework" first. Which does essentially two phase, "static" which gathers stats on token usage (since bloated context) and actual "live prompts" against various agent with specific combos MCPs/skills/etc loaded.

I'll expand the "gold" live prompt in benchmarks on more of the tricky things over time. I've been working on my WIP tikoci/centrs tool which is both an usable CLI and MCP server whose designed is based on some of found limitations of LLMs, and also humans. I'll explain my Centrs CLI/MCP concept in more detail once it's a more tested/validated state, but it offers:

  • validated before running command e.g. commands are checked against :parse and /console/inspect data before being actually run, so invalid commands prevented and agents can reason able why and "try again" to get it right
  • devices and credentials based WinBox CDB - this is a bit novel but the centrs MCP/CLI points to some CDB file (by default a new one in ~/.config/ but theoretically ENV/args could point the "real" CDB file from WinBox) using key-values stored as CDB "comments" to store non-default ports, RO/RW access from CLI/MCP, etc. MCP authentication is handled by provided it path to a CDB file to use, so LLM access is gated by what's in the CDB file (with option in comments for "read-only").
  • works on "groups" of routers too - since CDB supports groups, centrs can operate a group defined in CDB via MCP or CLI. e.g. instead of MAC/IP/identity, a group from CDB file can be used like centrs retrieve <group-name-in-CDB-file> /ip/route that get the routing table for all routers in that group in one command.
  • multi-protocol: REST, ssh, native API, MAC-telent - centrs does not just wrap REST API, rather also knows all* of them, even SNMP can be used with args (and CDB storing non-standard ports and creds). *WinBox terminal protocol might be possible at some point, since there the "M2"/"nova" structure is already known but not a high priority Anyway more to come on centrs as MCP, which in part was guided by benchmarks above and a lot of other less-structured tests/experiments.

100% correct - it runs the model you select. And since it's $10/$40 subscription offers most anthropic/openai/google models (at different rates) and full integrated into GitHub, its kinda convenient. So the GPT tests in my benchmark came from CoPilot. But the Claude results used "real" Claude Code (claude -c) [even though the same models are in CoPilot, the harness does add "color" since CoPilot has different system prompt than Claude Code even though model is same].

CoPilot was a great deal, until today. Up to now, copilot charge per-prompt which is a bad deal if you ask "how ya doing", but if agent runs for hour(s), that also counted as "one request" so it could be dozens or even hundreds of dollars at retail SDK rates for a single "request". On June 1, CoPilot now uses "AI credits" which are based on model/tokens now, which FAR less generous... so IMO Claude Code subscription (which also get you way more usage than SDK retail rates for the raw model) may be better deal (now).