MCP or API is usually the wrong binary. Use a direct API call when the application already knows the exact operation and the code should own its execution path. Add MCP when an AI application needs to discover a limited set of capabilities and select one for the request. In many production designs, MCP presents those capabilities to the agent while existing APIs remain the business contracts underneath.
Make the choice per capability, not per stack. Finding a record, drafting a response and sending a message have different effects. They should not inherit the same integration decision merely because one agent touches all three.
MCP and APIs sit at different layers
An API tells one software system how to request an operation from another: inputs, outputs, errors and business rules. The calling code will usually know which operation it wants.
MCP defines an exchange between an AI host, its MCP clients and servers that provide context or capabilities. The stable 28 July 2026 specification uses JSON-RPC and distinguishes resources, prompts and tools.[1] The host creates a dedicated client for each server and remains responsible for how its model receives and uses the context.[2]
An MCP tool can query a database, run a calculation or call an API.[3] That detail removes much of the supposed conflict. The API can stay in place behind the MCP server. One remains the business interface; the other presents a selected capability surface to AI applications.
Current vendor implementations show the layering in practice. OpenAI’s Responses API accepts remote MCP servers as tools alongside function calling, with tool filters and configurable approvals.[6] Anthropic’s Messages API can also connect to remote MCP servers and apply allowlists, denylists or per-tool settings.[7] This proves coexistence inside those products. It does not prove that every MCP client works with every server.
Keep a direct API call for a known transaction
Direct is often easier to reason about when the workflow knows exactly what should happen. A submitted form might create one task using a fixed schema, an idempotency key and a defined response. The model does not need to choose among operations.
A direct API path is a strong signal when:
- deterministic code triggers a fixed operation;
- business semantics should remain explicit in the calling code;
- the write is sensitive or hard to reverse;
- the error and recovery path must not drift into a different tool choice;
- no other AI host needs to discover the capability at runtime.
APIs can be described through OpenAPI documents or SDKs, so “APIs are not discoverable” is too broad to be useful. The important distinction is who chooses the operation at runtime. With a direct call, the application has already made that choice.
Use MCP for a discoverable capability surface
MCP becomes useful when AI applications need a consistent catalogue rather than a hard-coded call path. A client can list the available tools, inspect their schemas and call one. The list may change over time, and the protocol defines change notifications for clients that subscribe to them.[2][3]
Discovery is not permission. The host chooses which servers to connect to, what tools reach the model and how consent is handled. The specification recommends showing users which tools are exposed, making calls visible and allowing users to deny an invocation.[3]
Anthropic’s original 2024 announcement framed MCP as an open standard intended to reduce the custom connectors built between assistants and data sources.[8] That explains the design goal, but it predates the 2026 protocol revision. For an architecture decision, the version actually supported by the host-server pair matters more than the launch promise.
A thin MCP layer over APIs is often the practical design
A narrow MCP server can expose a few stable business capabilities without moving the business system behind them. It may translate a tool such as prepare_record_update into one or more existing API calls. Validation rules, authoritative data and transaction constraints stay in the services that already own them.
This avoids two poor extremes: rebuilding every connector for every AI host, or turning every endpoint into a model-facing tool. A large catalogue gives the model more actions to consider and leaves reviewers with a wider surface. A useful facade selects, names and constrains only the capabilities that belong in the agent’s lane.
Recent comparison pages also land on a layered answer. YouTrust contrasts code-led API integration with an MCP interface aimed at agent use.[9] WorkOS describes MCP over REST services and calls out runtime discovery through tools/list.[10] Both are commercial secondary sources. They help identify the decision intent, while the primary specification should settle protocol details.
Choose capability by capability
Use this matrix to start a design discussion, then test the real system. It is not a universal rule.
| Question | Direct API signal | MCP signal | Hybrid signal |
|---|---|---|---|
| Who chooses the operation? | Code knows the exact action | The AI application selects from bounded tools | The agent selects a capability; the service executes the transaction |
| Must several AI hosts discover it? | No | Yes | Yes, with the underlying APIs unchanged |
| Is the effect sensitive or irreversible? | Prefer the deterministic contract | Minimise exposure and require approval | MCP retrieves or prepares; a bounded API writes |
| Is the capability local? | A local SDK, CLI or API may be enough | A local transport may fit | Decide for each capability |
| Are version and transport confirmed? | The API contract is known | MCP compatibility is verified | Adapt and test both boundaries |
There is a fourth outcome: expose nothing yet. A capability with no business owner, authorization rule or verifiable end state is not ready for an agent, whatever protocol is available.
MCP does not supply governance or security by itself
MCP is not automatically safer than a direct API. Authorization is optional in the protocol. When it is implemented over HTTP, the specification bases the flow on OAuth 2.1 and asks clients to request the least privilege scopes needed for the operation.[4]
Token boundaries need explicit design. An MCP server must verify that an incoming token was issued for that server. If the server then calls an upstream API, it must use a separate token rather than passing through the MCP client’s token. The specification also requires secure token storage and PKCE for the relevant authorization flow.[5]
The protocol does not decide:
- which tools each user or role can see;
- which writes require approval;
- which system is authoritative;
- what the expected effect, idempotency and recovery rules are;
- what trace connects the original request to the final business state.
Untrusted external content creates a separate indirect prompt injection problem. Once the boundary is chosen, put human review at the right point and define AI agent observability. A protocol choice does not remove those controls.
Test portability instead of assuming it
“MCP support” is not one interchangeable feature. Anthropic’s connector currently documents tool calls only and requires a remote HTTP server; it does not directly connect to local STDIO servers.[7] OpenAI documents its own server parameters, tool filtering and approval behaviour.[6] Before changing hosts, compare primitives, protocol version, transport, authentication and extensions on both sides.
The 2026-07-28 revision also makes a common comparison stale. MCP now defines stateless, self-contained requests that carry protocol version and capabilities with each request.[1] A tool may preserve business state through an explicit handle, but MCP does not impose an implicit protocol-level session.[3] Saying “MCP is stateful” without naming a version or implementation is no longer precise enough.
Observability belongs at both boundaries. Record the presented tool, validated arguments, identity and scopes, any approval, the upstream API call, its result and the final business state. The full logging and alerting design belongs in our observability guide. The narrower question here is whether the chosen boundary can be explained, tested and maintained.
A fictional support workflow, split three ways
Consider a fictional support agent that finds a case, drafts a reply and, after human approval, prepares a CRM update.
Case retrieval can be a read-only MCP tool with a small schema and sourced results, allowing more than one AI host to reuse it. Drafting stays in the host because that is where context and tone rules are assembled. The CRM update goes through a bounded business API only after approval, with its expected end state and recovery path defined.
The resulting path may be AI host → MCP client → MCP server → search API for retrieval, followed by approved workflow → business API for the write. MCP replaces none of the APIs. It makes one selected part of the system discoverable to the agent.
Deciding whether to wrap an existing API, expose a few MCP tools or keep a deterministic workflow is architecture work, not a protocol popularity contest. Last Word can map the process and choose the boundary per capability before a limited pilot. Explore our AI and automation services.
Seven checks before a pilot
- Record the MCP version, transport and primitives actually supported by every component.
- Inventory the tools visible to each identity; do not confuse discovery with authorization.
- Verify input schemas, errors and the final state produced by each capability.
- Use minimal scopes and separate the MCP token from the upstream API token.
- Put approval before sensitive writes, and test the refusal path.
- Connect each invocation to a trace and an observable business effect.
- Re-test the host-server pair after a version or tool-catalogue change.
A separate pre-production evaluation should then exercise normal, ambiguous and degraded cases. If the underlying process still lacks a clear contract, scope the workflow through our process automation service and send us the context.
FAQ
Does MCP replace REST APIs?
Usually not. An MCP server can call an existing API and present selected capabilities to an AI application.[3] MCP may replace a custom agent-side connector while the API remains the business contract behind the facade.
Can an AI agent call an API without MCP?
Yes. Application code can call the API directly or use function calling. MCP adds a common client-server contract for discovering and invoking compatible capabilities; it is not a prerequisite for tool use.
Is MCP automatically safer than a direct API?
No. MCP authorization is optional, and safety depends on exposed tools, scopes, token handling, validation and approvals in the implementation.[3][4][5]
Is MCP stateful?
The 28 July 2026 specification defines stateless, self-contained requests.[1] A tool can preserve business state through an explicit handle passed between calls, but that state is not an implicit session imposed by the protocol.[3]
When should MCP and APIs be used together?
Use them together when the API should remain the business contract and MCP should expose a selected subset of capabilities to the agent. This separates discovery and model choice from controlled transaction execution.
Do you need one MCP server per API?
No. Draw boundaries around trust, business ownership and coherent capabilities. Mechanically converting every API or endpoint into its own MCP server adds maintenance without making the agent’s lane clearer.
What should you check before switching AI hosts?
Check protocol version, transport, primitives, extensions, authentication, approval controls and tool filtering. A generic MCP label does not guarantee that two implementations cover the same feature set.[6][7]
Sources
[1] https://modelcontextprotocol.io/specification/2026-07-28 — Model Context Protocol, “Specification”, stable revision dated 28 July 2026, accessed 10 September 2026.
[2] https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture — Model Context Protocol, “Architecture overview”, version 2026-07-28, accessed 10 September 2026.
[3] https://modelcontextprotocol.io/specification/2026-07-28/server/tools — Model Context Protocol, “Tools”, version 2026-07-28, accessed 10 September 2026.
[4] https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization — Model Context Protocol, “Authorization”, version 2026-07-28, accessed 10 September 2026.
[5] https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations — Model Context Protocol, “Authorization Security Considerations”, version 2026-07-28, accessed 10 September 2026.
[6] https://developers.openai.com/api/docs/guides/tools-connectors-mcp — OpenAI, “MCP and Connectors”, no publication date displayed, accessed 10 September 2026. Vendor documentation.
[7] https://platform.claude.com/docs/en/agents-and-tools/mcp-connector — Anthropic, “MCP connector”, version mcp-client-2025-11-20, no publication date displayed, accessed 10 September 2026. Vendor documentation.
[8] https://www.anthropic.com/news/model-context-protocol — Anthropic, “Introducing the Model Context Protocol”, published 25 November 2024, accessed 10 September 2026. Creator announcement.
[9] https://youtrust.com/fr-fr/blog/mcp-vs-api — YouTrust, “MCP vs API : quelle intégration pour l’IA ?”, published 24 July 2026, accessed 10 September 2026. Commercial secondary source.
[10] https://workos.com/blog/mcp-vs-rest — WorkOS, “MCP vs. REST: What’s the right way to connect AI agents to your API?”, published 13 March 2026, accessed 10 September 2026. Commercial secondary source.