MCP vs. APIs: where each belongs

Separate capability discovery from business execution

An API is an interface to software behavior or data. A REST or GraphQL API might expose account records, content entries or order operations. MCP defines an interaction protocol through which compatible clients can use capabilities such as tools and resources. The current protocol reference for this guide is the 2026-07-28 specification.[1]

A common implementation places an MCP server in front of an existing domain API. The server presents a small set of task-oriented tools, validates the tool arguments and calls the application. The application remains responsible for its business rules and resource permissions. Adding the protocol does not make an unsafe API safe.

When a direct API is sufficient

Suppose one internal workflow reads an account, classifies a support case and submits a proposal through three known operations. Its application code already defines the tool schema and call sequence. Introducing MCP may not improve that user experience or reduce meaningful integration work.

• The caller and service are controlled by the same product team.
• The operation set is small and stable.
• There is no immediate need for several compatible clients to discover the same capabilities.
• The current API has a clear authentication, versioning and failure contract.

In that setting, keep the direct integration unless a specific interoperability requirement justifies another layer. You can still design task-oriented tools and a clean authorization boundary without exposing a public MCP server.

When MCP can earn its place

Now consider a content platform used through several compatible agent clients. Each client needs to discover the same supported actions, inspect their input schemas and receive structured results. Maintaining a separate custom integration for every client creates repeated work. A well-designed MCP surface can consolidate that capability contract.

The consolidation is real only if the tools are useful. A single publish_entry tool that validates a draft and returns a clear outcome may be more dependable than exposing dozens of low-level endpoints with ambiguous names. Capability discovery and schema validation still need integration tests against the clients the product intends to support. MCP’s tools specification describes the protocol-level contract; task design remains the publisher’s responsibility.[2]

Authorization still crosses several boundaries

For an HTTP deployment that uses MCP authorization, follow the protocol’s authorization requirements for the applicable revision. Then separately enforce the caller’s rights to each domain resource and action. An access token accepted at the MCP boundary is not proof that the user may modify every account the backend service can reach.[3]

Credentials used downstream need deliberate scope and delegation. Do not treat a model-supplied user ID as the authenticated caller, or use one broadly privileged integration credential as a substitute for user-level policy. The exact design depends on whether the task acts for a person, a tenant-scoped service or another explicitly authorized principal.

A practical migration sequence

1. Choose one representative business task and define its input, output and terminal outcomes.
2. Implement or reuse a domain operation with authorization, validation and duplicate-handling behavior.
3. Expose a narrow MCP tool that preserves those semantics.
4. Test successful calls, denied calls, malformed arguments, timeouts and retries from the supported clients.
5. Add more capabilities only when the task inventory and operating evidence justify them.

Keep protocol errors separate from business outcomes. A client can successfully exchange a message while the requested operation is rejected, pending approval or not known to have committed. Tool results should let the caller distinguish those states without guessing from a paragraph of text.

The decision to record

Document which clients need MCP, which capabilities are shared and which layer owns the business rules. If the answer is simply that MCP sounds more current, keep the API integration and improve its task contract. If several real clients benefit, build the MCP surface as a maintained product interface with versioned tests and a clear owner.