Use MCP when a person works inside an AI app and wants the model to pick a connected tool. Use an HTTP API when your own program must make a call every time, in a fixed sequence. MCP is a protocol for AI applications to connect with tools and context; it does not make the underlying HTTP API obsolete. We make Unsame, a Playbook Engine that returns a writing protocol before your model writes.
MCP vs API: What is the difference?
An HTTP API gives your program documented routes and schemas to call. REST is one style of HTTP API; in an MCP vs REST API comparison, MCP standardizes how an AI host discovers tools and other capabilities from a server, then makes them available to a model. The MCP specification defines resources for context, prompts as templated messages and workflows for users, and tools for model-executed functions.
MCP uses JSON-RPC messages. The current transport specification defines stdio for a client-launched local process and Streamable HTTP for a remote server. An ordinary REST endpoint is still an HTTP API with its own paths, methods, status codes, and request body; Streamable HTTP is how an MCP client carries MCP messages, not a synonym for REST.
| Decision | MCP server | HTTP API |
|---|---|---|
| Who initiates the operation? | The AI host connects; the model can select an exposed tool | Your application code calls a known route |
| Where does it run? | A local server over stdio or a remote server over Streamable HTTP | A client sends an HTTP request to the service |
| Who controls whether it runs? | Usually the model at run time, subject to host policy and user approval | Your code can call on every run or under a precise condition |
| Authentication | For HTTP authorization, MCP defines an optional flow based on OAuth 2.1; actual server setup varies | Your client obtains and sends the credentials required by that API |
| Portability | One MCP server can be added to any host that supports MCP | Each application implements the provider's API contract or uses an SDK |
| Best fit | A person asks an AI app to use tools as the conversation needs them | A pipeline has a required step, schedule, or branching rule |
The MCP tool specification makes tool invocation model-controlled by default, while recommending that the host show tools and allow people to deny calls. HTTP keeps the call site in your code, where you can require, skip, retry, log, or branch around it. Pick based on where you need that decision to live.
MCP vs function calling: are they the same?
No. Function calling is a model API feature: your application sends tool definitions, receives a structured tool call from the model, runs the corresponding code, and sends the result back. MCP standardizes how an AI host can discover and connect to tools; function calling describes how a model can request a tool action within a model interaction.
In OpenAI's function-calling guide, the documented flow has the application execute the function after receiving the model's call. Anthropic's tool-use guide likewise describes client tools that your application runs. You can set a tool choice to required in supported APIs when the call must happen; otherwise the model can decide whether to call. Function calling does not force you to hand workflow control to the model.
Choose function calling when you own the AI application and want to define tools directly in that app. Choose MCP when you want a compatible AI host to connect to a server through a shared protocol, or when people should use the same service from different AI apps. Both can wrap or invoke APIs underneath.
When should you choose MCP, HTTP, or both?
Choose by asking one question: who must decide that this operation runs? If the answer is “the user's AI app, based on the conversation,” start with MCP. If the answer is “my code, on every generation or under a rule I control,” call the HTTP API. If a workflow mixes both, keep required steps in code and let the model choose only the conversational steps.
For example, a person drafting replies in Claude can connect a remote MCP server and ask the assistant to use it during the chat. A service generating posts in a queue should call HTTP before every model request, check the API response, and insert the result itself. A hybrid app could fetch required account facts through HTTP, then let the assistant call an MCP search tool if the user asks a follow-up question.
How does the same Unsame operation work over MCP and HTTP?
Both paths ask Unsame for a protocol before the writing model drafts. With MCP, the model calls the advise tool from the connected engine server. With HTTP, your backend calls POST /v1/advise, puts draws[0].advice into the model prompt, and reports the outcome afterward.
From an AI app over MCP. Connect the Unsame engine server at https://api.unsame.io/mcp/engine, complete OAuth sign-in, and turn the connector on for the chat. A goal page supplies a prompt like this:
Before you write each piece for this goal, call Unsame's advise tool with goal `threads_posts` and scope `clayandfire`. Use this same scope every time for this account. Follow the instructions it returns. After I tell you whether I used or rejected the draft, report that outcome to Unsame.Ask the assistant to list goals if you need the goal ID. The MCP authorization specification makes authorization optional overall and bases HTTP authorization on OAuth 2.1; Unsame's remote servers use OAuth 2.1, so sign in through the host rather than pasting an API key.
From your backend over HTTP. Create an API client in Unsame, use client credentials at https://api.unsame.io/oauth/token with grant_type=client_credentials, client_id, client_secret, and scope=advise, then send the access token to the API. Routes live under https://api.unsame.io/v1.
curl -X POST 'https://api.unsame.io/v1/advise' \
-H "Authorization: Bearer $TOKEN" \
-H 'Content-Type: application/json' \
-d '{"goal":"your_goal","scope":"your_scope","input":{"text":"…"},"facts":["…"],"k":1}'The documented response contains batch_id, playbook_version, situations, hooks, facts, draws, and miss. Each draw includes draw_id, way, axes, advice, and reason. Put draws[0].advice into the prompt you send to your writing model. When the user reports whether the draft was used, send the draw ID and outcome to POST /v1/report; reporting is free. The full route and field list is in the HTTP API docs.
For the host-side setup steps in Claude, Codex, ChatGPT and Cursor, see Unsame's connect docs.
What can fail on each path, and how do you fix it?
On MCP, first check whether the chat has the connector enabled and the server authenticated. A configured server is not necessarily available in every conversation. Then check that the goal exists by asking the assistant to list goals. Even with the tool connected, a model may not call it; make the instruction explicit, or use a code-owned HTTP call when the operation is mandatory.
On HTTP, handle the documented status and error instead of sending a weaker prompt or silently continuing:
| Failure | Meaning | Fix |
|---|---|---|
401 unauthenticated | Token missing, invalid, or expired | Obtain a valid client-credentials token and send it as a Bearer token |
429 rate_limited or quota_exceeded | Rate or credit limit reached | Respect Retry-After; surface quota exhaustion instead of using a fallback protocol |
413 input_too_long | Input exceeds 8,000 characters; content is not truncated | Shorten the input before retrying |
503 judge_unavailable | The judge could not return a protocol | Treat the generation step as failed; there is no keyword fallback |
Other documented responses include 400 invalid_request or invalid_playbook, 403 insufficient_scope, 404 unknown_goal/node/draw, and 409 version_conflict when using If-Match. The HTTP API reference lists all routes and errors. For a required pipeline step, stop on these errors and decide in your own code whether the job should be retried or shown as failed.
What should you choose?
Use MCP when a person is working in an AI app and the model should decide when to call a connected service. Use HTTP when your own pipeline must call on every generation, deterministically. Use both when a fixed code step and a conversational tool call serve different parts of the same workflow.
We don't claim MCP is faster, cheaper, or a replacement for APIs. We make Unsame; you can start with a free account and try the path that fits your workflow. Sign up.
— Don
