Claude Fable 5 vs Opus 5: which model should your AI agents use?
Fable 5 or Opus 5? Choose by mission difficulty and cost per successful task — not by putting Anthropic’s strongest model everywhere.
10 min read
Should you expose your services to an AI agent through MCP, or give it a REST API?
The wrong question is whether MCP is better than REST. They do not solve the same problem.
A REST API is an explicit HTTP contract between systems. OpenAPI can describe that contract in a standard, machine-readable way.
MCP, the Model Context Protocol, is a standard interface between an AI application and the capabilities it can use: tools, resources, and other context.
The practical difference is less about HTTP transport than about who has to understand and select the operation.
If your software already knows exactly which operation to run, an API is usually enough. If an agent must inspect available capabilities and decide which tool to use, MCP becomes much more useful.
REST API
The software · Known operation
Webhook → create the invoice
MCP
The agent · Capability to discover
Inspect tools, then act
Hybrid
Both · Same domain
MCP on top of the product API
MCP vs REST API in one sentence
A REST API mainly answers: how does a system call a specific capability?
MCP answers: how does an AI application discover and use the capabilities it is given?
In a project-management system, an API can expose “create a card”. The caller already knows the operation, the parameters, the shape, and when to call it.
With MCP, that capability can be a tool: name, description, schema. The agent decides whether it is relevant to the goal.
This is not REST versus JSON-RPC, HTTP versus MCP, or “legacy” versus “AI architecture”. The real split is:
a deterministic call to a known operation, or dynamic selection of a capability by an agent?
REST
MCP
The code knows the endpoint
The agent inspects tools
Fixed, predictable contract
Native capability discovery
Webhook, job, backend
AI host, open-ended mission
OpenAPI describes the API
Tools, resources, prompts
What REST, OpenAPI, and MCP actually standardize
The three names get mixed together. They sit at different layers.
REST structures system calls
Resources and operations over HTTP. An app, worker, or webhook calls a precise operation without asking a model to choose. Fit for sync, triggers, updates, and known automations.
OpenAPI describes the contract
Operations, parameters, bodies, responses, schemas, security. Docs, SDKs, validators, integrations. MCP did not invent machine-readable API descriptions.
MCP faces the AI application
Tools to act, resources for context, reusable prompts. An MCP client asks what is available, presents it to the model, and the model can pick a tool.
Neither is inherently better
They answer different needs. Quality comes from the choice, not from the fashionable protocol.
| Criterion | REST + OpenAPI | MCP |
|---|---|---|
| Object | HTTP API | Capabilities for an AI app |
| Contract | Endpoints, requests, responses | Tools, resources, MCP primitives |
| Consumer | Software, worker, webhook | AI host or agent |
| Who picks the call | The code | Often the model |
| Predictability | Very high | Depends on host and model |
Tool discovery or a fixed contract
Typical mission: “CSV import has been failing since the last release. Analyse the issue and open a card if the bug is confirmed.”
Fully coded orchestration
Fetch the bug, collect facts, analyse, verify, create a card if needed. The process is known. REST or internal calls are enough.
MCP tools
The agent inspects capabilities (read, search, act) and selects based on what it finds. Useful when several actions are possible and the right one depends on the run.
How an agent discovers tools
An MCP server announces tools: name, description, input schema, optionally an output shape. The AI host fetches the list and presents a selection to the model.
The loop becomes: goal → understanding → tool selection → call → result → possible next decision.
With an API called by an application: event → code → known endpoint → result.
Both models are useful. They do not serve the same kind of problem.
MCP tools vs REST endpoints
A REST endpoint usually represents a resource or an application operation. An MCP tool should be a capability an agent can understand and act on.
Mirroring every endpoint as a tool is rarely wise. Agents need a limited, clear, coherent, fairly high-level surface matched to their missions.
A tool does not have to mirror an endpoint. It can be a façade over several services. The API stays the business foundation.
Streamable HTTP, latency, tokens
MCP is not a replacement for HTTP. Remote servers can run over Streamable HTTP. The MCP specification has moved this closer to modern HTTP infrastructure: load balancing, scaling, serverless, recovery when an instance dies. Business state, if any, belongs to the application, not to a mandatory protocol session.
MCP is not inherently slower. application → API → service is a short path. user → model → selection → MCP host → server → API → result → model has more steps. The question is not “does MCP add milliseconds?” but are discovery and dynamic choice required?
MCP does not burn tokens on the wire. Names, descriptions, schemas, results, and resources do occupy context. Five simple tools: negligible. Fifty verbose tools: expensive. Prefer differentiated tools, short descriptions, simple schemas, limited to the agent’s context.
Versioning, auth, security, approvals, audit
REST does not prevent breaking changes. Neither does MCP. A production contract still needs stability, deprecation, and compatibility tests — regardless of protocol.
MCP does not replace identity. You still need to know who is calling, which resources, which actions, which workspace, with which limits. OAuth, JWT, API keys, PATs, service accounts: those are auth mechanisms, not alternatives to MCP.
Comparing “MCP security” with “API-key security” is a category error. MCP is a protocol. An API key is a credential. An overly broad token is dangerous behind REST and behind MCP. Apply least privilege.
When REST, MCP, or both
REST alone
Classic caller, known operation, deterministic workflow, high throughput, transactional, API already used by several systems. Webhooks, billing, cron, CI/CD, batch.
MCP earns its place
Several AI clients, tool discovery, capabilities that depend on context, several tools for one mission, resources to feed the agent, no custom integration per host.
Both
The usual case for a real product. The API remains the business contract. MCP is a façade over the same logic: permissions, validation, transactions, domain.
Same example, two paths
CSV bug → card. REST: a coded workflow, an API call if the result requires it. MCP: the agent picks tools; the underlying API can stay the same.
| Situation | REST | MCP | Hybrid |
|---|---|---|---|
| Classic web backend | Yes | No | No |
| Webhook | Yes | No | No |
| Deterministic automation | Yes | No | No |
| Batch job | Yes | No | No |
| Agent with one known call | Yes | opt. | No |
| Agent choosing among capabilities | No | Yes | Yes |
| Several AI hosts | No | Yes | Yes |
| Stable API plus agents | Yes | No | Yes |
| Agent tools plus public APIs | Yes | Yes | Yes |
| Critical business transactions | Yes | No | Yes |
Simple rule: REST if the software already knows what to call. MCP if the model must discover or select the capability. Both if the product already has an API and now needs to be usable by agents.
Stellary
Stellary follows this coexistence. The platform has a product API and a native MCP server over Streamable HTTP: https://api.stellary.co/mcp. GET for discovery or negotiation, POST for MCP requests. Identity is a PAT or an agent token. Permissions stay Stellary permissions.
The MCP server does not replace the product API. It exposes some capabilities to agents and MCP clients.
To connect a client: connect agents through MCP. For MCP in coding tools: what MCP changes in 2026. Runtime reference: MCP docs. Product view: Stellary MCP server. For execution autonomy: agent, workflow, or automation.
The question is not “should we migrate our API to MCP?”. It is: who uses this capability, and how do they decide to call it?
REST and OpenAPI excel at an explicit contract between systems. MCP helps an AI application discover and use capabilities in a standard frame.
For a modern product with users, integrations, automations, and agents: API as the foundation. MCP as the agent-facing interface. Not MCP instead of REST — MCP on top of REST, when the agent use case justifies it.
FAQ
Does MCP replace a REST API?
No. They can coexist. An API can remain the business foundation; an MCP server exposes selected capabilities to AI agents.
When should you use MCP instead of a REST API?
When the model must discover several capabilities and dynamically pick the tool that fits the mission.
What is the difference between MCP and OpenAPI?
OpenAPI describes an HTTP API contract. MCP defines primitives for AI applications (tools, resources) and a protocol to discover and use them.
Can an AI agent call a REST API directly?
Yes. MCP is not required. A REST API can be called directly, or wrapped as a tool in an agentic architecture.
Is MCP slower than REST?
Not necessarily at the protocol layer. An agentic architecture often adds steps (model, selection, execution, analysis). A direct API call is still better when no dynamic decision is needed.
Is MCP more secure than an API that uses an API key?
That is not a direct comparison. MCP is a protocol; an API key is an authentication mechanism. In both cases you still need identity, permissions, and least privilege.
Does MCP always use Streamable HTTP?
For remote MCP servers, Streamable HTTP is the current standard HTTP transport. Other modes, including local ones, exist depending on the environment.
Should every REST endpoint become an MCP tool?
No. Expose only the capabilities agents actually need, with clear descriptions and schemas, instead of mirroring the whole API.
