MCP as a First-Class API Style: What It Means and Why Your Gateway Architecture Matters

In spring 2026, Google’s Apigee API Hub began treating MCP as a first-class API style — right next to REST, gRPC, and GraphQL. API operations are mapped to MCP tools through Discovery Proxies, and MCP servers sync into Google’s Agent Registry. Around the same time, Gravitee 4.11 shipped MCP as a dedicated API-type template with its own analytics dashboards. Kong AI Gateway 3.14 added an Agent Gateway that positions MCP as one of three native traffic modes alongside LLM proxy and A2A.

The pattern is converging: MCP is no longer a sidecar experiment. It is a catalog entry that lives next to your REST APIs and shares the same lifecycle controls. This article explains what “first-class API style” actually means in practice, how three major platforms are implementing it, and why the architecture of your API gateway determines whether you get this by default or need to bolt it on after the fact.

What “first-class API style” means (and why it matters)

An API style becomes first-class in your platform when it gets the same treatment as every other API style in your catalog. For REST, that treatment is table stakes: you register the API, it appears in your developer portal, developers can subscribe and get credentials, and the platform handles authentication, rate limiting, versioning, observability, and billing.

When MCP is not first-class, teams end up with a parallel universe of tooling. The MCP server lives in a separate repository. It has its own authentication logic. It doesn’t appear in the API catalog. There’s no rate limiting, no usage tracking, and no billing. Developers discover MCP tools through README files or Slack messages instead of the developer portal. Governance teams can’t see what agents are doing because MCP traffic bypasses the gateway entirely.

When MCP is first-class, the parallel universe collapses. MCP tools show up in the same catalog as REST endpoints. They use the same credential system. They’re subject to the same policies. Developers discover and consume them through the same portal workflows. And operations teams get the same observability they expect from any API.

The shift matters because AI agents are becoming a primary consumer of APIs. If your MCP surface doesn’t have the same lifecycle controls as your REST surface, you have a governance gap that grows with every agent integration.

How major platforms are implementing first-class MCP

Three platform announcements in spring 2026 illustrate the trend — and three different architectural approaches to solving the same problem.

Apigee: MCP as an API Hub style with Agent Registry sync

Google’s Apigee announcement introduces MCP as a recognized API style in API Hub. The workflow is spec-driven: you register an API with an OpenAPI specification, Apigee assigns the MCP API style, creates a Discovery Proxy that maps operations to MCP tools, and synchronizes the resulting MCP server into Google’s Agent Registry.

What this means in practice:

• Auto-classification — API Hub recognizes MCP-eligible specs and assigns the MCP style automatically, so MCP APIs appear alongside REST and gRPC entries in the catalog without manual tagging.
• Agent Registry sync — MCP servers registered in API Hub flow into the Agent Registry, which is Google’s discovery layer for AI agents. Agents find tools through the registry rather than through hardcoded URLs.
• Zero-code MCP generation — Apigee creates managed MCP servers from existing API specs. No separate server deployment is required.
• Google Cloud security stack — MCP endpoints inherit OAuth 2.1, OIDC, and Cloud Data Loss Prevention integration.

The strength of this approach is the tight integration with Google Cloud’s ecosystem. The limitation is that it’s locked to Google Cloud infrastructure — if your APIs run elsewhere, the API Hub classification doesn’t help.

Gravitee 4.11: MCP as a dedicated API-type template

Gravitee 4.11 takes a different angle. Rather than auto-generating MCP servers from specs, Gravitee treats MCP as a dedicated API type within its management platform — on equal footing with HTTP Proxy APIs and LLM APIs.

What this means in practice:

• MCP API-type template — When you create a new API in Gravitee, MCP is a selectable type alongside HTTP Proxy and LLM. The platform applies MCP-specific configuration and analytics from the start.
• MCP analytics dashboards — Gravitee provides template-based dashboards for MCP traffic with metrics on request volumes, gateway latency, and operational patterns, comparable to the dashboards available for HTTP and LLM API types.
• MCP Resource Server v2 — Full OAuth configuration, client secret and certificate management, and CRUD permissions for MCP resources — upgraded from proof-of-concept to enterprise-grade.
• AI-powered PII filtering — A policy that detects and redacts personally identifiable information flowing through MCP tools.

Gravitee’s approach emphasizes the event-driven, observability-first side of MCP governance. MCP APIs get their own analytics pipeline, which makes Gravitee a strong fit for teams that need deep visibility into how agents are using tools. The enterprise edition requirement for AI and agent management features is the main gate.

Kong AI Gateway 3.14: MCP as a native traffic type

Kong’s 3.14 release positions the AI Gateway as a three-mode system: LLM Gateway, MCP Gateway, and Agent Gateway. MCP is one of three native traffic categories, each governed through the same Konnect control plane.

What this means in practice:

• Three traffic modes — LLM traffic flows through ai-proxy plugins, MCP traffic through ai-mcp-oauth2 and ai-mcp-proxy plugins, and A2A traffic through the ai-a2a-proxy plugin. Each mode has dedicated plugins but shares the same authentication, rate limiting, and observability policies.
• Token exchange (RFC 8693) — Kong intercepts incoming tokens and swaps them for downstream tokens with restricted scopes, enabling token downscoping and on-behalf-of delegation for MCP tool access.
• Scope-based tool filtering — MCP tool access is restricted using OAuth2 scopes from incoming tokens, removing the need for manual consumer group mapping.
• JWK-based token validation — MCP tokens are validated locally using cached public keys from the authorization server’s JWKS endpoint.

Kong’s plugin-based approach gives teams granular control over each traffic type. The trade-off is configuration complexity — each traffic mode uses different plugins, and the full feature set requires Konnect enterprise licensing.

What teams should standardize across REST and MCP

The vendor announcements share a common thesis: MCP should share the same lifecycle controls as REST. Here’s what that looks like in practice and why each control matters for MCP specifically.

Catalog ownership

Every MCP server needs an owner, just like every REST API needs an owner. When an MCP tool breaks, someone needs to be on call. When an agent starts using a tool in an unexpected way, someone needs to decide whether that’s acceptable. If your MCP servers aren’t registered in the same catalog as your REST APIs — with the same ownership metadata — you’ll discover the ownership gap during an incident.

Versioning

MCP tools evolve. Input schemas change. New tools are added. Old tools are deprecated. Without versioning, agents that cached an older tool list will break when the server changes. First-class MCP means your MCP servers have the same versioning strategy as your REST APIs: version identifiers, deprecation policies, and a migration path for consumers.

Authentication and authorization

MCP traffic needs the same authentication pipeline as REST traffic. API keys, OAuth tokens, or JWTs — the mechanism matters less than the consistency. If your REST APIs require authentication but your MCP server is open, you’ve created an unprotected back door into your backend services. Every tool call should be tied to a consumer identity, and that identity should determine which tools are accessible.

Rate limiting

AI agents don’t behave like human users. They burst. They retry aggressively. They run in loops. Without rate limiting on MCP tool calls, a single misconfigured agent can overwhelm your backend. The rate limits should work the same way as REST rate limits — per consumer, per time window, enforced at the gateway before traffic reaches your backend.

Observability

You need to know which tools are being called, by which agents, how often, and how fast. If your MCP traffic isn’t instrumented with the same observability as your REST traffic, you have a visibility gap. First-class MCP means MCP tool calls appear in the same dashboards, with the same granularity, as REST endpoint calls.

Monetization

If you charge for REST API access, you should be able to charge for MCP tool access through the same billing system. Separate billing for MCP creates operational overhead and confuses customers who are already paying for API access. First-class MCP means tool calls increment the same meters and are subject to the same plans as REST requests.

How an OpenAPI-first gateway gets this by construction

The announcements from Apigee, Gravitee, and Kong represent three different approaches to making MCP first-class. There’s a fourth approach that avoids the problem altogether: start with an OpenAPI-first architecture where every route is spec-defined, and MCP becomes first-class by construction rather than by configuration.

This is how Zuplo works. The MCP Server Handler reads the same OpenAPI specification that drives REST routing, request validation, and developer portal generation. It automatically transforms API routes into MCP tools — using operation IDs for tool names, descriptions for tool descriptions, and request schemas for input validation. There is no second catalog, no separate registry, and no manual tool-definition step.

One spec, one catalog

In Zuplo, your routes.oas.json file is the single source of truth. REST endpoints and MCP tools are derived from the same document. When you add a new endpoint and include it in the MCP server’s tool configuration, it’s available as both a REST operation and an MCP tool — derived from the same OpenAPI definition. When you update a description, both the developer portal and the MCP tool listing reflect the change. The “second catalog” problem — where MCP tools drift from the REST API they wrap — doesn’t exist because there is no second catalog.

One policy pipeline

The MCP Server Handler runs inside the same policy pipeline as REST routes. Authentication, rate limiting, request validation, and custom policies apply to MCP traffic without any additional configuration. If you add an API key authentication policy to a route, that policy applies whether the request comes from a REST client or an AI agent calling an MCP tool.

Critically, the handler keeps MCP requests within the gateway — it doesn’t make outbound HTTP calls to invoke tools. It re-invokes the configured routes internally, preserving the full policy pipeline for both the MCP server route and the tool’s target route. The execution order is: MCP server inbound policies → tool route inbound policies → tool route outbound policies → MCP server outbound policies.

One developer portal

Zuplo’s developer portal is auto-generated from the same OpenAPI specification. Developers discover APIs, get credentials, and explore endpoints through a single portal — regardless of whether they’ll consume the API via REST or MCP. There’s no separate “agent catalog” or “tool registry” to maintain. The self-serve credential flow works the same way for both consumption patterns.

One billing plane

Zuplo’s monetization system applies plans, metering, and Stripe-backed billing to any route — including MCP server routes. The MonetizationInboundPolicy runs on MCP routes the same way it runs on REST routes. Tool calls increment the same meters, are subject to the same quotas, and appear on the same invoices. There’s no separate billing integration for MCP traffic.

This is what “first-class API style” looks like when the architecture enforces it by default. You don’t configure MCP to be first-class. You define your API in OpenAPI, and the gateway treats every consumption pattern — REST, MCP, or both — with the same lifecycle controls.

One observability layer

MCP traffic flowing through Zuplo inherits the same analytics and logging as REST traffic. The same log integrations (Datadog, New Relic, Dynatrace, and others) that capture REST traffic capture MCP traffic. You can enrich logs with MCP-specific dimensions — capability name, method type, and consumer identity — using custom policies on the MCP server route.

For teams that need dedicated MCP observability, Zuplo’s MCP Gateway provides a built-in analytics dashboard with three event families (requests, capabilities, and auth), failure origin breakdown, gateway-versus-upstream latency splits, and per-capability metrics — the same signals covered in our guide to MCP analytics at the gateway.

Choosing the right approach for your team

The right path depends on where you’re starting from.

If you’re already on Google Cloud and use Apigee, the API Hub MCP style assignment and Agent Registry sync give you first-class MCP within the ecosystem you already manage. The trade-off is Google Cloud lock-in — your MCP governance is tied to the same infrastructure commitment as the rest of your Apigee deployment.

If you’re running Gravitee and need deep MCP analytics, the 4.11 release gives you MCP as a dedicated API type with purpose-built dashboards. The MCP Resource Server v2 upgrade brings enterprise-grade OAuth for MCP tools. The trade-off is the enterprise edition requirement for AI and agent management features.

If you need A2A protocol support alongside MCP, Kong 3.14’s three-mode architecture covers LLM, MCP, and A2A traffic from a single control plane. The trade-off is plugin complexity and Konnect enterprise licensing for the full feature set.

If you want MCP to be first-class by default without additional configuration, an OpenAPI-first gateway like Zuplo eliminates the problem at the architectural level. Define your API in OpenAPI, and every lifecycle control — authentication, rate limiting, observability, monetization, developer portal — applies to MCP traffic automatically. There’s no second runtime, no separate registry, and no plugin to configure.

For a detailed feature-by-feature comparison across these platforms, see our AI gateway comparison guide.

The architectural takeaway

The convergence across Apigee, Gravitee, and Kong validates a principle that’s been true since the first MCP server shipped: MCP traffic deserves the same governance as REST traffic. The question is whether your platform requires you to build that governance for MCP separately, or whether the architecture gives it to you by construction.

If MCP is going to be a real API style — with the same lifecycle, the same catalog presence, the same billing — you want a gateway that already treats it that way. Not because a vendor told you to, but because the architecture makes any other outcome impossible.

Start building with Zuplo — deploy an MCP server from your OpenAPI spec in minutes, with authentication, rate limiting, and observability included from the first request.