What Developers Are Saying About MCP Servers

The useful argument about MCP servers is not a product announcement. It is the one developers are having with each other, in public, about setups they actually run.

I read two places where that argument is specific: Reddit, in r/ClaudeAI, r/ClaudeCode, and r/AI_Agents, and Hacker News. The quotes below are from those threads. Percentages in them are the speaker's opinion unless the sentence says how they measured it. Several replies under the Reddit threads are pitches for a gateway or a token monitor. I left those pitches out and kept the replies that describe a setup the person is running.

The window is spent before you type

On June 28, 2026, u/Nit222 asked r/ClaudeAI how people manage MCP servers that were eating the context window before a session started. Their check: tool definitions from connected servers were taking roughly a third of the window, on every message, whether or not that session called the tools. They also wrote that on Cursor the same problem "caps you at 40 tools total and just drops the rest." That 40-tool cap is their report. This page did not re-test Cursor.

On April 16, 2026, u/Lopsided_Bass9633 told r/ClaudeCode that a new Claude Code session was already down 30 to 50 percent from MCP tool definitions. Integrations they had disabled in the Claude UI still injected instruction blocks. "The toggle in the UI doesn't actually prevent loading." The same day, u/scodgey answered that this was not their default: if the servers are off, they are off, and the check is /mcp and /context in the terminal UI. The complaint shows up in more than one thread. scodgey's session did not behave that way.

The replies that describe a workflow, rather than a product, land on a small rule.

• u/d1smiss3d: treat servers like load-bearing browser tabs. A tiny set stays on. Everything else is a task pack. If a server is unused in the first five minutes of most sessions, it should not pay rent in every window.
• u/anasgoblins: treat tools like backpack weight. Default profile is a boring core (shell, files, git, browser, search, or whatever that person really uses every session). Project profile is only what that project needs. Rare vendor tools stay off until the session asks. They said trimming did more than save tokens. The larger change was fewer wrong-tool calls, and less of an agent looking at what they called "80 shiny buttons."
• u/penmoid: some popular servers are unnecessary. The example was GitHub. "The GitHub MCP server consumes context and adds nothing," because Claude already knows the gh CLI. For a CLI the model does not know, learn it once, write the notes down, and load the notes when the task needs them.
• u/General_Yam_9879: Skill plus CLI, and an MCP server when a specific API schema has to stay current.

Claude Code's own documentation describes the deferral those threads were asking for. Read on November 1, 2026, the MCP page says tool search is on by default: tool definitions stay deferred until Claude needs them, and a session starts with tool names and server instructions rather than every schema. ENABLE_TOOL_SEARCH=auto is a different switch. In that mode, definitions load up front while they total under 10 percent of the context window, and tool search turns on at that line. The default described in the docs is deferral, not the 10 percent threshold. A comment in the June thread pointed at the same docs. Confirm it in the client you run. /context is the check u/scodgey named, and the April thread is the reminder that a disable toggle and a loaded tool can be two different facts.

A command the model already knows

On October 17, 2025, under a Hacker News thread about Claude Skills, cheema33 wrote that MCP servers are overhyped and that about 95 percent of them "are useless and can be replaced with a simple tool call." That is an opinion with a number on it. It is not a count of servers.

dinkleberg answered on the same thread that the obvious part is the part that hurts: a good MCP server can be really good, and a bad one can make the agent worse. Product teams, in that account, were being told to ship a server so the company could say it had an AI product, including teams that did not otherwise have a job for the model.

ojosilva split the pile in the same discussion. Worth having, by that comment: bundled instructions for a non-standard tool, a server in front of a business API the model has never seen, and one shared HTTP endpoint so a team can hand out a tool without handing out another API key. Called context-stuffing: the trivial npx stdio servers that list files in a folder.

The same split is still the thread in September 2026. On September 20, maharshi365 asked "MCP was always a bad idea?" The post drew 335 points. In the comments, blitzar wrote that Claude had been better with the gh command line than with the GitHub MCP. u/penmoid had already used GitHub as the example, on June 28, 2026, in r/ClaudeAI. ex1fm3ta wrote that the Jira and GitLab servers were consuming an excessive amount of tokens, so those jobs moved to the vendors' CLIs: the agent ran --help, and the commands were saved as markdown the session loads when it needs them. They still use MCP for internal tools and for a few jobs (sampling, long-running notifications) where a server was the shorter path. 0x445442 put the cost in one sentence: MCP servers "encourage token burn at runtime when a deterministic program that uses the API should be used."

socketcluster agreed the protocol had been stretched past its job, and wanted a skill file plus curl as the usual mechanism, with MCP kept for the band between "one HTTP call would do" and "do not give the agent the whole internet." rimeice pushed the other way. In their experience the frontier models still waste tokens hunting parameters, and the cheaper models people actually run in production still need the extra help.

The key stays outside the agent

simonw's reply at the top of that September thread is the defense that survives the CLI argument. A terminal agent with open internet access can call APIs itself, and MCP is optional there. The case he makes is the tighter setup:

1. Control over which external services the agent can reach.
2. Authentication that does not let the agent read the API key.
3. A way for a person to connect another service without pasting a secret into a config file.
4. An audit log of what was called.

His line: "MCP makes all of that so much easier to provide." He also wrote that, in practice, he believes tools are 95 percent or more of what people use MCP for. Resources, prompts, and elicitation are in the spec. He had not seen elicitation implemented, and he had not seen resources or prompts in widespread use. That is a different 95 percent from cheema33's. One is a claim about how many servers a normal function could replace. The other is a claim about which part of the protocol people actually call.

prescriptivist described a setup that uses the protocol for the boundary, not for the schema. Sandboxed Claude Code instances share files that live on AWS. The agents cannot see the AWS keys, and they do not know the files are on AWS. They get MCP tools for a private URI (agentfiles://...). An orchestrator outside the sandbox does the read and the write, and both sides keep logs.

butterNaN uses a server that can only make GET requests, wrapped around tools they already have. The reason they gave: a hard limit is more reassuring than a line in the context that says "don't do this." They know a CLI wrapper could do the same job. They want the path to be agent, then server, then the tool, so the surface is the thing they listed.

woodpanel, replying to simonw, did not buy the happy version of that story. They had seen the security pitch land in companies. Then they wagered, in their words, that "1-10% are spending this extra effort, while 90% of users basically run shims" in front of APIs those users cannot govern well. Keep the percentages inside that wager. Nobody in the thread measured them.

brookst, on the October 2025 thread, named the other half of the trust problem. An MCP server works only as long as you trust the provider, and a provider's incentive is to convince the model that its service is the right one. "There's a fundamental misalignment of incentives between publishers and consumers of MCP."

What broke once someone other than the author called it

On June 1, 2026, u/Sea-Plum-134 asked r/AI_Agents who was running MCP for real users, past a localhost demo. The headaches they listed were not tool design. Client registration failed halfway through a flow. Refresh tokens lived longer than the user's session. Explaining scopes made people think the app was stealing their data. They later wrote that the refresh-token case was the one that bit them, and that they tied the token lifetime to the session, with a hard cap, and tried to make signing in again cheap.

u/nastywoodelfxo said the registration flake shows up when tools are chained: one server times out mid-flow and the registration state gets stuck. They stopped inventing friendlier names for scopes and showed the raw scope, because every abstraction they tried was more confusing than the technical term. The surprise was tracing. There is, in their words, no standard way to follow a request that fans out to three MCP servers and comes back. They added their own correlation IDs and said that belonged in the spec.

u/Ok-Engine-5124 described the refresh-token failure as quiet. Nothing errors. "The token is technically valid, the session context is gone," and the result is a half-authorized state that looks fine until a user complains. Their rule was to tie the token to the session and fail loudly when the two drift. Half-finished client registration got the same treatment: "Half-registered clients are worse than failed ones because they look connected." On the scope screen, they stopped explaining the scope string. At the moment of consent they stated the consequence: what the app can see, and what it cannot change, run, or delete.

u/Legitimate_Key8501 runs MCP internally only, a Storybook server inside a Claude session for component work, and wrote that every look at a public server people would authenticate against ended at the auth story.

What the threads agree to do

Taken together, the comments are a buying rule with three lines.

1. If the model already knows a CLI for the job, the server is a tax. GitHub is the example both sites used. Start with gh. Save --help into a note if the CLI is one the model has to learn.
2. If the server is how a credential stays out of a shell the model can read, it is doing simonw's job. A sentence in the prompt is not that job. butterNaN's GET-only wrapper is the shape: the tool cannot perform the write, so the model cannot talk the tool into the write.
3. If you connect a server, leave it off until the task asks. Core tools in the window. The rest are task packs. Then read /context. A switch labeled off has already failed at least one person in these threads.

A schema for a call the model can already make is an expensive duplicate. A server that holds the key, and cannot do the dangerous call, is a boundary. A server left on from the last project is a bill you pay before the first word of the task.

Quick answers

Is "95 percent" a measurement?

No. cheema33 used it on October 17, 2025 for how many MCP servers a simple tool call could replace. simonw used "95%+" on September 20, 2026 for how much of real MCP use he believes is just tools. Both are labeled as what that person thinks.

Does Cursor drop servers after 40 tools?

u/Nit222 reported that cap on June 28, 2026. This article does not confirm it against Cursor's docs. Treat it as one user's account of their client.

Does Claude Code still load every tool schema at startup?

Its MCP docs, read on November 1, 2026, say tool search defers schemas by default, and that ENABLE_TOOL_SEARCH=auto is the mode with a 10 percent threshold. Check /context in the build you run. The April 16 thread is a person whose disable toggle did not match what the session loaded.

Did these threads conclude that MCP is finished?

A few comments say so. The people describing production setups did something narrower. They dropped servers that duplicate a CLI they already trust, and they kept a server where it draws a permission line the prompt cannot draw. The June production thread is about OAuth registration, token lifetime, scope copy, and tracing. Those are the problems that showed up after the demo worked.

Related

• r/ClaudeAI — a third of the window, June 28, 2026
• r/ClaudeCode — 30 to 50 percent, April 16, 2026
• r/AI_Agents — running MCP past localhost, June 1, 2026
• Hacker News — cheema33, October 17, 2025
• Hacker News — "MCP was always a bad idea?", September 20, 2026
• Claude Code docs — MCP, including tool search
• Don't put secrets in MCP headers
• Paste-a-key is dead
• stdio, HTTP, hosting, and secrets