Making an Existing SaaS MCP-Compatible: A Practical Guide

The Model Context Protocol (MCP), the interface that lets AI agents call application tools, passed 400 million monthly SDK downloads—four times its level earlier in 2026—while making an existing SaaS product MCP-compatible still begins long before the protocol code.

That distinction matters. A modern REST API may expose most of what an agent needs, but a production MCP server also needs a carefully bounded tool surface, user-level authorization, auditability, rate controls, and predictable responses. The realistic goal isn’t to rebuild your SaaS around agents. It’s to add a governed interface over capabilities that already exist.

What does making an existing SaaS MCP-compatible actually require?

You need a translation layer between your API and MCP clients, not a wholesale backend rewrite. The server should map selected API operations into named tools, structured input schemas, and controlled responses while your application continues to own business logic, validation, and permissions.

0mcp’s API-to-MCP service follows that pattern. It converts OpenAPI 3.0.x, OpenAPI 3.1.x, Swagger 2.0, or Postman collections into a hosted MCP server. The important boundary is clean: 0mcp supplies tool names, descriptions, schemas, and runtime-authenticated requests; the original API remains responsible for business behavior and access control.

If your APIs already run behind Google Cloud API Gateway, you may not need a separate service at all. In Public Preview as of September 24, 2026, the gateway can expose an annotated OpenAPI 3.x document as a remote MCP server. It converts tools/call requests into REST calls while preserving existing JWT or API-key authentication, quotas, and logging. OpenAPI 2.0 isn’t supported.

Even in that lightweight case, you still need to choose what agents can see. Exposing every administrative endpoint is convenient for a demo and dangerous for customers. Start with read-only, low-blast-radius operations, then add actions only when you can preserve the requesting user’s permissions and record the exact downstream effect.

Which implementation path fits your existing SaaS?

For a modern API with stable authentication and limited tool surface, an API-derived adapter is usually the cleanest starting point. A custom build becomes more defensible when the agent needs domain-specific orchestration, multiple internal services, or stronger production controls.

Implementation path	Pricing available in research	Defining features	Best-fit audience
Touchlane Professional	$12,999 for an approximately three-week package	Multiple APIs, authentication and permissions, internal integrations, cloud deployment, monitoring, documentation, and source repository	SaaS products with multiple services and complex APIs
Upniche custom MCP development	From $999 to $2,999	Tool design, authentication, rate limiting, hosted or self-hosted deployment, and documentation; higher plans add a Claude Skill, orchestration, and monitoring	Teams scoping a custom connector across Starter, Business, or Enterprise plans
0mcp	—	Converts OpenAPI, Swagger, or Postman definitions into a hosted MCP interface without rewriting the backend	Founders, CTOs, and product teams with useful existing APIs
Google Cloud API Gateway	—	Transcodes MCP requests into REST while reusing existing gateway authentication, quota, and logging policies	Google Cloud teams already using OpenAPI 3.x and API Gateway

A dash means the research didn’t provide product pricing, not that the option is free.

The API-derived options minimize surface area because the existing API definition is the source of truth. That’s attractive for stable SaaS products, especially when the agent only needs to search records, retrieve status, or create a narrow set of tasks.

Custom packages make more sense when the mapping isn’t mechanical. A multi-service product may need shared permissions, internal dependencies, deployment automation, and monitoring that an automatic converter won’t infer. Our breakdown of MCP server development costs gets into that build-versus-buy distinction in more detail.

The deciding question is simple: does your API already represent the exact boundary you want agents to cross? If yes, adapt it. If agents need domain workflows spanning several services, build or buy a layer that can enforce those workflows explicitly.

How much should you budget for an MCP server?

Budget by the control surface you’re exposing, not by the number of protocol endpoints. Public pricing data varies so widely because a read-only adapter and a multi-tenant action server are different products.

Groovy Web’s 2026 guide places a single-server integration at $8,000 to $18,000, a multi-system enterprise rollout at $30,000 to $60,000, and a public server product at $20,000 to $45,000. The spread reflects authentication, rate limiting, monitoring, and the number of systems involved.

AppMatic Tech reports an overall range of $8,000 to $75,000. Its full enterprise tier, with four or more systems, a unified permission layer, custom audit logging, and multi-LLM routing, runs from $40,000 to $75,000. It also says per-user token passthrough adds two to three weeks.

The cost gap becomes much wider when “MCP server” means a production agent product. Launch Day Advisors reports partner-built costs of approximately $100,000 to $300,000 for a read-only, single-client application and $300,000 to $700,000 for one that can take actions. Ongoing maintenance is budgeted from $5,000 to $25,000 monthly. Its methodology comes from 2026 partner engagements and in-house builds, so treat it as a scope benchmark rather than a universal rate card.

For the existing SaaS case in the structured scenario, Touchlane Professional is the most directly comparable fixed-price package. At $12,999, its stated phases total 5 days of assessment, 12 days of design and implementation, and 3 days of launch work: 5 + 12 + 3 = 20 working days, matching its approximately three-week estimate. That’s plausible for a controlled launch, not evidence that every multi-tenant product fits that scope.

How should identity, permissions, and auditability work?

The server must carry the human user’s identity into every downstream action. A shared service account breaks attribution, can overgrant access, and makes incident response painfully slow.

The Odoo MCP Server illustrates a product-specific approach at $118.47. It supports Odoo 16 through 19, applies per-model create, read, update, and delete permissions, uses Odoo API-key authentication, records interactions, and limits requests to 100 per minute per user and 50 per minute per IP. Those controls show why an API wrapper can’t simply reuse an unrestricted integration key.

Identity should also travel with the agent rather than sit beside it. Frends MCP ties each action to a named user through a personal token, applies that user’s existing permissions, and requires drafts to be approved before production changes run. Rubrik’s MCP implementation takes a similar direction with scoped, short-lived tokens minted per individual tool call and role-based access parity through Okta or Microsoft Entra ID.

Runtime policy still matters. ServiceNow AI Gateway adds OAuth 2.1 client registration, tool scanning against OWASP MCP threat categories, input-and-output sensitivity policies, and runtime pause controls. It also changed its proxy URL format, forcing existing integrations to update their endpoints. That last detail is a reminder: governance itself becomes production infrastructure, not a checklist completed before launch.

How does the stateless MCP spec change the architecture?

The July 2026 specification makes an MCP server behave more like an ordinary horizontally scaled HTTP service. Transport-level sessions and the prior Mcp-Session-Id requirement are removed from the stateless core.

Google’s implementation analysis says the 2026-07-28 release removes transport-level session management, sticky-session routing, and the need to pin a client to one server instance. Servers can therefore run behind ordinary load balancing, serverless infrastructure, or edge platforms.

That doesn’t make migration automatic. Amazon’s AgentCore Gateway guidance says upgrading is opt-in: clients requesting the 2025-11-25 version continue unchanged, while clients requesting 2026-07-28 receive the new behavior. That’s useful, but your compatibility test matrix now needs to cover both paths if customers upgrade at different times.

SDK readiness is another constraint. Victor Dibia’s July 2026 analysis reports that only the C# SDK had all updates implemented when the spec shipped, with other SDKs still in progress. Sampling, Roots, Logging, and the legacy HTTP+SSE transport are deprecated, although Roots, Sampling, and Logging have at least a 12-month removal runway. Our deeper analysis of MCP’s stateless architecture changes covers the operational consequences.

When does a custom build beat an integration wrapper?

An integration wrapper wins when your product has a clean REST boundary and the agent’s allowed actions are already represented by existing API operations. A custom server earns its cost when agents need cross-service workflows, tenant-aware actions, or controls that generic mapping can’t infer.

The legacy case is different. Frends Enterprise MCP says existing Frends processes can be exposed as governed tools in two to four hours, claiming a 95% time reduction versus custom connectors. It also reports 70–85% lower exception-handling time and estimated annual savings from €90,000 to €250,000 for organizations processing 1,000 invoices per month. Those are vendor claims tied to particular workflows, not general savings guarantees.

MCPify makes an even sharper speed claim: it says mainframes, SOAP services, proprietary databases, and COBOL transactions can be wrapped in approximately 60 seconds with zero-code configuration, including an OAuth vault and multi-tenant isolation. If that holds for your system, the remaining work is validating schemas, identity propagation, and transaction safety.

The size of the surrounding estate explains why middleware keeps appearing in enterprise planning. Madgeek says custom integration code typically consumes 40–60% of an AI project’s development budget and that the average large enterprise runs more than 85 operational systems, most without native MCP support. Against that backdrop, the enterprise iPaaS market is projected to surpass $17 billion by 2028, with AI orchestration replacing static workflow automation as the main differentiator.

What evidence says about purpose-built MCP tools?

Purpose-built tools usually outperform generic access because they return the context needed for a job instead of forcing an agent to reconstruct it from broad tables. That’s especially important when the downstream interface exists mainly for software developers.

ServiceNow’s July 11 benchmark covered seven change-management prompts. Its MCP path produced approximately 52% lower Claude-side cost, 72% faster execution, and about 6.5 times fewer output tokens than direct Table API access. The company also notes that simple CRUD didn’t show the same advantage. Workflow-heavy work, where domain logic saves repeated calls, is the stronger MCP use case.

The emerging product pattern is to add MCP without replacing the human interface. Samsara MCP became generally available with more than 40 tools, carries the requesting user’s existing permissions, and is currently available at no additional charge, with future pricing based on monthly usage. That makes MCP another distribution channel rather than a replacement for Samsara’s core product.

Google is taking the same approach across Workspace. Seven MCP-powered integrations connect Gemini to products including Asana, HubSpot, QuickBooks, and Salesforce. They’re available through Workspace applications and enabled by default for users with the appropriate Gemini license.

Positive Group launched MCP servers for Positive Surfer, Positive Iconosquare, and Positive Signitic, with Positive User beginning a phased rollout in the fourth quarter of 2026. It cites Gartner’s projection that as much as $234 billion in enterprise SaaS spending could be exposed to agentic shifts by 2030. The strategic message is straightforward: keep the dashboard, add an agent-facing door.

What decision framework should an existing SaaS team use?

Use a three-gate decision. First, test whether an API-derived adapter can expose a narrow, read-only tool set while preserving your existing authentication and business rules. If it can, you’ve avoided a new service boundary before creating one.

Second, promote the adapter to a custom server only when a real workflow demands it. That usually means cross-service orchestration, state-changing actions, tenant-specific behavior, data normalization, or audit requirements that an imported operation can’t express. The hidden production costs of MCP SaaS workflows are mostly in those non-functional requirements.

Third, make customer rollout conditional on identity, least-privilege tool design, structured audit records, and explicit handling for failures. Validate both the previous and current protocol versions if adoption is staggered, and monitor token consumption as carefully as infrastructure usage. In Peliqan’s pricing analysis, vendor platform fees exclude Claude or OpenAI token spending, with mid-market token expense reported at €20,000 to €80,000 annually.

My default recommendation is a narrow API-derived pilot with read-only tools, followed by a custom governance layer only when the first workflow proves it needs one. If that pilot crosses service boundaries or permits state changes without user-scoped audit records, is it ready for customers, or merely ready for a polished demo?