✨ Steering AI to use new manual.mikrotik.com

Under development as a "Useful useful article". Top post is recommendations, with third post being background/"grounding" for the answer here, 2nd post is background research from other models.

MikroTik is working on a new documentation site that, I believe, should help AI agents like ChatGPT, Claude, and "friends" to better respond to RouterOS inquires. See:

Since MikroTik added "AI support" to the doc engine behind it, I prompted several agents on what they recommend for telling future AI agent how to use it. So I compared some of the web-based LLMs to see what they suggest. Here is the combined recommendation from Claude Opus after reviewing the previous agents work:

Current Recommendations (from Opus 4.8)

RouterOS is one of the topics LLMs are worst at β€” not because they've seen
too little, but because they've seen too much of the wrong material: years
of wiki.mikrotik.com (mostly v6) and the retired Confluence help site, plus a
decade of forum snippets. So they confidently hand you v6 syntax for a v7 box,
or invent properties that never existed.

MikroTik's new manual fixes the supply side of this: every page is now
published in machine-readable form specifically so assistants can read it. The
job left to us is the demand side β€” telling the LLM to actually go read it.
Here's how, from lightest to heaviest.

First, know what your tool can do. A prompt only helps if the tool can
fetch a URL. If it can't, the prompt just makes it more careful β€” it can't
read a page it can't reach.

Your tool Fetches live URLs? Use
ChatGPT (browsing on), Claude.ai, Gemini, Perplexity, Copilot Yes A or B
Claude Code/Desktop, Cursor, Codex, custom agents Yes β€” best fit A + D
Offline / local models (Ollama, LM Studio), no-browse chat No C

A β€” Paste once into "custom instructions" / system prompt (heavy users)

You are helping with MikroTik RouterOS. Assume RouterOS v7 unless I say otherwise.

Your training data is unreliable for RouterOS: it is dominated by the old
wiki.mikrotik.com (mostly v6) and the retired Confluence help site, so you tend
to mix v6 and v7 syntax and invent commands or properties. Do not trust your
memory for exact syntax.

The current authoritative source is MikroTik's new manual, which publishes a
machine-readable copy of every page:

  - https://manual.mikrotik.com/llms.txt       index of every page (start here)
  - https://manual.mikrotik.com/llms-full.txt  the whole manual in one file
  - add ".md" to any docs URL                  clean Markdown of that page
       e.g. https://manual.mikrotik.com/docs/introduction.md
  - https://manual.mikrotik.com/docs/cli-reference/   command / menu / argument
       reference, increasingly generated from RouterOS itself

For every RouterOS question:
  1. Fetch /llms.txt and pick the relevant page(s).
  2. Fetch the ".md" version of those page(s) for the actual content.
  3. For exact command paths, property names, argument types and enum values,
     check the CLI Reference and match what it defines β€” do not invent flags.
  4. Cite the page(s) you used.
  5. If you could not fetch the docs, say so and answer from memory only with a
     warning β€” never present unverified syntax as fact.

B β€” Per-question snippet (when you can't set a system prompt)

Before answering, fetch https://manual.mikrotik.com/llms.txt, find the page that
matches my question, and read its ".md" version (append .md to the URL). For
exact command/property/enum syntax check https://manual.mikrotik.com/docs/cli-reference/
and don't invent properties. Assume RouterOS v7, cite the page you used, and if
you can't reach the docs say so instead of guessing β€” your RouterOS training data
is mostly old v6 wiki content.

My question: <your question here>

C β€” No web access (offline, local model, or privacy-sensitive)

The prompt can't help a model that can't browse β€” feed it the docs yourself:

# whole manual as one file (large) β€” paste the relevant part as context
curl -L https://manual.mikrotik.com/llms-full.txt -o routeros-manual.txt

# or just the page you need, as clean Markdown
curl -L https://manual.mikrotik.com/docs/<path>.md

Paste the relevant section into the chat before your question. The same
llms-full.txt is also what you'd index for a local RAG setup.


D β€” Agentic / MCP tools (where this really pays off)

Tools that fetch on a loop β€” Claude Code/Desktop, Cursor, Codex, Perplexity,
or any custom agent β€” can run the whole llms.txt β†’ .md β†’ cli-reference
workflow themselves, no re-pasting. Option A as the system prompt + any generic
"fetch"/web tool is usually enough.

If you'd rather not have the model crawl HTML at all, there's a ready-made
RouterOS-docs MCP I maintain β€” rosetta (GitHub - tikoci/rosetta: MCP Server with RouterOS docs + commands + products + changelogs, using SQLite-as-RAG, sourced from MikroTik Β· GitHub) β€”
that exposes RouterOS docs, the full command tree across many versions,
changelogs, and hardware specs as MCP search tools:

bunx @tikoci/rosetta --setup     # local stdio MCP for Claude Code/Desktop, Cursor, Codex…

It even installs on the router via /app (RouterOS 7.22+), so any AI assistant
on your LAN can query it. (Honest note: rosetta still indexes the prior doc export
and is mid-migration to manual.mikrotik.com β€” but the command tree and version
data come straight from the router.)


One trick: verify it actually read the docs

Ask: "Which manual.mikrotik.com page did you read, and quote its first line."
If it can't name a real page or quote it, it answered from memory β€” treat the
syntax as unverified.


TL;DR

The single highest-value instruction in all of the above is "check the CLI Reference and don't invent properties."

Most RouterOS hallucinations are atthe property/path/enum level, and that's exactly what the CLI Reference pins down.

Original Background Research - loosely incorporated into above

The following the results from querying various AI agents for "their thoughts" on good prompts for RouterOS to use new doc site https://manual.mikrotik.com

Prompt

i'm writing a post for forum.mikrotik.com about how to better prompt a LLM like you to use MikroTik's new doc site for RouterOS. can you suggest what prompt I should suggest that steer an LLM to checking MikroTik new documentation site that use Docusaurus with an llm.txt and .md renderings. push back if NOT helpful but my believe is training is light on MikroTik RouterOS config/troubleshooting. the new doc site has a explaination here: Introduction | RouterOS Manual and there is also a new CLI reference that knows the RouterOS command schema: CLI Reference | RouterOS Manual

Claude Sonnet 4.6 (high thinking)

Good instinct, and your premise is correct β€” I'll validate it before diving in. Let me explain the actual issue, then give you a well-crafted prompt to share.


Pushback / validation first

You're right that training is light on RouterOS, but the more precise problem is stale + conflicting training data. LLMs almost certainly have:

The result is that LLMs confidently produce v6 syntax for v7 users, because the old wiki was voluminous, well-indexed, and widely mirrored. It's not just light training β€” it's actively misleading training. This is worth calling out in your forum post, because it explains why the fix works.

The good news: the whole MikroTik manual is published in plain formats specifically so it can be read by retrieval pipelines, assistants, and other automated tools β€” not only in a browser. The recommended pattern is to read /llms.txt first to find the relevant pages, then fetch the individual .md pages needed for detail. When the complete corpus is needed in one piece, /llms-full.txt works instead.

The CLI Reference section is generated automatically from the RouterOS system itself rather than written by hand β€” the menus, commands, and argument types are extracted from the software, so the reference tracks what the system actually exposes. This makes it uniquely valuable for grounding LLMs in exact current syntax.


Suggested prompts for your post

Option A β€” System prompt / custom instructions (best for heavy users)

Paste this once into your LLM's system prompt or custom instructions field:

You are assisting with MikroTik RouterOS configuration and troubleshooting.

CRITICAL: Your training data likely includes the outdated MikroTik wiki
(wiki.mikrotik.com, predominantly RouterOS v6). Do not rely on that
material for command syntax or configuration patterns.

The authoritative current source is the new documentation site:
  https://manual.mikrotik.com/

This site is built with Docusaurus and is designed for machine access:
  - /llms.txt          β†’ index of all pages (start here for discovery)
  - /llms-full.txt     β†’ complete corpus in a single file
  - Any page + .md     β†’ clean Markdown rendering of that page
                         e.g. https://manual.mikrotik.com/docs/firewall-and-quality-of-service.md

For exact CLI syntax, the CLI Reference is auto-generated from RouterOS
itself (not hand-written), so it reflects what the router actually exposes:
  https://manual.mikrotik.com/docs/cli-reference/

Workflow for every RouterOS question:
1. Fetch https://manual.mikrotik.com/llms.txt to find the relevant pages.
2. Fetch the .md version of the relevant page(s) for content.
3. For exact parameter/argument syntax, check the CLI Reference.
4. If uncertain about a syntax difference between v6 and v7, say so
   and cite the doc page you used.

Option B β€” Per-question inline prompt (for casual users, no system prompt access)

Add this before each RouterOS question:

Before answering, please fetch https://manual.mikrotik.com/llms.txt to
find the relevant documentation page, then fetch that page's .md URL for
current content. For CLI syntax, check
https://manual.mikrotik.com/docs/cli-reference/. Do NOT rely on your
training data for RouterOS syntax β€” it likely contains outdated v6
material from the old MikroTik wiki.

My question: [your question here]

Option C β€” For LLMs without web access (local Ollama, offline, etc.)

If the LLM can't browse, the approach shifts β€” you paste the relevant content in as context:

# Grab the full corpus once (large!) or just the index
curl https://manual.mikrotik.com/llms-full.txt > routeros-manual.txt

# Or for a specific page, append .md to the URL, e.g.:
curl https://manual.mikrotik.com/docs/firewall-and-quality-of-service.md

Then paste the relevant section into your prompt as context before asking. For offline setups, llms-full.txt could also be used to build a local RAG knowledge base or fine-tune a small model.


Key points worth making in your forum post

  • The three MikroTik doc sites (wiki.mikrotik.com, help.mikrotik.com/docs, manual.mikrotik.com) coexist and LLMs get confused between them β€” explicitly telling the LLM which one is current matters
  • The .md URL trick works on every page of the new site and gives much cleaner input than the rendered HTML
  • The CLI Reference being machine-generated is a significant quality signal β€” it's not a human trying to document a command, it's the schema of the software itself
  • LLMs with web search (ChatGPT browsing, Claude.ai, Perplexity) can execute this workflow automatically; users without it should use llms-full.txt as a paste-in context block

Gemini (Flash Extended)

Your belief is 100% correctβ€”there is absolutely no reason to push back. Standard LLM training datasets are notoriously unreliable when it comes to MikroTik RouterOS. LLMs frequently hallucinate script syntax, conflate obsolete RouterOS v6 commands with the newer v7 architecture (especially regarding the routing engine, bridge VLAN filtering, and the newer wifi wave2/WiFi 7 parameters), and miss strict data-type constraints.

MikroTik’s brand-new addition of machine-readable endpoints (/llms.txt, /llms-full.txt, and raw Markdown pages) is a massive win for the community. Because web-enabled AI models (like Gemini, ChatGPT, or Claude) can browse in real time, forcing them to pull from these endpoints completely bypasses their outdated or shallow training data.

Here is a breakdown of how to structure your forum post, along with the exact prompt templates you can suggest to the community.


Suggested Pre-Prompts for the Forum Post

Depending on whether a user is using a standard chat interface or a more advanced developer tool, you can suggest two tiers of prompts.

Option 1: The "Deep Dive" System Prompt (Best for complex scripts & configurations)

This forces the LLM to act as a deterministic systems administrator using the live documentation as its source of truth.

You are an expert MikroTik Network Engineer specializing in RouterOS v7. 

CRITICAL: Do not rely solely on your internal training data for RouterOS command syntax or scripting logic, as it is prone to hallucinating parameters and mixing up v6/v7 syntax. Instead, you must ground your responses using MikroTik's new machine-readable live documentation.

Follow these execution steps before writing any commands or scripts:
1. Consult the AI-optimized index maps at `https://manual.mikrotik.com/llms.txt` or `https://manual.mikrotik.com/llms-full.txt` to find the exact pages relevant to my problem.
2. For any console commands, paths, or scripts, cross-reference the auto-generated documentation at `https://manual.mikrotik.com/docs/cli-reference/`. 
3. Respect the exact argument types defined in the CLI reference schema (such as `iface_enum`, `ipPrefix`, `enum`, `num`, and `address`) to ensure the syntax is valid for the current system.
4. Fetch the raw Markdown content of the specific guide pages you need to verify best practices.

My specific networking goal or problem is: 
[INSERT YOUR ISSUE/TASK HERE]

Option 2: The Quick "Context Anchor" (Best for casual or rapid queries)

A lightweight snippet users can just append to a quick question.

Please solve the following RouterOS v7 task. To avoid syntax errors or deprecated v6 commands, explicitly browse the official new docs at https://manual.mikrotik.com/. Use the machine-readable map at https://manual.mikrotik.com/llms.txt and the live schema at https://manual.mikrotik.com/docs/cli-reference/ to verify the exact command paths and parameters before outputting your response.

Task: [INSERT TASK]


Key Technical Points to Highlight in Your Forum Post

When explaining to the forum why this works and how to use it, you should highlight a few critical facts about MikroTik's new setup:

  • The Power of the llms.txt Standard: Explain that /llms.txt and /llms-full.txt are part of a rapidly adopting standard specifically designed to give AI models a clean, noise-free site map of Markdown files. It prevents the model from getting lost in standard HTML UI elements (sidebars, footers, scripts) and provides direct links to the information it needs.
  • The Auto-Generated CLI Reference: Emphasize that the new cli-reference section isn't written by hand; it is compiled directly from the RouterOS software schema itself. Telling the LLM to check this specific path means it will look up actual exposed binaries and arguments, drastically reducing the hallucination of non-existent flags.
  • Strict Parameter Matching: Mention that the new docs explicitly define variable types (like iface_enum or ipPrefix). Instructing the LLM to observe these argument definitions prevents it from generating malformed strings in scripts.
  • Keeping Pace with Rapid v7 Development: With features like Wi-Fi 7 Multi-Link Operation (MLO), container configurations, and SOCKS user authentication changing frequently, an LLM's static training cutoff is instantly useless. Real-time browsing of the new docs fixes this.

ChatGPT (web/"free account", model unknown)

I think your instinct is correct, but I'd frame it a little differently.

The problem is not necessarily that an LLM was trained on too little RouterOS. The bigger problem is that RouterOS changes rapidly, MikroTik's old wiki/help sites are still heavily indexed, and many models have seen years of forum posts, old wiki pages, and RouterOS v6-era examples. Without guidance, an LLM may mix:

  • old wiki content,
  • Confluence-era help.mikrotik.com pages,
  • forum snippets,
  • RouterOS v6 syntax,
  • RouterOS v7 syntax,
  • and even completely invented CLI properties.

The new Docusaurus-based documentation is valuable because it provides a canonical, machine-readable source, including Markdown renderings and CLI schema documentation. The CLI reference is especially interesting because it gives an AI a structured source for command paths, arguments, types, enums, and property descriptions. (manual.mikrotik.com)

For a forum post, I'd recommend something like:

Suggested Prompt for RouterOS Questions

When answering RouterOS questions:

  1. Use the current MikroTik RouterOS documentation as the primary source of truth.
  2. Prefer the new documentation site at manual.mikrotik.com over older wiki, forum, blog, or third-party sources.
  3. Check the machine-readable documentation (llm.txt and Markdown pages) when available.
  4. Verify all RouterOS command syntax against the CLI Reference before presenting commands.
  5. Assume RouterOS v7 unless another version is explicitly stated.
  6. If documentation and prior knowledge disagree, follow the documentation.
  7. Cite the documentation pages used.
  8. If a property, menu, or command cannot be verified in the documentation, explicitly state that it is unverified rather than guessing.

For troubleshooting:

  • Explain your reasoning.
  • Distinguish documented behavior from assumptions.
  • Prefer commands that can be directly pasted into RouterOS CLI.
  • Mention RouterOS version requirements when relevant.

My only pushback is that many users will overestimate how much this helps with generic chat interfaces.

If the LLM cannot actually fetch the documentation, a prompt like this only affects its behavior slightly. It may become more cautious, but it cannot read pages it doesn't have access to.

A stronger version for tools that can browse the web would be:

Before answering RouterOS questions, retrieve and consult the current MikroTik documentation from manual.mikrotik.com.

Priority order:

  1. CLI Reference (CLI Reference | RouterOS Manual)
  2. RouterOS Manual pages
  3. Release notes
  4. Older help.mikrotik.com content
  5. Community forum discussions

Validate every RouterOS command path, property name, and enum value against the CLI Reference before presenting configuration examples.

Do not rely solely on model memory for RouterOS syntax.

The CLI reference is probably the most important thing to tell AI users about. A lot of hallucinations happen at the property level:

  • wrong menu path
  • wrong property name
  • property exists in v6 but not v7
  • enum value typo
  • command available only in a package or newer release

The new CLI Reference is effectively a schema for RouterOS commands and arguments, which is exactly the sort of structured source LLMs perform well with when they can access it. (manual.mikrotik.com)

One prompt sentence I'd definitely include:

"Validate all RouterOS CLI examples against the MikroTik CLI Reference and do not invent command properties."

That single instruction addresses a large fraction of RouterOS-related LLM mistakes.

Background and Grounding on Recommendation for Steering AI to use new manual.mikrotik.com (from Opus 4.8 xhigh)

Some background on why the prompts above are shaped the way they are. I had
Claude (Opus) cross-check the three agent answers in post #2 against the live
site and correct what they got wrong β€” notes below.

The real problem isn't "too little training" β€” it's stale, conflicting training

LLMs haven't seen too little RouterOS; they've seen too much of the wrong
RouterOS. Their data is dominated by:

  • wiki.mikrotik.com β€” voluminous, heavily mirrored, mostly v6, no longer updated
  • the retired Confluence help.mikrotik.com site
  • ~20 years of forum posts mixing v6 and v7

The new Docusaurus site (manual.mikrotik.com) is almost certainly after most
models' training cutoff
. So the failure mode isn't "I don't know" β€” it's
confident v6-for-v7 answers and invented properties. That's why the prompts lead
with "don't trust your memory" and name the old sites explicitly: you're
overriding bad priors, not filling a blank.

What the new site changed (and why it matters to an LLM)

MikroTik now emits a machine-readable copy of the docs on every build
(via the docusaurus-plugin-llms plugin):

  • /llms.txt β€” an index of all ~558 pages as [Title](…​.md): description
    links, following the llmstxt.org convention. It's a
    clean, noise-free map so the model finds the right page without wading through
    HTML nav/sidebars/scripts.

  • per-page .md β€” append .md to any docs URL for the raw Markdown
    (e.g. …/docs/introduction.md). Cheaper to read and far less ambiguous than
    rendered HTML.

  • /llms-full.txt β€” the entire manual in one file, for bulk ingest / RAG / offline.

  • robots.txt now explicitly welcomes the AI crawlers (ClaudeBot, GPTBot,
    PerplexityBot, Google-Extended, CCBot…) β€” so over time this content should
    even reach future training runs, not just live browsing.

The CLI Reference is the highest-value target

Most RouterOS LLM mistakes are property-level: wrong menu path, wrong property
name, a v6-only property, an enum typo, or a flag that simply doesn't exist. The CLI Reference documents exact menus, properties, argument types and enums β€” the
structured shape of the commands β€” which is precisely what models get wrong from
memory. Hence the prompt line "check the CLI Reference and don't invent properties."

One honest correction to the post-#2 answers: a couple of agents called the CLI
Reference "machine-generated." MikroTik's own words are more measured β€” auto-updating
the command reference from RouterOS source is "partially started in the CLI
reference section"
(@normis). So: increasingly authoritative, not yet fully generated. Worth checking, not yet blindly trusting for the newest features.

Honest limits (why post #1 leads with a capability table)

  • A prompt cannot make a non-browsing model fetch a page. For plain chat
    windows and local models it only induces caution. That's what Option C (paste-in / llms-full.txt) is for.

  • Web-browsing and agentic tools (ChatGPT browsing, Claude.ai/Code, Cursor,
    Perplexity, Copilot) are where the endpoints genuinely shine β€” they can run llms.txt β†’ .md β†’ cli-reference on their own.

  • Always have the model cite and quote the page it read. If it can't, it didn't read it.

Small corrections to the agent answers in post #2

  • It's /llms.txt (plural) and /llms-full.txt β€” not "llm.txt". The file and the standard are both plural.

  • Don't hard-code specific argument-type names in your prompt (one agent guessed iface_enum / ipPrefix). The real page defines its own set (address, bool, enum, ipAddr, ipv6Prefix, …). Telling the model to "match the types and enums the CLI Reference defines" is safer than naming them.

Net: the supply side is now excellent. These prompts are just about reliably pointing the model at it β€” and knowing when your tool can't follow.

Good job on the MCP server, looks awesome! Let us know if you need other data or in some better format

@Amm0 Do you know https://www.skills.sh/?

Do you know https://www.skills.sh/?

No. But I keep some SKILL.md files here: GitHub - tikoci/routeros-skills: Custom instruction SKILL.md for MikroTik RouterOS v7 Β· GitHub which are published to https://skillstore.io/skills?q=routeros&tools=claude and, I believe, would use skills.sh to install them using the skill.sh scheme:

npx skills add https://github.com/tikoci/routeros-skills

The skills are far from perfect, and not all well-structured... but they capture a few repeated AI mistakes I've seen. And I have tried to make sure there "grounded" by having agents use https://github.com/tikoci/quickchr to validate things against a "real" router... so likely not "wrong" but may be incomplete.

Thanks! Although I do believe that prompting an LLM agent to use Docusaurs llms.txt/*.md would already do a LOT – with no MCP required. So the new manual.mikrotik.com site should go a long way since Docusaurs seems to have WAY better architecture than Confluence for ongoing improvements. Rosetta MCP's main special ability beyond "steering to Docusaurs" is now just it's indexing/search - which manual.mikrotik.com be hard to match, as well as having all the product/changelog/video linked in one search ("tool call").

Using Rosetta as /app: https://github.com/tikoci/rosetta#install-on-mikrotik-app

And it worth commending MikroTik on the new custom /app YAML that makes it trivial to install the Rosetta MCP (and bunch of other minor improvements like multiline strings in scripting so cut-and-paste an /app/add just work). So outside the package/device-mode hell dance, it's just 3 steps, see GitHub - tikoci/rosetta: MCP Server with RouterOS docs + commands + products + changelogs, using SQLite-as-RAG, sourced from MikroTik Β· GitHub .

This important since adding MCP Server varies a lot. But the most "universal" method is to use a URL to an MCP Server (like Rosetta) in AI agents like Claude Code, CoPilot, Cursor, etc. Since /app will wrap Rosetta in HTTPS automatically, it's also secure without any work on my part. Previous to /app using the "raw" /container system, Rosetta setup be like 10-20 steps to explain, and add another 10-20 to setup certificates for HTTPS. With /app it's 5 commands, 1 reboot, and 1 power cycle at worst.

Further, the new cmd= support allows you to use the Rosetta /app as TUI from RouterOS Terminal. Perhaps surprisingly... all the ANSI/termcap stuff work through it. Background Rosetta also support a "TUI mode" that does NOT need AI since it just exposes searching of the SQLite DB that stores all the docs/changelogs/schemas/specs/etc. and it UX is entirely based on the SAME methods that an AI agent use navigate the data (although an agent get JSON, while TUI gets ANSI). And this can be easily accessed using one command (assuming Rosetta /app is installed):

/container/shell app-rosetta cmd="/app/rosetta browse"

Will get a search interface to RouterOS docs from the WinBox/SSH/etc terminal.

Basically I did not run into any issues in packaging Rosetta as a /app. So good work on /app, too!

@rodions was already very helpful by publishing the HTML export of Confluence, which is basis of rosetta MCP. But since you ask...

1. My #1 request be a new matrix.json that expands the existing product matrix.csv that y'all long maintained on www.mikrotik.com.

Today, rosetta's "ETL pipeline" has to scrape the www.mikrotik.com for product data CSV. As well as parse EACH product pages' HTML to find the ethernet and IPSec test results, and also locae the block diagram URL from the HTML content too.

If there were process on your www backend that generated some machine-readable JSON file like matrix.json (or whatever name) with ALL the of the product details from matrix.csv, PLUS the test results as JSON array of object under each product in JSON, along with a link to PNG with block diagram (and perhaps link to PDF brochure for completeness, although rosetta does not use the brochure)

  • Alternative and trivial work: The new website lost the direct download link the matrix.csv, so rosetta has to emulate your LiveWire framework to fetch it (since CSV is generated in client-side JS in new website). But just a static URL like http://mt.lv/products/matrix.csv would help me. And, one line mentioning the product matrix CSV in your new llms.txt on manual.mikrotik.com give AI agent a clue where it could resolve a product name into it's CPU/switch-chip/#port/PoE-abilities/etc – without rosetta MCP – likely provide even better answers if a prompt/instruction steered toward the llms.txt
  • e.g.: The product data allow for AI prompts that mention a device to be resolved to their specs. So for example, a user prompting an LLM with rosetta MCP installed, can ask things like "Does the RB5009 support L3HW?", which looks up the product from SQL (which then returns the matrix.csv, "test results", and even the "block diagram" [since some LLMs can "read" an image]), and queries docs for L3HW. This important since docs reference the switch chip, but user is likely to use a router name/model. And thus allow an AI to "reason over" the L3HW docs page with router spec is way more likely to get the right answer. And answer a likely follow on question: "What is the cheapest devices with L3HW, that has at least 8 ports with 1Gb port speed?"

2. Downloadable "Captions"/subtitles and "Chapters" .vtt files for the "YouTube" videos

Rosetta actually also pulls in the @MikroTik YouTube channel, so the MCP know the full collection of videos. Since it indexes both the captions and "surfaces" the chapters to MCP clients, the "main" MCP function routeros_search() will also return any video results so an agent can offer a video, i.e. if task is more of an question, than request for configuration.

Today transcript/captions/subtitles from YouTube are collected by Rosetta's build using yt-dlp scrapper against the @MikroTik channel to find your videos, and then added some same full-text index (FTS5) so a "topic search" will return a videos that mention VRRP (with ordering determined by BM25 indexed ranking)

But scraping YouTube is very fragile so it's a manual process since it needs a cookie etc etc to run yt-dlp. I would have used MikroTik's TikTube site, since the underlying PeerTube seems to have a nice REST API that Rosetta could use to fetch captions and subtitle VTT files that could be using the GitHub CI. This be WAY cleaner than yt-dlp schemes that require me running them on desktop (so Rosetta may be few videos behind YouTube).

The issue is the YouTube catalog is NOT synced to TikTube... so only YouTube has the full set of videos. Now I don't specifically care about TikTube, although to me it make sense they were in-sync... But if you had the captions/chapters/subtitles in VTT form someplace else that available for download... that work equality as well as PeerTube's REST API.

How video works in the MCP server... Since the Rosetta non-AI terminal interface ("TUI") emulates an MCP client (e.g. how an AI agent would call the Rosetta MCP server) so a human can "see" the same view as future agents. So a search on "VRRP" (for example) would find the one VRRP video from routeros_search() with pointer to `, and it break response up by chapters, so it has time-based URL to sections within the video. This all works since transcripts are all fully index, so it can find related video like the "7.20 changelog" videos that mentioned VRRP changes. e.g.

3. Minor, and mentioned in FEEDBACK thread, but manual.mikrotik.com should avoid any URL needing url encoding since url encoding is avoidable in Docusaurus by id in front-matter.

While Rosetta should not care about urlencoding when it eventually pulls from new manual.mikrotik.com... By avoid url encoding, you prevent an entire class of bug/issues for any programatic/agentic use of the doc pages since it's always possible something re-encode/early-decode special chars given a URL may passthrough many functions/processes (and if even one thing f*ck up encoding along the way, the URL becomes worthless downstream)

4. Docs and schemas for /app YAML

Despite writing a article on custom /app YAML, publishing a "JSON schema" for /app YAML, storing per-version catalogs of the "built-in" /app catalog, and even having a web-based /app YAML editor:

Yet, Rosetta MCP itself actually knows nothing about /app YAML. Part of this is lack of time, and part is that as a first principle Rosetta ONLY sources MikroTik generated content WITHOUT personal opinions/coloring. So waiting y'all to update the docs and perhaps publish an official scheme for the /app YAML :wink:

Side note: the /app YAML Editor support Google's experimental WebMCP interface for /app YAML - but WebMCP is completely different protocol from the "classic" MCP Server supported by Rosetta