Nice work. Few thoughts.
You might consider streamlining the packaging. Perhaps, you can compile the python into an EXE to make it more readily consumable. i.e. I think you'll lose @anav at docker and/or python+venv step.
In terms of the operations offered by your MCP, I'd be curious at your results so far? My high-level thought is an LLM isn't too bad at syntax... so mapping RouterOS's CLI/API directly into MCP tools may not offer much but IDK.
One tool you could add is some validate_syntax tool that use the /console/inspect request=completion input=<LLM_CMD_OUTPUT> which could be used check the results are valid syntax for the connected routed. This is what my LSP uses to check syntax. So in terms of an MCP, some some prompting to check its output against the a validate_syntax MCP tool might do much of the work your broken up mikrotik_get_vlan_interface etc etc., since LLM like can guess /interface/vlan/get without help.
It's the more complex cases, that may be a simple prompt that I worry about. For example, "I'm starting with a defconf, and want to add VLAN for guests, and make a ether5 trunk port for an AP". The MCP ideally know you need vlan-filtering=yes and all the various other parts of actually creating a vlan - beyond just adding /interface/vlan/add. And ideally the LLM be given the current configuration, and perhaps other print output from neighbors, DHCP leases, etc. Perhaps even loading the relevant doc pages and/or product specs so their in the current LLM window.
So I guess my 10,000 view - without much test however - is that an I think an LLM could be improved is by offering more context, than necessarily mapping CLI on a one-to-one basis. But IDK.