I’ve been using the n8n documentation MCP server (https://docs.n8n.io/~gitbook/mcp) with an AI tool to help me build and work with workflows.
Is there a way to scope or align the documentation responses from the docs MCP server to match my specific installed version of n8n?
The docs MCP server appears to serve the latest published documentation, but I manage various servers and one might not be running an older version and want to make sure the information returned is relevant to my setup — for example, avoiding suggestions for features that don’t exist in my version yet.
Specifically, I’d like to know:
Does the docs MCP server support any version filtering parameter (like the behaviour of Contex7)?
If not, is there a recommended workaround to ensure version-aligned documentation when using the MCP server with an AI tool? llm.txt with versions accessible?
If not, is this something on the roadmap?
Any guidance from the team or community would be appreciated!
No. The MCP server provided via the ~gitbook/mcp endpoint is a generic GitBook site-level implementation. It is designed to index and serve the currently published content of the documentation site.
Since the official n8n documentation at docs.n8n.io primarily hosts the latest stable version, the MCP server simply mirrors that state. It does not have a parameter to “roll back” the documentation context to a previous version of n8n.
State your version in the system prompt or the start of your conversation. Example:“I am working on an n8n instance running version v1.x. Please ensure all workflow suggestions and node parameters are compatible with this version and avoid features introduced in v2.x.”
Thanks. Perhaps a good feature request. Not only for the Doc MCP but also for the llm.txt doc at least. At least for major versions, considering the amount of releases n8n has.
Hi, as part of the n8n docs team just wanted to say thanks for your feedback and for highlighting this need.
Versioned docs are something that we think about a lot. It’s tricky because often versioning differences are not just at page level, but within a page (eg. a node or feature might exist since v2.0, but a specific parameter or option on that node/feature was only added in v2.32 — the “since” note lives on a paragraph or table row, not the whole page). That granularity is exactly what makes this harder to solve than a simple version switcher.
That said, this is genuinely useful feedback and we’ll keep looking at different possibilities. In the meantime, the most reliable workaround is to explicitly state your n8n version in your prompt (e.g. “I’m on v1.x, avoid anything introduced after that”) — it won’t catch every inline caveat, but it meaningfully cuts down on suggestions for features you don’t have yet.
Back to this, wondering if anything can be done to “support” this being implemented. With so many n8n updates we are trying to automate a prevalidation on updates, and this is a must. Thanks.
The system prompt workaround is worth knowing the limits of. In our experience building MCP servers, a version constraint in the prompt loses to content that arrives as a tool result, because the model tends to treat retrieved documentation as ground truth and the instruction as a preference. So it degrades in exactly the case you care about, where the docs describe a node parameter your version does not have.
Two things hold up better. The docs are a git repo, so you can check out the tag matching your version and point a local file or RAG based MCP at that instead. Version alignment then comes from the source rather than from asking nicely.
Better still for the specific question of whether a parameter exists on your install, ask the instance rather than the docs. Your running n8n knows its own node schemas, and that is authoritative for the version actually deployed, which no documentation approach can match when you are running several servers on different versions.
For full detail of every commit in every release, you can also see n8n-io GitHub Releases: Releases · n8n-io/n8n · GitHub
I’d be interested to hear more about your needs in relation to versioned docs and release details, we’re looking to do some user research soon. Let me see if I can get back to you to set something up, if you’d be interested.
Thanks @RoRoJ@themineworks — this thread actually pushed us to ship a pragmatic workaround instead of waiting for native version-filtering, and it works well enough for our case (multiple self-hosted n8n instances, automated pre-upgate validation).
What we landed on, in case it’s useful for the research:
Source = GitHub Releases, not the MCP. For “did node X change between my version and the target?”, we grep the release bodies in the range. They follow conventional-commits format — HTTP Request Node: Add Simplified Custom Auth, Execute Workflow Node: Deprecate Local File and URL sources — so each node surface is greppable. The MCP/docs couldn’t answer this (as @RoRoJ noted, the “since” notes live inside paragraphs). We use the Release Notes page (the n8n 2.34 … feature-level summaries) as a human-readable complement.
“Ask the instance” confirmed. We pull the actual node-type inventory from each running instance (n8n export:workflow --all → node types in use), plus the installed NodeDescriptions dump. That’s the authoritative “what exists on my version” — exactly what @themineworks suggested.
3. Scope = only the nodes that matter. We tag production workflows (production, excluding anything tagged test) and only run the changelog diff against the node types those use. Cuts the noise massively.
Net: a pre-flight that flags Deprecate/Remove/Breaking hits on the nodes we actually depend on, before touching the stack. Not as clean as native version-scoped MCP, but it’s working today.
That release-grep is a better answer than the one I gave, and the conventional-commits format making each node surface greppable is a nice property to lean on.
One gap worth patching in the same pass: those prefixes only hold for changes scoped to a node. Anything that moves underneath a node, the expression engine, credential handling, the task runner, tends to land without a node prefix at all. So a grep keyed on node names will quietly miss the class of change that breaks every workflow at once rather than one of them. n8n keeps a separate breaking-changes file in the repo, so it is worth running your version range against that too rather than trusting the release bodies alone.
The other thing your instance inventory unlocks, which you may already be doing: the range diff tells you what changed, but not what you depend on. Intersecting the node types actually in use on each instance with the deprecations in that range gives you the much shorter list that will genuinely break, and that is the one worth blocking an upgrade on. Everything else is informational and can go in a report nobody has to read before shipping.
Good to hear the ask-the-instance half held up in practice.
Great catch, thanks for the nuance — you’re spot on.
We did miss that gap in our first pass: a node-focused grep (keyed on **<Node> Node:**) would have quietly skipped the class of change that can hit every workflow at once — the expression
engine, credential handling, and the task runner. The instance only tells you where a node sits, not whether the floor underneath it moved.
We added a second pass to our diff script to cover it: we now also grep the release bodies in that range for non-node-scoped changes (**core:**, **task runner:**, **cli:**, **editor:* *) with breaking/deprecate/remove/migrate keywords, plus the semantic-release BREAKING CHANGE footers, and surface them separately as INFRA — flagging the upgrade as blocked if any hit. We still lean on the release notes and the breaking-changes file for major-version jumps.
And yes, completely agree: the ask-the-instance half (intersecting the node types actually in use with the deprecations in that range to get to the list that actually matters) is what makes
the report useful rather. That shorter list is exactly what we block on; everything else is informational only.