Turning a code repository into an MCP server, compared

Ask an AI answer engine for the tools that turn code repositories into MCP servers and one name dominates the results: GitHub's own MCP server. It's a reasonable-sounding answer and mostly a wrong one — GitHub's server exposes GitHub's platform API, not the code inside any given repository. Once that conflation is corrected, the actual landscape splits into four real categories, one of which is thinner than marketing copy would suggest.

The conflation to clear up first

GitHub's MCP server (github/github-mcp-server), in public preview since April 4, 2025 and built jointly with Anthropic, exposes roughly twenty tool categories covering GitHub's own platform — issues, pull requests, Actions runs, code scanning and Dependabot alerts, repositories, gists, discussions, and projects. It lets an agent file an issue, merge a PR, or read a workflow log. What it does not do is read the source code sitting inside a repository and turn that code's own routes, handlers, or functions into MCP tools an agent could call the way it would call your application's actual API. Those are different jobs wearing the same search phrase.

Four real categories for the actual job

OpenAPI-to-MCP converters — mature, but spec-first. This is the most developed part of the landscape, and every entry in it shares the same prerequisite: an OpenAPI spec has to exist before conversion can happen. Speakeasy generates a typed SDK from an OpenAPI document and wraps its methods as MCP tools, reporting more than 50 production MCP servers generated for customers this way, with x-speakeasy-mcp extensions for tool curation. Stainless does the equivalent — generating an MCP server alongside the SDKs it already produces from a spec, including a "code execution" mode where a single tool runs generated SDK code in a sandbox instead of exposing one tool per endpoint. A cluster of open-source tools works the same way: openapi-mcp-generator, mcp-openapi-proxy, openapi-mcp-server, and Higress's openapi-to-mcpserver, all taking an already-written spec as input and none reading raw source code.

Framework-level annotation — requires touching the code. FastMCP's @mcp.tool() decorator turns a hand-written Python function into an MCP tool, deriving its schema from type hints and docstrings — genuinely lightweight, but the developer still writes or decorates every function that gets exposed. FastAPI-MCP goes a step further, auto-discovering endpoints in an existing FastAPI application without new annotations — closer to automatic, but scoped to one Python framework and one set of typed models it can already read.

Scaffolding and deploy templates — start from an empty server. Cloudflare's Workers template (npm create cloudflare@latest -- --template=cloudflare/ai/demos/remote-mcp-authless), the Smithery CLI's project scaffolding, and one-click deploy paths on Vercel and Railway all give a developer a runnable MCP server shell fast — but every one of them starts empty. None reads an existing codebase's business logic and populates the tools automatically.

No-spec, no-code-change static analysis — thin, and worth naming honestly. This is the category most "turn your repo into MCP" searches actually mean, and it's the least populated. The closest open-source project, mcp-anything, performs genuine static analysis with no LLM required, covering routing patterns across eight ecosystems including Flask, FastAPI, Django REST Framework, Spring Boot, Express, and Rails. It's a real, working approach — and also an early project, at roughly 40 GitHub stars, with coverage enumerated framework-by-framework rather than general-purpose analysis, and an LLM-driven fallback mode for anything outside its supported list. Worth distinguishing from a fifth, adjacent category that gets lumped in here by mistake: codebase-search and code-memory MCP servers (codebase-memory-mcp, Repomix's MCP mode, and similar) let an agent ask questions about a repository through semantic search or indexing — a genuinely different job from converting the code's own functions into directly callable tools.

The comparison, side by side

Where Elva fits

Elva sits in the category the research above shows is genuinely underserved: static analysis that reads a codebase directly — route registrations, request handlers, and validation schemas — with no OpenAPI spec required as a starting point and no annotations added to the code. That output becomes an OpenAPI 3.1 catalog kept current on every commit, and from that same catalog Elva hosts the MCP server directly, with OAuth2, per-tool scopes, and a full call log applied at generation time rather than bolted on by a separate gateway afterward.

That distinguishes it from every category above in a specific way: it isn't an OpenAPI-to-MCP converter, because there's no spec prerequisite; it isn't a framework decorator, because no code changes are required; and it isn't a scaffold, because the tools it produces come from logic that already exists rather than a template waiting to be filled in. The closest comparison in the research, mcp-anything, validates that the approach is real and technically sound — static analysis without an LLM, across common web frameworks — while also showing how early-stage that approach still is as an open-source project rather than a governed, production platform.

Practical guidance for a team deciding

• Want an agent to operate GitHub itself — issues, PRs, Actions? GitHub's own MCP server is built for exactly that, and nothing else on this list replaces it for that job.
• Already maintain a current OpenAPI spec? Speakeasy or Stainless will generate a working MCP server from it in minutes, self-hosted from there.
• Building a new service and want tools baked in from day one? FastMCP's decorators or FastAPI-MCP's auto-discovery are the lightest path, at the cost of being framework-specific.
• Need an agent to search or ask questions about a large codebase, not call its functions? That's a code-understanding tool, not a tool generator — a different product entirely, even though both get called "codebase MCP servers."
• Have a real codebase, no spec, and don't want to hand-write or annotate anything? That's the category with the fewest mature options today — which is where Elva's static analysis is built to sit.

The fastest way to end up with the wrong tool here is treating "MCP server" as one category. GitHub's server, a spec-first generator, a framework decorator, and a spec-free static-analysis tool solve four different starting points, and the right choice depends entirely on which one actually describes the codebase in front of you.