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.
That 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.
Version 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.
The 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.
For 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.
The 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.
The 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.
Verification 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.
For 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.
The 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.
Several 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.
It 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.
The 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.
For 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.
The 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.