MCP or REST API for your agent: which one to give it, and when

Give your agent MCP when it has to discover what it can do, and a REST API when you already know. MCP buys discovery and one auth flow, and it costs context on every session. A script that posts the same way every night pays that cost for nothing. Here is the line, with numbers.

MCP vs API: the table

Both talk to the same server. The difference is who reads the documentation: the model, or you.

MCP server vs REST API: what actually differs at runtime

MCP is a JSON-RPC 2.0 protocol in two layers: a data layer that defines the primitives, and a transport layer that is either stdio for a local process or Streamable HTTP for a remote one. A server exposes three things: tools (functions the model can call), resources (data it can read) and prompts (templates). The client calls tools/list to find out what exists, then tools/call to run one. Checked on the spec site on October 9, 2026.

That tools/list step is the whole story. A REST API has the same operations, but the list lives in your head and in your code. With MCP the list arrives in the model's context window, in full, before it has decided whether it needs any of it.

Since protocol version 2026-07-28 the protocol is stateless: every request carries the version and capabilities in _meta, and server/discover replaces the old handshake. Practical consequence for you: a remote MCP server can sit behind a load balancer with no sticky sessions, and the tool list comes back with a ttlMs cache hint, so a well-behaved client does not refetch it on every turn.

What an agent does with 103 tools

Here is the concrete case. The PlugKit MCP server exposes 103 tools and 3 workflows, verified on the tools page on October 9, 2026. They are grouped: 18 for campaigns, 13 for posts, 12 for Meta ads, 10 for accounts and connections, 9 for messaging, 7 for analytics, 7 for engagement, down to 2 for search.

An agent asked to "reply to the comments on my last Reel" needs maybe four of those 103. The other 99 still entered its context, with their names, descriptions and input schemas. That is the tax.

Three things cut the bill, and all three are real today:

1. Scopes. A session holding only mcp:read never gets the write tools registered at all, so the list shrinks before it reaches the model. The scopes are mcp:read and mcp:write, documented in the MCP overview.
2. Workflows. PlugKit ships three (publish, inbox, report) that clients surface as slash commands. One command replaces a chain of tool calls the model would otherwise have to plan, which is fewer turns and fewer wrong guesses.
3. Progressive discovery. The spec has a pattern for it: a client federating many servers loads tools on demand instead of all upfront. Whether you get it depends on your client, not on the server.

A server with four times the tools has four times the problem. I counted 496 tools on one competitor's MCP in social media MCP servers compared, which is enough to crowd out the conversation it is meant to serve.

When to use MCP

Give the agent MCP when at least one of these is true:

• The next action depends on what it reads. Triage an inbox, decide which comment deserves a reply, notice a post failed and pick a different account. You cannot enumerate those branches in advance, which is exactly what a model is for.
• A human is in the loop. Someone types "post this to Instagram and LinkedIn at 9am". MCP turns that sentence into calls without you shipping a UI.
• You do not want to hold credentials. OAuth 2.1 with PKCE means the client never stores a long-lived secret. The user approves on a consent screen and revokes it the same way.
• The capability set moves. A server that adds tools gets used without you releasing anything.

Connecting it is one line in Claude Code: claude mcp add --transport http --scope user plugkit https://api.plugkit.co/mcp, then /mcp to authenticate. Cursor, VS Code, the Claude apps and ChatGPT in developer mode all take the same URL, per the client docs, checked today.

When to give it the REST API instead

Give it HTTP when the work is decided before the agent runs:

• Scheduled publishing. The payload is known, the targets are known. A POST does it in 200ms with no model in the loop and no token cost: POST /v1/posts with accountIds and publishNow, documented in the publishing guide.
• You need tests. A unit test asserts a status code. It cannot assert that a model will pick create_post over publish_post on a bad day.
• Volume. Thousands of calls an hour through a model is a bill, not an architecture.
• Strict error handling. PlugKit returns 402 when a plan quota or spend cap blocks a call, 429 when you are rate limited, 404 instead of 403 for resources you do not own. Your code can back off on 429 and alert on 402. A model will sometimes read 402 and try again.

The useful detail: on PlugKit every MCP tool maps to a REST endpoint with the same vocabulary and the same ids. So the two are not a fork in the road. You prototype in the agent, read the ids it returned, then move the repetitive half into code without relearning anything.

Give it both, split on determinism

What I actually run, and what I would recommend to anyone building on top of a social media API: code owns everything scheduled and repetitive, the agent owns everything conversational and ambiguous.

For the agent half, the setup is the same whichever client you use: see Claude as a social media manager for what the model handles well and what I will not hand over, and how to give an AI agent social media access for the mechanics underneath.

Where MCP is genuinely worse: you lose determinism, you pay context, and you cannot easily diff two runs. Anyone telling you MCP replaces your API client is selling a protocol, not an architecture.

What it costs

PlugKit is $49 a month for 5 connected accounts, cancel anytime, or $97 a month for 30. The MCP server and the REST API are the same product at the same price, so the choice above is purely technical. Seven days free, no card, with one connected account during the trial. The one metered extra is X: calls are passed through at X's own rate, $0.005 to read a post and $0.015 to publish one, with a $20 default monthly spend cap per account until you set your own. Figures from the billing page, checked on October 9, 2026.

FAQ

What is the difference between MCP and an API?

An API is the interface; MCP is a standard way to hand that interface to a model. An MCP server almost always sits in front of a REST API, exposing the same operations as tools the model discovers at runtime with tools/list instead of endpoints you code against. MCP adds discovery and a uniform auth flow, and costs context.

Is MCP better than a REST API for agents?

Only when the agent needs to choose. If the sequence of calls is known before the run, a REST client is faster, cheaper, testable and deterministic. If the next call depends on what the last one returned, MCP is worth its context cost.

When should I use MCP?

When a human is talking to the agent, when the next action depends on data the agent just read, when you would rather not store a long-lived API key, or when the tool list changes without you shipping a release. Scheduled, high-volume, identical calls are the opposite case.

Does MCP use a lot of tokens?

Every tool definition in the list enters the context: name, description and JSON Schema. On a 103-tool server that is real overhead on every session. Cut it with a read-only scope, which hides write tools entirely, with server-side workflows that collapse several calls into one command, and with a client that does progressive discovery.

Can I use MCP and the REST API at the same time?

Yes, and you should. On PlugKit each MCP tool maps to a REST endpoint with the same ids, so an agent can explore and your cron job can publish against the same accounts. Scopes and keys are separate, so the agent can be read-only while your code keeps write access.

AB

Antoine BlancoFounder of PlugKit. Runs his own Instagram, YouTube and X accounts through the API and MCP server described here.