{
  "version": "2",
  "id": "https://freelancenews.online/news/openapi-to-mcp-generator-updated-to-group-endpoints-and-preserve",
  "title": "OpenAPI-to-MCP generator adds endpoint grouping and regen-safe custom code",
  "summary": "A developer-published tool for turning OpenAPI specs into MCP servers now groups operations into fewer tools and preserves hand-written code across regeneration, according to the author's release notes for version 2.1.5.",
  "body": "A community-built generator that converts OpenAPI specifications into Model Context Protocol servers has been updated to version 2.1.5, according to its author, who published the release notes on dev.to. The tool targets TypeScript, Python and Go and is distributed as an npm package, @christopher_dondici/mcp-gen, with source on GitHub. The author presents the release as a correction to a design mistake in the first version rather than as a feature expansion, and the evidence for everything below is that single post.\n\nThat mistake, as the author describes it, was a one-to-one mapping between API endpoints and MCP tools. On a specification with roughly 200 operations, the generator would produce a server exposing 200 tools. The author states this feedback came from Reddit and that it was correct. The author's own words are that nobody can use a server of that size; the post does not elaborate further on why, so the reasoning behind the redesign is the author's assertion rather than a documented finding.\n\nVersion 2.1.5 addresses this with grouping. Operations can be grouped by tag or by path, so 200 operations spread across eight tags collapse into roughly eight tools, each of which routes internally by action. The author supplies command-line examples showing a --group-by tag flag, and a variant that combines grouping with --include-tags to limit generation to a subset such as pets. This is the central mechanism of the release: fewer top-level tools, with dispatch handled inside each group.\n\nThe release also adds filtering that runs before generation. Documented flags include --path-prefix to restrict output to a path segment, --include-paths and --exclude-paths for allow and deny lists, and --operation-allowlist for naming specific operations such as listPets and createPet. The author's stated rationale is to generate only what will actually be used, which matters when a large public specification contains endpoints irrelevant to a given integration.\n\nFor teams that have already customized generated servers, the author describes a regeneration workflow built around marker comments and a three-way merge. Custom code is placed between @@mcp-gen:start and @@mcp-gen:end markers, and the author claims it survives regeneration when the --incremental flag is used. Reusable logic is directed into handlers.custom.*, which the author says is not overwritten unless --force is passed. These are the author's claims about behavior; the evidence does not include an independent reproduction of the merge.\n\nThe release notes list several fixes the author groups as P0 items in 2.1.5. For TypeScript, the author reports real query serialization, giving the example of a call with a limit parameter producing a query string on the request. For Python, the author reports _build_query and _build_headers functions in --http mode, including for grouped tools. For Go, the author states that --http is now wired to the real APIClient instead of stubs the author describes as not yet wired.\n\nThe author also reports that the registry is now v3-only, with what are described as actionable errors for removed keys and for v2 specifications. That is a compatibility statement: older specification versions and removed registry keys are expected to produce errors rather than silent behavior. The evidence does not describe a migration path or a deprecation timeline beyond that.\n\nVerification is described in the post as npm run build plus npm test, covering 11 suites and 196 tests. The author also provides a repository example using a Petstore specification, with commands to clone the repository, install dependencies, build, generate a TypeScript server, and run a validate command against the same specification. Installation is offered through a global npm install of the versioned package.\n\nFor freelancers and developers who maintain integrations against third-party APIs, the grouping change is the part most likely to affect day-to-day work. A server exposing eight grouped tools is a smaller surface to present than one exposing 200, and the pre-generation filters reduce the number of endpoints that have to be reviewed or documented. The marker-based regeneration approach, if it behaves as described, addresses a recurring maintenance cost: re-running a generator without discarding local edits.\n\nThe tradeoff the author implicitly accepts is that grouping moves complexity inward. Each grouped tool must route by action, so the quality of the generated dispatch logic matters more than it did in the one-tool-per-endpoint model. The author's own framing suggests the earlier model was unusable at scale, but the evidence does not compare the two approaches on accuracy, latency or failure modes, and no benchmark is offered.\n\nSeveral things remain unknown from the supplied material. There is no pricing information for the package, no stated license terms, and no independent testing beyond the author's own test suite. The claim that custom code survives regeneration rests on the author's description of a three-way merge and marker convention, not on a third-party audit. The Reddit feedback that prompted the redesign is referenced but not linked or quoted in the evidence.\n\nIt is also worth separating the event from the publication. The post carries a source timestamp, but the evidence does not establish an exact release date for version 2.1.5, so the version's ship date should be treated as unconfirmed. The author presents the changes as already present in the published package rather than as a roadmap, but that too is an author statement.\n\nThe design question the author ran into, how many tools to expose from a large API, is a general one rather than specific to this package. The author's answer is to group and filter; the evidence does not show how other generators handle the same problem, so no comparison is possible here.\n\nFor this audience, the practical implication is narrow but concrete: if you maintain a generated MCP server against a large OpenAPI spec, grouping and path filtering are worth evaluating before adopting the tool, and the marker convention is worth testing on a throwaway branch before trusting it with production customizations. Treat the regeneration guarantee as a claim to verify locally, not as a documented standard.\n\nThe honest limitation is that this is a single-author community release described in a single post. The evidence supports what the author says changed and how the flags are meant to work; it does not support claims about reliability, adoption, or superiority over alternatives. Developers should weigh the release notes as a starting point and confirm behavior against their own specifications.",
  "category": "dev",
  "language": "en",
  "datePublished": "2026-09-20T20:37:00.313Z",
  "dateModified": "2026-09-25T10:26:21.294Z",
  "eventDate": null,
  "sourcePublicationDate": "2026-09-20T19:50:35.000Z",
  "source": {
    "name": "dev.to",
    "url": "https://dev.to/christopherdond/i-turned-a-real-openapi-into-an-mcp-server-in-5-min-without-losing-custom-code-on-regen-2j2k",
    "kind": "community"
  },
  "practicalImpact": "If you maintain a generated MCP server against a large OpenAPI specification, the grouping and path-filtering flags are the features to evaluate first, since they directly reduce the number of tools exposed. Before relying on the marker-based regeneration workflow for production customizations, test it on a disposable branch, because the survival guarantee is the author's claim rather than an independently verified behavior.",
  "limitations": "All details come from a single community post by the tool's author; the evidence contains no independent testing, no pricing or license information, and no exact release date for version 2.1.5. The referenced Reddit feedback is not linked or quoted. Claims about regeneration preserving custom code and about the P0 fixes are author statements, not verified facts, and no comparison of grouped versus ungrouped tools on accuracy or performance is provided.",
  "keyPoints": [
    "Version 2.1.5 of the OpenAPI-to-MCP generator groups operations by tag or path, turning roughly 200 operations across eight tags into about eight tools, per the author.",
    "Pre-generation filters include --path-prefix, --include-paths, --exclude-paths and --operation-allowlist, according to the release notes.",
    "Custom code placed between @@mcp-gen markers is said to survive regeneration via a three-way merge when --incremental is used, and handlers.custom.* is not overwritten without --force.",
    "The author reports P0 fixes for TypeScript query serialization, Python query and header builders in --http mode, and Go --http wiring to a real APIClient.",
    "Verification is described as npm run build plus npm test across 11 suites and 196 tests; no independent testing or pricing is provided."
  ],
  "review": {
    "status": "source-reviewed",
    "checkedAt": "2026-09-25T10:26:21.294Z",
    "method": "Automated comparison against retrieved source text; not independent fact-checking.",
    "correctionNote": "Updated after automated comparison with the full extracted source text. Attribution, wording and practical context were re-evaluated; this is not an independent fact check."
  },
  "sources": [
    {
      "id": 1,
      "url": "https://dev.to/christopherdond/i-turned-a-real-openapi-into-an-mcp-server-in-5-min-without-losing-custom-code-on-regen-2j2k",
      "publisher": "dev.to",
      "title": "I turned a real OpenAPI into an MCP server in 5 min (without losing custom code on regen)",
      "publishedAt": 1789933835000,
      "fetchedAt": 1790331966600,
      "hash": "c6cc7c1513277b7283051220c9e979c8db1ad9a88457efaa107c096cd93db78c",
      "kind": "community"
    }
  ],
  "claims": [
    {
      "claim": "The author states the first version mapped one endpoint to one tool, producing a 200-tool server for a 200-operation API, and that this was the mistake corrected in 2.1.5.",
      "source": 1,
      "id": "claim-1",
      "url": "https://freelancenews.online/news/openapi-to-mcp-generator-updated-to-group-endpoints-and-preserve#claim-1"
    },
    {
      "claim": "Grouping by tag or path is documented as collapsing 200 operations across eight tags into roughly eight tools that route internally by action.",
      "source": 1,
      "id": "claim-2",
      "url": "https://freelancenews.online/news/openapi-to-mcp-generator-updated-to-group-endpoints-and-preserve#claim-2"
    },
    {
      "claim": "The generator supports pre-generation filtering through flags including --path-prefix, --include-paths, --exclude-paths and --operation-allowlist.",
      "source": 1,
      "id": "claim-3",
      "url": "https://freelancenews.online/news/openapi-to-mcp-generator-updated-to-group-endpoints-and-preserve#claim-3"
    },
    {
      "claim": "Custom code placed between @@mcp-gen markers is said to survive regeneration through a three-way merge, and handlers.custom.* is not overwritten without --force.",
      "source": 1,
      "id": "claim-4",
      "url": "https://freelancenews.online/news/openapi-to-mcp-generator-updated-to-group-endpoints-and-preserve#claim-4"
    },
    {
      "claim": "The author reports P0 fixes in 2.1.5 covering TypeScript query serialization, Python query and header builders in --http mode, and Go --http wiring to a real APIClient.",
      "source": 1,
      "id": "claim-5",
      "url": "https://freelancenews.online/news/openapi-to-mcp-generator-updated-to-group-endpoints-and-preserve#claim-5"
    },
    {
      "claim": "The author states the release was validated with npm run build and npm test across 11 suites and 196 tests.",
      "source": 1,
      "id": "claim-6",
      "url": "https://freelancenews.online/news/openapi-to-mcp-generator-updated-to-group-endpoints-and-preserve#claim-6"
    }
  ],
  "formats": {
    "html": "https://freelancenews.online/news/openapi-to-mcp-generator-updated-to-group-endpoints-and-preserve",
    "markdown": "https://freelancenews.online/news/openapi-to-mcp-generator-updated-to-group-endpoints-and-preserve.md",
    "json": "https://freelancenews.online/news/openapi-to-mcp-generator-updated-to-group-endpoints-and-preserve.json"
  }
}