Reduce API governance fragmentation with SmartBear Swagger, now fluent in multiple protocols

Design, document, and verify APIs across OpenAPI, AsyncAPI, GraphQL, and MCP. gRPC and A2A support coming soon. 

If you lead engineering or platform strategy at any organization past a certain scale, you already know this: your APIs aren’t one thing anymore. They’re REST endpoints your mobile or web team calls with OpenAPI-described contracts, Kafka topics your data platform team documents (or doesn’t) with AsyncAPI, a GraphQL layer your frontend team built to stop over-fetching, and a handful of internal gRPC services your platform team runs because JSON serialization was costing them CPU at scale. There are an MCP server or two that your AI initiative stood up so agents could call internal tools, and an early but fast-growing mesh of A2A (Agent-to-Agent) connections letting those same agents discover, negotiate, and delegate tasks to each other across departments and external vendors – without a bespoke integration for every model. 

All of these elements co-exist in your organization’s API program, and appropriately so, because different problems have different natural protocols, and engineering organizations pick the right protocol for each job. The strategic question for platform and engineering leaders now isn’t “which protocol should we standardize on?” It’s “how do we govern quality, security, and compliance across all of them without fragmenting our tooling into silos?” 

That’s the problem broader multi-protocol support in SmartBear Swagger Studio, SmartBear Swagger Portal, and SmartBear Swagger Contract Testing is built to solve. Swagger now supports AsyncAPI, GraphQL, and MCP, alongside OpenAPI, across products in varying capacity. (For how this multi-protocol support came together over the past year, see Swagger in 2025.) Before getting into how, it’s worth being precise about why each of these protocols shows up in an organization’s API estate, and what actually drives adoption. The adoption reasoning is different for each protocol, and treating them as interchangeable is where governance strategies go wrong. 

OpenAPI: Still the foundation for clients, partners, & the public  

OpenAPI remains the default for anything client-facing, partner-facing, or public – synchronous, human-readable, and backed by mature HTTP clients in every language. Nothing beats it for external developer experience, and that isn’t changing. The multi-protocol story isn’t “OpenAPI is being replaced.” It’s “OpenAPI is now one contract type among several living in the same API ecosystem.” 

AsyncAPI: The event-driven architecture 

Request-response can’t describe what happens when a service publishes an event to Kafka and four downstream consumers react independently. AsyncAPI 3.0, stable since late 2023, fills that gap – capturing messages, channels, and operations once, then using protocol-specific bindings for the details. As agentic systems increasingly coordinate through events rather than calls, an undocumented event contract stops being a documentation gap and becomes a production risk. Financial services and e-commerce firms running event buses as their backbone are where this shows up first, and where message-contract audit trails start mattering as much as OpenAPI ones. 

GraphQL: Solving the aggregation problem REST created 

Frontend and mobile teams adopted GraphQL to stop over-fetching bloated payloads or under-fetching via five chained REST calls. A single schema that lets the client specify shape solves both, which is why adoption concentrates at the backend-for-frontend (BFF) layer, not as a REST replacement. The governance wrinkle: a GraphQL schema can expose a lot of surface area through one endpoint, so knowing who can query what, and what the resolver touches underneath, becomes a compliance question, not just a DX one. 

MCP: The protocol that made AI agents enterprise infrastructure in under two years 

Anthropic released MCP as an open standard in November 2024; by December 2025 it had moved to the Agentic AI Foundation under the Linux Foundation, with OpenAI, Google DeepMind, and Microsoft adopting it natively and financial-sector backers including Block and Bloomberg among its founding members. It solves the N×M integration tax – every AI app needing a custom connection to every tool by standardizing discovery and invocation. The catch is MCP servers are a new API surface appearing faster than most governance processes were built to track, and a drifting MCP contract is arguably riskier than an undocumented REST endpoint, since it’s called autonomously with limited oversight. 

The common thread: Fragmentation risk outweighs protocol proliferation 

None of these protocols are wrong to use. Your organization is likely to have OpenAPI, AsyncAPI, GraphQL, MCP, A2A, and gRPC in production simultaneously, and engineering organizations moving up the levels of autonomy are increasingly running all of them, each doing the job it’s suited for. The risk is having multiple tools with different review processes and different places where contracts can drift, with no single view of what’s actually being exposed, by whom, and whether it still matches what was designed and approved. That’s the real test of application integrity at the protocol layer – continuous, measurable assurance that your software just works as intended, with governance to operate at AI speed and scale, no matter which protocol carries the traffic. 

For regulated industries in particular, this isn’t a hypothetical situation. Banking TPRM programs, insurance compliance functions, healthcare organizations under HIPAA, and public sector teams working toward FedRAMP don’t get to say, “we’ll govern the REST layer and hope the Kafka contracts and the new MCP servers stay in sync.” Multi-protocol governance is the mandate, and a fragmented tool estate is precisely what makes that mandate hard to meet. 

This is the problem Swagger Studio, Swagger Portal, and Swagger Contract Testing are built to close: a consistent governance and compliance experience, no matter which protocol an API is built in. Govern and define multi-protocol APIs in Swagger Studio, document them in Swagger Portal and test for breaking changes before they reach production in Swagger Contract Testing. Eliminating the need for fragmented tooling just because engineering team is using the right protocols to solve the right problems.  

Swagger picked up its third consecutive Devies Award for API Management and Support in 2026, and most recently a recognition from API World in the API coding category – both, a reflection of the industry validating the need for governance that keeps pace with how fast teams are now building, across every protocol they’re building with. Governing all of them from one place is the harder part; and it’s where fragmented tooling turns into risk 

What’s next: gRPC and A2A support in Swagger 

Support for gRPC and A2A within Swagger is next on the roadmap – extending the same design, documentation, and contract-testing discipline to internal service-mesh traffic and agent-to-agent coordination. As agents stop just calling tools through MCP and start delegating tasks to each other through A2A, the same governance question follows them: who approved this agent’s ability to talk to that one, what’s the contract between them, and how do we prove it during an audit? 

The protocols will keep multiplying. With Swagger Studio, Swagger Portal, and Swagger Contract Testing, you can enforce the same standards of governance and compliance across your APIs – wherever your teams are actually building, in whatever protocol they’re building with. 

Looking for exact support within Swagger products for these protocols? Here’s how you can get started: