How do I expose SaaS APIs through MCP?

Here's how to expose a SaaS API through MCP, from the pragmatic options fastest to build out to the fully custom approach:1. Generate an MCP server directly from your OpenAPI spec (fastest, least custom work)

The straightforward first move: expose each API endpoint as its own MCP tool If your OpenAPI spec has clean, robust schemas, this is genuinely close to a one-command generation step. Some SDK-generation platforms (e.g., Stainless) support this directly — you flip on an MCP server option in your config alongside your normal SDK generation, and it produces a working MCP server package from your existing spec Best when your API operations are simple, uniform, and largely CRUD-like, and you want to quickly validate whether MCP is worth investing further in before customizing anything 2. Use your API gateway's built-in MCP exposure (if you're already on one that supports it)

Azure API Management can expose any managed REST API as an MCP server directly through its portal — you select which operations to expose as tools, and it handles turning them into MCP-compatible endpoints without you writing an MCP server from scratch MuleSoft's Agent Fabric offers the same idea: adapt your existing APIs to the MCP standard rather than building new MCP servers, reusing your current security and governance layer in the process If you're already running Kong, Tyk, or Gravitee, check whether their AI Gateway features cover this too — several of the gateways we've discussed earlier now market native MCP exposure 3. Use a managed unified-API-to-MCP platform (if you're connecting to many third-party SaaS apps, not exposing your own)

If your actual need is agents accessing other SaaS tools (QuickBooks, Salesforce, HubSpot, BambooHR, etc.) rather than exposing your own product, a service like Apideck gives you one MCP server that fronts 200+ SaaS APIs with normalized schemas and managed OAuth, instead of building/maintaining a separate MCP server per integration This is the right tool if you're the consumer of many third-party APIs, not the provider of one 4. Build a custom MCP server (most control, most work)

Use the official MCP SDK (Python or TypeScript) Prepare: containerized dev environment (Docker), credentials for the APIs you're wrapping, and a short list of the first tools to expose Implement each tool with a clear name, description, and typed input/output schema; test each one in MCP Inspector before wiring it to production Add token-based or short-lived key auth, plus role-based permissions controlling who can call which tools Set up structured logging (Grafana/Datadog) for visibility, then containerize and deploy to staging before production Design principles that matter regardless of which path you pick Don't just mirror your REST API 1:1. Naively converting every endpoint into a tool works for small APIs, but breaks down at scale — every tool's name, description, and input schema gets loaded into the model's context window on connection. A large API with hundreds of endpoints can overflow the context before the agent does anything useful. Curate which resources you expose, and keep descriptions and schemas lean. Break complex endpoints into simpler tools. Agents perform more reliably with a sequence of small, predictable steps than with one endpoint that does five things via optional parameters. Consider progressive/dynamic tool discovery for large APIs. Rather than loading every tool upfront, expose a handful of meta-tools that let the agent discover and inspect specific tools on demand — one pattern reports reducing context usage by over 60x compared to loading everything at once, which matters a lot for complex multi-step workflows. Never let the model see raw credentials. The MCP server should hold and inject the actual API tokens itself; the agent only ever holds a scoped MCP session, not your underlying API keys. Scope permissions at the tool layer, not just the API layer. Enforce read/write/destructive distinctions in what tools are exposed — a read-only agent shouldn't even be able to discover a delete operation, let alone be blocked from calling it after the fact. Multi-tenant SaaS: scope each MCP server session to a single tenant's connected account, with the server URL itself often encoding which account and tool set to expose — don't build one shared MCP server across all your customers' data. A framing worth remembering MCP servers typically wrap your existing APIs rather than replace them — think of it as an AI-friendly interface layer on top of infrastructure you already have, not a parallel system to build and maintain independently. Your existing non-AI integrations keep working unchanged alongside it.