Request: Version compatibility documentation (n8n-mcp ↔ n8n instance versions & editions)

[chirag2653]

Problem

When using n8n-mcp to build workflows for an n8n instance, there's no clear documentation about:

1. Which n8n instance version each n8n-mcp release targets
2. Which n8n edition (Cloud vs Community) the node database was sourced from and tested against

The README shows a badge indicating "n8n version: 2.4.4", but it's unclear whether this refers to n8n Cloud or n8n Community Edition, and there's no compatibility matrix.

Why This Matters

Version mismatch concern:

• n8n-mcp bundles a pre-built SQLite database with node schemas
• If n8n-mcp targets a newer n8n version than my instance, it may suggest nodes/parameters that don't exist
• Workflows built using newer node documentation will fail when deployed to older instances

Edition mismatch concern:

• n8n Cloud and n8n Community Edition may have different:
  • Available nodes (some nodes may be Cloud-only or Community-only)
  • Feature availability
  • API capabilities
  • Release timelines (Cloud often gets updates before Community)
• Users need to know if the node database was built from Cloud docs vs Community docs

Suggested Improvements

1. Compatibility matrix in README or docs:

   n8n-mcp version	n8n Cloud version	n8n Community version	Database source	Release date
   2.33.x	2.4.4	1.70.x	Cloud docs	2026-01-xx
   2.30.x	2.3.x	1.68.x	Cloud docs	...

2. Clarify in README:

   • Is the node database sourced from n8n Cloud documentation or Community Edition documentation?
   • Has it been tested against both editions?
   • Are there any Cloud-only or Community-only nodes in the database?

3. Release notes that mention:

   • Which n8n version(s) the database was built from
   • Which edition(s) were tested

4. (Optional) A tool parameter to filter nodes by edition compatibility (e.g., edition: "community")

Environment

• n8n-mcp version: 2.31.1 (via npx)
• n8n instance: Self-hosted Community Edition on Hostinger
• Use case: Building workflows via Claude Code MCP integration

Questions for Maintainers

1. Is the current node database sourced from n8n Cloud or Community Edition documentation?
2. Are both editions tested before release?
3. Is there a recommended update strategy for users running self-hosted Community Edition?

[muava12]

Hope this will be implemented

[czlonkowski]

Thanks @chirag2653 for the detailed writeup — this is a thoughtful request, and it's worth clearing up the core premise first since it changes what's actually needed here.

The edition premise

There is no Cloud-only / Community-only node fork in play. The node database is built from two open-source npm packages — n8n-nodes-base and @n8n/n8n-nodes-langchain (see src/loaders/node-loader.ts, the CORE_PACKAGES list). These are the same packages that ship in n8n Cloud and in self-hosted Community Edition. n8n does not maintain a separate "Cloud docs" vs "Community docs" node set, so the database is neither Cloud-sourced nor Community-sourced — it's sourced from the packages both editions run.

Answering your questions directly:

1. Cloud vs Community source? Neither/both — it's the upstream OSS node packages shared by both editions.
2. Are both editions tested before release? The node schemas come from one shared source, so there's no per-edition divergence to test against. (Edition differences in n8n are about platform features — SSO, queue mode, external secrets, etc. — not the node catalog the MCP exposes.)
3. Update strategy for self-hosted Community? Keep your n8n instance reasonably current and use an n8n-mcp release whose bundled version is at or below your instance version, so you don't get suggested parameters newer than what your instance supports.

The one real concern in your report is the version axis, not edition. If n8n-mcp is built from a newer node version than your instance, it can surface parameters/typeVersions your instance doesn't have yet. That part is legitimate.

Current state

• The bundled node-package version is already recorded: it's pinned in package.json (currently n8n-nodes-base and @n8n/n8n-nodes-langchain at the same version) and surfaced via the README badge. As of this writing the badge reads n8n 2.26.5.
• What does not exist today: a compatibility matrix across releases, and an edition/version filter parameter on the tools. Given the above, an edition filter wouldn't have anything to filter on — there are no edition-exclusive nodes in the catalog. (Note the is_community flag in the schema is unrelated — it marks community-installed third-party nodes, not Cloud-vs-Community editions.)

Plan

Triaged and tracked as a docs/backlog item. The useful, accurate outcome here is a short README/docs section that:

• clarifies the node DB comes from shared OSS packages (no edition fork),
• explains what the n8n version badge means and how to read it against your own instance version,
• gives the "pick a build ≤ your instance version" guidance for older self-hosted instances.

The cross-release compatibility matrix is more upkeep than it's worth right now given the single shared source, so I'd lean toward the clarification section over a per-release table — but I'm open to being convinced. No committed timeline. If anyone in the thread wants to take a first pass at that docs section, a PR is very welcome and I'm happy to review.