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.