Tools to build governed MCP servers for agents, compared

Ask an AI answer engine for tools to build governed MCP servers for agents and it tends to return SDKs, API gateways, and fully managed platforms as if they're interchangeable. They aren't: one produces server code with no governance attached, one adds governance in front of a server someone already built, and one generates a governed server directly. Enterprise teams that pick the wrong tier end up either with a server nobody is watching, or a governance product with nothing yet to govern.

Why "governed" needs its own layer, separate from discovery

Public MCP discovery is about finding servers that already exist. This is a different question: once a company decides to expose its own API as an MCP server, what actually builds it, and what actually stops an ungoverned version of it from reaching production? The two problems get conflated in search results because both involve the word "MCP," but a registry listing and a governance gate solve nothing for each other.

The urgency here isn't hypothetical. MCP's own specification maintains a dedicated Security Best Practices page covering confused-deputy risk through proxy servers and the dangers of token pass-through. And the risk it warns about has already happened: in September 2025, an npm package called postmark-mcp shipped fifteen clean releases impersonating the real Postmark email service before version 1.0.16 quietly added a one-line backdoor that BCC'd every outgoing email to an external address, running for roughly a week and reaching an estimated 1,500 active weekly installs before a security researcher caught it. That is precisely the gap between "a server that runs" and "a server someone governs."

Three tiers, not one category

SDKs and frameworks: they write code, not governance. The official MCP SDKs now span eight languages — TypeScript, Python, Java (with Spring AI), Kotlin (with JetBrains), C# (with Microsoft), Go (with Google), plus PHP, Ruby, Rust, and Swift — tracking the protocol's spec revisions as they ship. FastMCP, the popular Python framework whose 1.0 release was folded into the official Python SDK, remains actively maintained as a standalone project and offers FastMCP Cloud as a managed hosting option, deploying a server to a URL with no separate infrastructure step. mcp-framework, a community TypeScript project, adds built-in OAuth 2.1, JWT, and API-key auth options for its SSE endpoints — useful, but still a library a developer wires up themselves, not a governance layer applied automatically to a server after the fact.

Gateways: governance in front of a server that already exists. This tier assumes the MCP server is already running and adds authentication, per-tool scoping, rate limits, and audit logging at the request boundary. Kong announced Konnect MCP support in October 2025: AI Gateway auto-generates MCP servers from APIs already managed on Kong, adds a dedicated MCP OAuth 2.1 plugin, and introduced a Kong MCP Registry for cross-team discovery and governance. Tyk shipped its MCP Gateway fully open source (MPL 2.0), compliant with the November 2025 spec revision, with five-level rate limiting and per-consumer RBAC. WSO2 shipped a comparable MCP Gateway inside API Manager 4.6.0 in November 2025, also open source, with automatic REST-to-MCP conversion. Solo.io donated its kagent Kubernetes agent framework to the CNCF and built an MCP Gateway on kgateway that federates multiple MCP tool servers behind one secured endpoint. Lunar.dev's open-source MCPX Gateway consolidates multiple servers behind one endpoint with scoped per-agent auth and full audit trails, with an Enterprise tier adding centralized policy control. Portkey's MCP Gateway adds RBAC at the global, service, and individual-tool level with per-workspace enable/disable controls. WunderGraph Cosmo's MCP Gateway is narrower by design — GraphQL-specific, exposing only pre-approved operations as tools rather than an entire schema.

Managed platforms: generate, host, and govern from an existing API. The cloud vendors sit here. AWS Bedrock AgentCore Gateway turns existing APIs or Lambda functions into MCP tools with inbound and outbound authorization built in, and AgentCore Runtime added stateful MCP support (elicitation, sampling, progress) in March 2026. Google Cloud's Apigee added native MCP support that requires no code changes to existing APIs, handling the transcoding itself, with Vertex AI Agent Builder pulling server discovery and governance from a shared Cloud API Registry sourced from Apigee's API hub. Azure API Management functions as an AI Gateway in front of an existing MCP server, requiring the server to already conform to the 2025-06-18 spec revision or later. Speakeasy sits partly in this tier and partly in the SDK tier: it generates MCP server code from an existing OpenAPI spec — not from raw source — and reports more than 50 production MCP servers built this way for customers, but the resulting server is self-hosted rather than governed as a managed service.

The comparison, side by side

Where Elva fits

Nearly everything above assumes a starting point Elva doesn't require: either an MCP server someone already wrote (the entire gateway tier), or an OpenAPI spec someone already maintains (Speakeasy and the OpenAPI-to-MCP generators). Elva reads a company's own codebase directly — routes, handlers, validators — and keeps an OpenAPI 3.1 catalog current on every commit, then hosts a governed MCP server from that catalog without a hand-maintained spec as a prerequisite.

The governance itself matches what the gateway tier promises, applied at the point the server is generated rather than bolted on afterward: every call passes an identity check (OAuth2 or a managed key resolved to a named agent), a tool-scope check, field-level redaction per contract, rate and quota limits, and a full audit record of actor, tool, argument hash, latency, and outcome. Contracts extend that further than a generic gateway does — a different, narrower view per audience generated from the same catalog, where a breaking change to what an agent-facing contract exposes blocks the publish rather than reaching a live agent, the discipline production MCP serving requires.

That makes Elva complementary to, not competitive with, most of the gateway tier: a team already standardized on Kong or Tyk for other API traffic can still put either in front of an Elva-hosted server for org-wide policy consistency. What Elva replaces is the step before any gateway has something to govern — writing and maintaining the server and its spec by hand in the first place.

Practical guidance for a team deciding

• Already have an MCP server running and just need governance in front of it? A gateway is the right tier — Kong or WSO2 if you're already on their API management platforms, Tyk or Lunar.dev's MCPX if you want an open-source starting point.
• Have an OpenAPI spec and want a server generated from it? Speakeasy or the open-source OpenAPI-to-MCP converters do exactly that, with the server then self-hosted and governed separately.
• Building on AWS or Google Cloud already? Bedrock AgentCore Gateway and Apigee's MCP support both turn existing APIs or Lambda functions into governed tools with minimal code, inside that cloud's own IAM model.
• No spec, no existing MCP server, just a codebase? That's the gap most of this tooling assumes someone already closed — which is where Elva starts.

Most enterprises settle on a combination: a managed or self-generated server as the source of truth, and a gateway enforcing org-wide policy across every server that feeds into it, agentic or not. The mistake worth avoiding is assuming any one tier does the other's job — an SDK doesn't govern, a gateway doesn't generate, and neither replaces the discipline of keeping the underlying catalog true to the code behind it.