What an assistant connection actually costs

Every tool in this category now has an MCP page. We checked twelve social listening and brand monitoring products: nine ship an official MCP server. Only two publish a list of the tools they expose. None documents a rate limit. And not one has written anything about what it is actually like to put a mentions feed inside an assistant.

That gap is not an accident. For most of this category the agent surface arrived late — a wrapper around an existing REST API, priced as an upsell on the plan above yours. We built the API, the MCP server and the webhooks as one surface from the start, under one set of scopes, because an assistant reading your mentions was the product rather than a feature added when the protocol got attention.

So here is what that actually involves, including the parts that are unflattering to us.

Context is rent, and you pay it before anyone asks a questionCopy Anchor Link

Every tool your server exposes — its name, its description, its JSON schema — is injected into the model's context on every single request. You pay for that whether the tool is used or not.

This is not a critic's framing. It is the MCP maintainers' own, from their roadmap:

Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question.

They add, in the same post, that "tool selection tends to get worse as the list grows."

But most of the horror stories are measurement errorsCopy Anchor Link

Here is where the genre goes wrong, and it is worth knowing before you panic about your context window.

If you have seen someone screenshot Claude Code's /context and point at an enormous MCP number — that number is roughly three times too big. /context calls the token-counting API once per tool and sums the results, so Anthropic's hidden system prompt gets counted once for every tool you have. One careful measurement put the real cost of a tool set at 14,081 tokens against 45,018 as reported.

The second correction is scale. Across 8,127 servers and 165,779 tool schemas, the median server costs 1,920 tokens. The monsters are real but they are the tail: GitHub's full server is 14,406 tokens across 86 tools. Even the widely-quoted "GitHub MCP eats 55,000 tokens" is the all-93-tools figure — its default 26-tool set is closer to 4,000.

So: context rent is real, the median bill is small, and a lot of the alarm is an artefact of one tool's reporting bug.

The cost that is real is tool countCopy Anchor Link

The number of tools matters more than their size, and this one has proper evidence behind it.

GitHub cut Copilot's default toolset from about 40 tools to 13 and measured the result: success rates improved 2 to 5 percentage points on SWE-bench Verified and SWE-Lancer, with both GPT-5 and Sonnet 4.5. Not faster — more accurate, with fewer tools. Their conclusion is worth quoting: "giving an agent too many tools doesn't always make it smarter. Sometimes it just makes it slower."

Anthropic reports the same shape from the other direction: hiding tools behind a search step took Opus 4.5 from 79.5% to 88.1% on their internal evaluation.

And an academic study — MCPGauge, roughly 20,000 API calls across six commercial models — found that adding MCP "generally degrades LLM effectiveness across the three task domains, averaging 9.5% performance decline," with input token volume growing between 3.25× and 236.5×.

Read that carefully, because it is the least comfortable finding here and the vendors quoting MCP as a feature never mention it. Connecting a tool server can make a model worse at the job. What determines which way it goes is how few, and how well-designed, the tools are.

Anthropic's own guidance says the quiet part:

More tools don't always lead to better outcomes. A common error we've observed is tools that merely wrap existing software functionality or API endpoints.

OpenAI's guidance lands in the same place: aim for fewer than 20 functions at the start of a turn, and under ten per namespace.

Which is why our server exposes a small surface rather than one tool per REST endpoint. Search mentions, read one, manage keywords, act on a mention. If you want the full endpoint list, that is what the REST API is for.

Results are the other half of the bill, and nobody warns youCopy Anchor Link

Tool definitions cost you before the conversation. Tool results cost you during it, and this is where a mentions feed gets dangerous — a broad query over months of data is thousands of rows, each with text, relevance, labels and metadata.

The limits are worth knowing because they are client policy, not protocol. The MCP specification sets no result size limit at all. Every client invented its own:

And the detail that catches server authors out: tools/call is not paginable. MCP's cursor pagination covers tools/list, resources/list and their siblings — not tool results. If your tool can return a thousand mentions, you build the pagination into your own schema, because the protocol will not help you.

That is the difference between a tool that returns "the 20 highest-scoring mentions this week, with a cursor" and one that returns everything and blows up the conversation. Anthropic's own advice is the right mental model: an agent reading every row to find one is "searching for a contact in your address book by reading each page from top-to-bottom."

The tell is where they put it on the price listCopy Anchor Link

If a company built for agents, the agent surface is the front door. If it retrofitted, the agent surface is an upsell. That is visible from the outside, because pricing pages do not lie about priorities.

Here is the cheapest plan that includes an MCP server, across the nine that ship one:

We are not going to claim we are the only company thinking about agents — we are plainly not. Octolens publishes a 23-tool server on every plan and is the only vendor in the category that documents its tool list properly, which is more than most manage. Brand24 includes MCP on every tier while charging $149 extra for REST access.

But there is a difference between putting agents on the roadmap and building for them. Anthropic's own guidance names the retrofit pattern directly: "a common error we've observed is tools that merely wrap existing software functionality or API endpoints." A server with one tool per REST route is a REST API wearing a costume, and it inherits the cost we measured above — you pay for all of it, on every request, whether you use it or not.

The version we shipped is a small tool surface, the same scopes as the REST API, on the free plan. Not because we are more virtuous, but because we did not have an existing API to bolt a wrapper onto — the agent was the design brief.

The thing MCP cannot do, which matters more for us than for mostCopy Anchor Link

MCP has no way to wake your agent up.

There is no mechanism for a server to say "something happened." subscriptions/listen covers protocol events — the tool list changed, a resource updated — not your data. An assistant learns about a new mention when somebody asks it to look.

For a coding tool that is fine. For an alerting product it is the whole problem. The most valuable mention you will get this month arrives at 2am on a Saturday, and MCP has nowhere to push it.

So we did not build the alerting on MCP, and our API docs have said the honest thing since before we shipped a server: for a continuous feed, webhooks push to you and cost neither of us a polling loop. MCP is for asking questions. Webhooks are for being told.

If a vendor's MCP page implies you can replace your alerting with an agent, ask them how the agent finds out.

The security shape is uncomfortable, and specifically so for listening toolsCopy Anchor Link

Simon Willison's lethal trifecta is the clearest framing: risk appears when a system combines access to private data, exposure to untrusted content, and a way to send data outward.

A social listening tool supplies the second leg by construction. Our entire product is untrusted text written by strangers on the internet. If you hand an agent a key that can also read your private data and act on it, you have assembled all three yourself.

This is not hypothetical. The clearest worked example is Supabase, which drew 848 points and 470 comments on Hacker News. Row-level security was correctly enabled. The policies were right. The agent ran with a service_role key because that is what it needed to do its job — and service_role bypasses RLS by design. An attacker filed a support ticket containing instructions, a developer asked their assistant to read the latest ticket, and the agent read a token table and wrote the secrets back into the public thread.

Nothing was misconfigured. The privilege the tooling needed was the vulnerability.

The wider picture is worse than most people assume. A measurement study of 7,973 live remote MCP servers found 40.55% expose tools with no authentication at all, and of 119 testable OAuth-enabled servers, every single one had at least one authentication flaw.

What we do about it is unglamorous. Keys are scoped — mentions:read gives you an assistant that can read and summarise and cannot change anything, which is the right default for a client you paste a credential into. Keys expire. And FishOut drafts replies but never posts them: sending happens from your account, by you. That last one is not a missing feature.

One piece of practical advice worth more than any vendor's assurance: call tools/list yourself before you trust a server. We found a product in this category whose page lists "create or edit filters" under not exposed, and whose live server returns a tool that does exactly that — with a description warning it "may remove existing filters." Marketing copy is not a permissions model. The tool list is.

Where the clients actually differ, and where we honestly standCopy Anchor Link

The thing that decides whether a normal person can use your server is authentication, and it splits the world in two.

A static Authorization: Bearer header works in Claude Code, Cursor, VS Code and the Gemini CLI — anywhere a human can paste a header into a config file.

It does not work in the ChatGPT app, the Claude app or the Gemini app. Those run the OAuth flow themselves. Claude Desktop's custom connector dialog, for instance, takes a URL and optional OAuth client credentials — there is no field for an API key, and no amount of looking will find one.

Today FishOut is in the first group. Our server takes a bearer token, so it works in the developer tooling and cannot be added to the consumer apps. We are building the OAuth side, and until it ships, that is the accurate description. The setup pages say which client does what, per client, with the flags people get wrong, and the playbooks are prompts to paste once it is connected.

Worth knowing if you are building your own: the specification moved under you this year. The 2026-07-28 revision removed the initialize handshake and protocol-level sessions entirely — MCP is now explicitly a stateless protocol — and deprecated Dynamic Client Registration in favour of Client ID Metadata Documents. A lot of MCP writing still assumes sessions that no longer exist.

So is it worth connecting?Copy Anchor Link

Yes, with an honest scope.

It is genuinely good at the thing it is good at: asking questions of your data in the place you are already working, without opening another tab. What did people say about our pricing this week that I should reply to? is a better interface than a dashboard, and it is a real reason we ship the server on the free plan rather than behind a $79 or $159 tier like most of this category.

It is not an alerting system, it will not wake up on its own, and pointing an agent at a firehose of untrusted text with a write-capable key is a decision that deserves five minutes of thought rather than a checkbox.

The most useful thing we can tell you is the thing nobody in this category writes down: look at the tool list, look at the result caps, and ask what happens when nobody is asking.

---

Every figure here links to its source. If we have got something wrong, tell us and we will correct it in place — we have already had to correct two of our own pages while researching this one.