Why five MCP tools beat 496

August 30, 2026

Zernio's MCP server exposes 496 tools: 20 hand-written ones plus one auto-generated per API endpoint. Around 50 stay visible at all times and the rest are found on demand through a search_tools tool. That is documented on their MCP page, and it is a reasonable answer to a real problem.

Ours has five. This is the argument for that, including the parts where more tools would win.

#What an agent actually needs to post

Sit with the task for a minute. An agent posting on your behalf has to do four things:

1. Find out what accounts exist and what they are called
2. Send some text to one or more of them, now or later
3. Check what happened
4. Take back something scheduled that should not go out

That is it. There is no fifth thing. Our surface is:

The interesting move is create_post. Threads, first comments, images, scheduling, queue slots, drafts and tags are all parameters, not tools. There is no create_thread, no schedule_post, no add_first_comment, no create_draft. Every one of those would be a separate tool in a generated catalogue, because each is a separate shape in the REST API. Collapsed into arguments, they are one decision an agent already knows how to make: it is filling in a form, not choosing between five forms.

#The context-window argument

Tool definitions are not free. They are text, they sit in the system prompt, and they are re-sent on every single turn of the conversation.

A tool definition with a handful of described parameters is a few hundred tokens. Fifty of those is a five-figure token bill before the model has read a word of your actual request, on every turn, for the whole session. That is the cost of the "always visible" half of a large catalogue, and the other 446 tools are not free either: they need an index, and search_tools needs enough description to be searchable.

Our five definitions are small enough that the whole surface fits in what one large catalogue spends on its table of contents. In a Claude Code session where the model is also holding your repo, your diff and your conversation, that difference is not academic. It is the difference between a posting integration that costs you nothing to keep loaded and one you feel.

#The discovery cost

The token bill is the obvious cost. The latency and reliability cost is the one that bites.

With five tools, "post this to LinkedIn and X" is two calls: list_connections, then create_post. With a searched catalogue it is at least three, and the first one is a guess. The agent has to decide what to search for before it knows what exists. Search "post" and you get every endpoint with "post" in it, which in a social API is most of them. Pick wrong and you burn a round trip, read a tool definition that turns out to be for something else, and search again.

Every one of those steps is a place to fail. Worse, they fail quietly: the agent does not tell you it went down the wrong branch, it just takes longer and sometimes calls the wrong thing. A tool that is not in context cannot be reasoned about, only searched for, and search is a weaker operation than knowing.

There is a subtler version. When an agent sees all five tools, it can plan across them: it knows create_post returns a postId and cancel_scheduled_post takes one, so it can offer to undo a schedule without another lookup. Cross-tool reasoning needs the tools co-present, and discovery breaks that by construction.

#Read the results, not the status code

Fewer tools only helps if each one returns something an agent can act on. create_post fans out and gives one entry per connection:

One connection failing is a failed item, not a tool error. The agent reports "LinkedIn went out, X called it a duplicate" and offers to reword, because everything it needs to say that is in the response. Tool errors are reserved for problems with the whole call: empty text, a bad scheduledFor, media that is not yours, or none of the slugs matching a connection.

Fanning out across several tool calls instead means holding partial state across turns, and a failure in the middle leaves the agent guessing whether to retry everything or the remainder. One call, one array, no bookkeeping.

#Where breadth genuinely wins

This would be a cheap argument if we pretended a large catalogue never helps. It does, in cases we do not serve.

If your API really has 476 distinct operations, generating a tool per endpoint is the only honest way to expose all of them, and search_tools is the right mitigation. Zernio's approach is a sensible response to genuine surface area, and their 20 hand-written core tools are an admission that generated ones are not enough on their own, which is correct.

Breadth wins when the agent's job is open-ended: analytics across a year of posts, bulk account administration, migrating a workspace, anything where the useful operation is one you did not anticipate. A curated five-tool surface answers those with "you cannot do that here", and sometimes that answer is wrong.

Breadth also wins on coverage guarantees. Ours is curated, so anything not in the five is not reachable from MCP at all. There is no upload tool, so an agent that wants to attach an image uploads it over HTTP with POST /api/v2/media and then names the id in mediaIds. There is no publish tool, so isDraft: true stores a draft and publishing it is POST /posts/{postId}/publish over REST. There are no webhook tools, no profile tools, no queue-configuration tools, and no analytics tools. If your agent needs those, our MCP server is the wrong door and the API is the right one.

Our bet is that the common case is overwhelmingly "post this thing", and that an agent doing the common case well beats an agent that could theoretically do anything.

#What does not work yet

The honest list. The five tools cover posting and nothing else: media upload, draft publishing, webhook management, profile creation and queue settings all require dropping to REST, which means an agent restricted to MCP genuinely cannot do those things. create_post accepts thread and firstComment, but a thread only works on X, Bluesky, Telegram and Mastodon and a first comment only on LinkedIn, so an agent posting a thread to all six connections gets shape_unsupported on the ones that cannot take it, per item. There is no way for an agent to create a connection: that is a browser flow, once, by a human. And we have not run a head-to-head benchmark of task success rates against a large catalogue, so everything above is an argument from how the pieces work, not a measurement. If you run one, we would like to see it, including if it goes against us.

#Try it

The server is hosted, it speaks Streamable HTTP, and it takes the same API key as everything else:

Use a yp_test_ key and it sees only your sandbox connections, which is a good way to count the tools yourself. The MCP docs have the full reference, and our comparison with Zernio covers the rest of the differences, pricing included.