As MCP spreads, I keep hearing a familiar question in enterprise AI discussions: if MCP becomes the standard way for agents to call systems, will we eventually have to replace our REST APIs and API gateways?
I would start elsewhere. If an API already handles business rules, security, transactions, and audit reliably, adopting MCP is no reason to rebuild it. The design question is which capabilities an agent should discover, what contract it should use to call them, and how far its access should extend.
Which capabilities should we expose above an existing API-first backend, and through which agent-facing surface?
That question leaves room for existing OpenAPI tools, vendor hosted MCP servers, and custom MCP servers. The right combination depends on who owns the capability and how many AI consumers need it.
REST and MCP Have Different Jobs
A REST API is a general integration contract between applications. URLs, HTTP methods, request and response schemas, authentication, and error semantics establish a stable boundary for system-to-system calls.
MCP addresses a different interaction: how an agent or AI client discovers, understands, and calls an external capability through a common interface. To the agent, the choice is a capability it can use, rather than merely an endpoint it can reach.
Suppose an organization already operates these APIs:
POST /salesforce/cases
GET /customer/360
POST /erp/orders
GET /documents/searchConnecting an agent does not require reimplementing all four. One capability might remain an OpenAPI tool. Another might be available through a vendor hosted MCP server. A capability used repeatedly across several agents and clients might justify its own shared MCP surface. Replacing the implementation and standardizing its consumption interface are separate decisions.
The MCP specification dated July 28, 2026, also fits this operational view. Its remote transport direction reduces dependence on protocol-level sessions in favor of self-contained HTTP requests. It specifies OpenTelemetry trace context rules for distributed tracing. Those changes make it clearer how an MCP server can operate as a workload on existing HTTP infrastructure, without treating it as a special long-lived connection system.
The useful framing, then, is to standardize the capability contract an agent consumes while keeping established backend responsibilities in place.
Choose the Exposure Surface for Each Capability
Enterprise capabilities do not all need the same exposure path. In practice, I would consider three options.
Keep existing OpenAPI. If a REST/OpenAPI contract is well defined and only one or two agents use it, this is often the simplest choice. The schema and error contract should be stable; authentication and authorization may already be managed at the API gateway; and there may be little need for dynamic discovery or reuse across clients. In that situation, a separate MCP server can add an adapter and operating responsibility without adding much capability. A working boundary is a sound place to start.
Use vendor hosted MCP. This deserves an early look when the vendor owns the product capability and its permission model. Salesforce Hosted MCP Servers, for example, offer standard and custom servers that expose Salesforce capabilities to MCP clients under the authenticated user’s permissions. The Headless 360 MCP Server Beta places many Salesforce operations behind a smaller Discover, Describe, and Dispatch surface instead of exposing every operation as an individual tool.
The value is more than avoiding a direct REST call. The vendor manages boundaries it knows well: identity, permissions, audit, and the capability catalog. Microsoft Foundry shows a related pattern. Its Toolbox and private tool catalog manage sources including MCP and OpenAPI centrally, while tool search makes relevant tools available at runtime. For a vendor-native capability, I would first ask whether its governed surface meets the need.
Build custom MCP when shared use warrants it. A custom MCP server is not the default destination for every internal API. Imagine that one Microsoft Foundry Agent initially calls the customer/360 API. An OpenAPI tool may be enough. Later, ChatGPT, a Salesforce-side agent, an internal Copilot, an n8n agent workflow, and a custom CLI agent need the same capability. If each consumer maintains its own schema mapping, authentication connection, tool description, and versioning rules, the cost changes.
At that point, a custom MCP surface can provide a shared capability contract for those AI consumers. It still does not require a backend rewrite. Its value grows when reuse and common governance outweigh the additional operating complexity.
The deciding question is whether repeated integration and governance work across consumers has become expensive enough to justify that shared surface. It is not whether custom MCP sounds more modern.
When Tools Multiply, Selection Becomes the Hard Part
Adding the first tool may be straightforward. An enterprise agent can soon have access to CRM, ERP, document search, data platforms, ticketing, provisioning, analytics, and deployment capabilities. Then the harder question is which of those capabilities to show for the task at hand.
Putting hundreds of tool schemas into the model context carries a cost and can weaken tool selection. Salesforce’s smaller Discover, Describe, and Dispatch surface and Foundry Toolbox’s tool search address this problem from different product contexts: they help the agent find a relevant capability without presenting every operation at once.
I find it useful to keep two questions distinct. Discovery asks what the agent can see. Authorization asks what it may actually do. A successful tool search does not authorize execution. Equally, a user’s permission to use a tool does not mean its schema must always appear in the model context.
That is why I would design enterprise tool exposure as curated discovery:
Enterprise capabilities
↓
Capability catalog
↓
Task / identity / context
↓
Relevant capability retrieval
↓
Bounded tool surface
↓
Agent planning
↓
Runtime authorization / policy
↓
Controlled execution
This connects to the distinction between what an agent can call and what it may execute. Here, the design starts one step earlier: which capabilities should the agent be able to discover and select in the first place?
MCP Does Not Supply Identity or Observability by Itself
MCP can improve interoperability, but enterprise security and governance still depend on the implementation. For each exposed capability, the design needs answers to concrete questions:
- Whose identity executes the tool call?
- Does end-user identity reach the backend, or does the call use a shared service identity?
- Where are tenant and record scope checked?
- Which approval policy governs destructive actions?
- Can a tool call and its downstream API calls be connected in one trace?
- What versioning and regression tests apply when the capability contract changes?
Salesforce Hosted MCP can provide per-user permission and audit boundaries. Microsoft Foundry environments can be configured with Entra identity or OAuth passthrough. These are security contracts supplied by particular implementations; using MCP alone does not confer them.
The distinction is especially easy to miss when wrapping an internal API with custom MCP. A tool schema at the MCP server does not remove the underlying API’s business authorization. The API gateway and domain service must continue to enforce the permission checks and mutation policies they own.
Where Custom MCP Starts to Pay Off
On a new enterprise project, I would assess capabilities individually before drawing up any broad MCP migration plan. Five signals help locate the break-even point:
- AI consumer count: With few consumers, retain an existing OpenAPI contract. As more consumers need the same capability, consider a common MCP surface.
- Vendor-native capability: Reuse existing integration where the vendor has little role. Where the vendor owns the capability and its governance boundary, evaluate hosted MCP first.
- Dynamic discovery: Fixed tool bindings may suffice when discovery needs are low. Greater discovery needs make a catalog and tool search more useful.
- Common governance: Runtime-specific configuration may work at small scale. Shared governance needs increase the value of a central capability surface.
- Existing API stability: Improve an unstable backend contract first. If the API is stable, keep it and add only the exposure layer the consumers need.
The break-even point is not an endpoint count. It is the cost of connecting and governing the same capability repeatedly across AI consumers.
Keep the Backend API-First and the Agent Edge Capability-First
An enterprise cannot rebuild its backend every time an agent runtime changes. Today’s consumer might be Microsoft Foundry; another managed agent platform might come next. ChatGPT, Salesforce, an internal Copilot, and n8n workflows may also consume capabilities at the same time.
I would keep the backend business contract stable and make its agent-facing exposure adaptable. In one line: stabilize the backend around APIs, expose the agent edge around capabilities, and add MCP where its reuse, interoperability, and governance value exceeds its operating cost.
REST can remain the system’s business contract. MCP can become a common surface through which agents and AI clients discover and use selected capabilities. Hosted MCP can reduce the work of exposing vendor-native capabilities; custom MCP earns its place when reuse across consumers becomes substantial.
The question I would ask first is: which capability should be exposed, to whom, in what context, under which authority, and through what contract?