Get the top HN stories in your inbox every day.
whoknowsidont
jcelerier
> LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.
but the major user interfaces for operating LLMs do and that's what matters
> Not only do you not need MCP, but you should actively avoid using it.
> Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.
so what's the proven and standard API I can use to interact with ableton live? blender? unity3d? photoshop?
whoknowsidont
[flagged]
nilslice
What do all of the links below have in common? Do you know of another way you can control all of those applications via LLMs? Computer use?
https://github.com/ahujasid/ableton-mcp
https://github.com/ahujasid/blender-mcp
didibus
> MCP was a really shitty attempt at building a plugin framework
Can you go more in depth? The protocol is relatively simple, what about it you feel is "shitty" as a plugin framework?
paulddraper
The hate for MCP here is absurd.
It's JSON-RPC, with some descriptors.
And some comments about OAuth 2.
The value is in the consensus. You can make a tool that agents can connect to with no apriori knowledge.
rcarmo
Actually, MCP wastes a lot of tokens when compared to regular tool calling. You might not notice it on more trendy models with large contexts, but for those of us trying to use locked down/local/cheap models it makes very little sense.
Also, MCP creates a new problem: providing the model with too much context when trying to combine tools across multiple servers. It works OK with small, very focused servers (like helpers for a specific data set), but if you try to mix and match servers things get out of hand really quickly and the entire workflow becomes very unreliable—too many options to digest and pursue, just like humans.
whoknowsidont
>It's JSON-RPC, with some descriptors.
That's not even true. It defines the lifecycle of tool calling.
JSON-RPC with some descriptors would have been fine and amazing.
manbitesdog
Things like OpenAPI have existed for 15 years now and they also offer standarization.
The value on MCP is not on its features or innovation, but on the rate of adoption it has had. Companies have now an incentive to open, document and standarize their APIs to enable this new distribution channel.
block_dagger
Perhaps you haven't used many MCP server, but those that I have used (GitHub, Atlassian, Glean, BuildKite, Figma, Google Workspace, etc) work very well. They teach an LLM how to do exactly what you're saying - "use the API standards...your models/agents directly interact with those API endpoints." Most MCP severs don't sit in between the LLM and the API endpoints, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would. I find it works quite well and seems far better than manually maintaining rules or pointing at docs and installing CLI tools (like "gh" for GitHub) or using curl to interact with APIs from a terminal within a chat session.
cstrahan
> but those that I have used (GitHub, [...])
> Most MCP severs don't sit in between the LLM and the API endpoints [...]
Your first example certainly isn't an example of that: https://github.com/github/github-mcp-server
I suppose someone could try to abuse MCP by stuffing information about REST API endpoints into a the prompt/descriptions in a small MCP "skeleton" service, but I don't know of any. Can you provide examples?
> they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would.
I suspect you might have some deep misunderstandings about MCP.
whoknowsidont
>, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would.
No. MCP does not do this. Function & tool calling is built into the LLM. MCP is not augmenting this ability in ANY way.
paulddraper
> No major models have any direct knowledge of MCP.
Claude and ChatGPT both support MCP, as does the OpenAI Agents SDK.
(If you mean the LLM itself, it is "known" at least as much as any other protocol. For whatever that means.)
whoknowsidont
>it is "known" at least as much as any other protocol.
No. It is not. Please understand what the LLM's are doing. Claude nor ChatGPT nor any major model knows what MCP is.
They know how to function & tool call. They have zero trained data on MCP.
That is a factual statement, not an opinion.
Bockit
This is probably a semantics problem. You’re right. The models don’t know how to mcp. The harness they run in does though (Claude code, Claude desktop, etc), and dynamically exposes mcp tools as tool calls.
choilive
That is an easily falsifiable statement. If I ask ChatGPT or Claude what MCP is Model Context Protocol comes up, and furthermore it can clearly explain what MCP does. That seems unlikely to be a coincidental hallucination.
cookiengineer
> That is a factual statement,
I think most people, even most devs, don't actually know how crappy an MCP client is built, and that it's essentially an MITM approach and that the client sends the LLM on the other end a crappy pretext of what tools are mounted and how to call their methods in a JSON, and then tries to intelligently guess what response was a tool call.
And that intelligent guess is where it gets interesting for pentesting, because you cannot guess anything failsafe.
paulddraper
> They have zero trained data on MCP.
They have significant data trained on MCP.
> They know how to function & tool call.
Right. You can either use MCP to transmit those tool calls, or you can create some other interface.
numpad0
(pedantry)it's something humans are talking about a lot, so up-to-date models do know about it...
undefined
cyanydeez
probably easier to just tell people: You want MCP? Add a "description" field to your rest API that describes how to call it.
That's all it's doing. Just plain ole context pollution. World could be better served by continuing to build out the APIs that exist.
pests
Sometimes the actions you want to perform does not map cleanly into one or two API calls, or would be too messy to assume correct parsing. Maybe your UI is fine POSTing to /users and PUTing to /groups or whatever but giving the LLM a direct CreateUserAndAddToGroup action simplifies the task and keeps context cleaner.
cstrahan
This is very true. But why stop there?
Imagine a future where we have an evolved version of MCP -- call it MCP++.
In MCP++, instead of having to implement a finite list of specialized variants like CreateUserAndAddToGroup, imagine MCP++ has a way to to feed the desired logic (create user, then add that user to $GROUP) directly to the endpoint. So there would be something like a POST /exec endpoint. And then the /exec endpoint can run the code (maybe it's WASM for something)...
Wait a minute! We already have this. It's called programming.
You could have the LLM write code, so that any pipelining (like your example), aggregation, filtering, or other transformation happens in that code, and the LLM only needs to spend the output tokens to write the code, and the only input tokens consumed is the final result.
I definitely am not the first person to suggest this:
https://www.anthropic.com/engineering/code-execution-with-mc...
https://blog.cloudflare.com/code-mode/
... but I can say that, as soon as I read about MCP, my first thought was "why?"
MCP is wasteful.
If you want LLMs to interact with your software/service, write a library, let the scrapers scrape that code so that future LLM revisions have the library "baked into it" (so you no longer need to spam the context with MCP tool descriptions), and let the LLM write code, which it already "knows" how to do.
What if your library is too new, or has a revision, though?
That's already a solved problem -- you do what you'd do in any other case where you want the LLM to write code for you: point it at the docs / codebase.
jes5199
yesss, and OpenAI tried this first when they were going to do a “GPT store”. But REST APIs tend to be complicated because they’re supporting apps. MCP, when it works, is very simple functions
in practice it seems like command line tools work better than either of those approaches
CuriouslyC
Command line tools are my preference just because they're also very useful to humans. I think providing agents function libraries and letting them compose in a repl works about as well but is higher friction due env management.
tacticus
> Add a "description" field to your rest API that describes how to call it.
Isn't that swagger\grpc etc?
EagnaIonat
> Just plain ole context pollution.
It would normally be a second context window to figure out what tool / agent to run.
My only quibble with MCP is in the usual AI bandwagon people are implementing for FOMO than business value. My experience is likely anecdotal though.
mycall
Also, keep your api small as all the tool call, DTOs and user messages (e.g. workflow recipes) add up to big context windows and accuracy confusion, at least in the latest models. I hope that gets resolved.
blitzar
> World could be better served by continuing to build out the APIs that exist.
before LLM's and MCP the world was depreciating or locking down APIs
timClicks
MCP is an example of "worse is better". Everyone knows that it's not very good, but it gets the job done.
voidhorse
Yeah there's no there there when it comes to MCP. It's crazy to me that the world bought into the idea when the "spec" literally boils down to "have your server give the LLM some json". Just illustrates how powerful it is to attach names to things, especially in a hypestorm in which everyone is already frothing at the mouth and reason is hard to come by. Give people some word they can utter to help them sound like they're on the "bleeding edge" and they'll buy into it even if it's totally pointless.
tptacek
"Have your XYZ give the LLM some JSON" is pretty close to how all tool calling works with or without MCP.
what-the-grump
What next you are going to tell me rest and async are implemented in code?! And not just willed into existence by the compiler!
mycall
Markdown is for output too.
anon84873628
It gave everyone a reason to think about the usability of the interfaces they were exposing.
Many endpoints have tons of fields irrelevant to 95% of external users. Now those are gone.
Or they implemented higher level abstractions for the actual tasks instead of making developers compose a bunch of little pieces.
And it has a standardized manifest.
Execs, PMs, and customers having that word to utter as part of the AI hype train created the opportunity for that industry-wide cleanup to happen. Calling it pointless is very naive. It's actually kind of extraordinary.
voidhorse
Thanks for offering another perspective on it. I can buy into this partially.
At the same time, I'm skeptical that this won't just become yet another dead protocol once the hype abates, at which point all of the perceived benefits were for naught.
pjmlp
Fully agree, however we need to reach our KPIs and OKRs regarding AI adoption.
upghost
So I don't disagree with any of the criticisms of MCPs but no one here has mentioned why they are useful, and I'm not sure that everyone is aware that MCP is actually just a wrapper over existing cli/API:
1. Claude Code is aware of what MCPs it has access to at all times.
2. Adding an MCP is like adding to the agent's actuators/vocabulary/tools because unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available and "hey you have access to X" and "hey make an MCP for X" take the same level of effort on the part of the user.
3. This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.
4. You can almost trivially create an MCP that does X by asking the agent to create an MCP that does X. This saves you from having to constantly remind an agent it can do X.
NOTE: I cannot stress enough that this property of MCPs is COMPLETELY ORTHOGONAL to the nutty way they are implemented, and I am IN NO WAY defending the implementation. But currently we are talking past the primary value prop.
I would personally prefer some other method but having a way to make agents extensible is extremely useful.
EXAMPLE:
"Make a bash script that does X."
<test manually to make sure it works>
"Now make an MCP called Xtool that uses X."
<restart claude>
<claude is now aware it can do Xtool>
whoknowsidont
>This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.
No it's not.
Honestly this conversation is extremely weird to me because somehow people are gravely misunderstanding what MCP even purports to do, let alone what it actually CAN do in the most ideal situation.
It is a protocol and while the merits of that protocol is certainly under active discussion it's irrelevant because you keep adding qualities about the protocol that it cannot deliver on.
Just same facts to help steer this conversation correctly, and maybe help your understanding on what is actually going:
* All LLM's/major models have function & tool calling built in.
* Your LLMs/models do not have any knowledge on MCP, nor have they been trained on it.
* MCP exists, at least the claim, is to help standardize the LIFECYCLE of the tool call.
* MCP does not augment or enhance the ability of LLM's in any form.
* MCP does not allow you to extend agents. That's an implicit feature.
* If you have access to "X" (using your example), you don't need anything that obeys the MCP standard.
MCP at best is for developers and tool developers. Your model does not need an MCP server or client or anything else MCP related to do what is already been trained to do.
>I would personally prefer some other method but having a way to make agents extensible is extremely useful.
They already are. MCP does not help with this.
cjonas
This response is spot on. People seem very confused about what MCP actually is. It's just a standard way to provide an LLM with tools. And even how that happens is up to the agent implementation. There are some other less common features, but the core is just about providing tool definitions and handling the tool_call. Useful but basically just OpenAPI for LLM
anon84873628
I think people are really underappreciating the "OpenAPI for LLM" part. The hype forced a lot of different SaaS products and vendors of all stripes to actually follow a standard and think somewhat critically about the usability of what they expose.
smallnamespace
Three facts to consider:
1. CLAUDE.md is not part of the system prompt
2. The Claude Code system prompt almost certainly gives directions about how to deal with MCP tools, and may also include the list of tools
3. Instruction adherence is higher when the instructions are placed in the system prompt
If you put these three facts together then it’s quite likely that Claude Code usage of a particular tool (in the generic sense) is higher as an MCP server than as a CLI command.
But why let this be a limitation? Make an MCP server that calls your bash commands. Claude Code will happily vibe code this for you, if you don’t switch to a coding tool that gives better direct control of your system prompt.
whoknowsidont
>is higher as an MCP server than as a CLI command.
What do you mean by "higher"?
throwaway314155
1.) Awareness doesn’t mean they will use it. And in practice they often don’t use them.
2.) “ unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available” - this doesn’t match my experience. In fact, bash commands are substantially more discoverable.
3.) Again, this doesn’t match my experience and the major providers recommend including available MCP tools in system prompts/CLAUDE.md/whatever.
4.) Can’t speak to this as it’s not part of my workflow for the previous reasons.
The only useful MCP for me is Playwright for front end work.
upghost
Chrome Devtools is similarly an extremely high value MCP for me.
I would agree that if you don't find they add discoverability then MCPs would have no value for you and be worse than cli tools. It sounds like we have had very opposite experiences here.
throwaway314155
Interesting. Perhaps it comes down to which platforms we're working on. I don't want to be outright dismissive of it. My primary platform is Claude Code. Are you working with another driver e.g. OpenAI Codex?
paulddraper
MCP is simply a standardized RPC protocol for LLMs.
That's it.
The value is in all the usual features of standardization -- plug-and-play, observability, pass-through modifications, etc.
whoknowsidont
>observability
Which MCP does the opposite of. It hides information.
lsaferite
How so? The protocol doesn't obfuscate things. Your agent can easily expose the entire MCP conversation, but generally just exposes the call and response. This is no different than any other method of providing a tool for the LLM to call.
You have some weird bone to pick with MCP which is making you irrationally unreceptive to any good-faith attempt to help you understand.
If you want to expose tools to the LLM you have to provide a tool definition to the LLM for each tool and you have to map the LLM's tool calls into the agent executing the tools and returning the results. That's universal for all agent-side tools.
The whole purpose behind MCP was to provide a low-impedance standard where some set of tools could be plugged into an existing agent with no pre-knowledge and all the needed metadata was provided to facilitate linking the tools to the agent. The initial version was clearly focused on local agents running local tools over stdio. The idea of remote tools was clearly an afterthought if you read the specification.
If you want your agent to speak OpenAPI, you are *more* than welcome to make it do so. It'll probably be fine if it's a well-specified API. The context issues won't go away, I guarantee you. OpenAPI specs for APIs with lots of endpoint will result in large tool definitions for the LLM, just like they do with MCP.
A core issue I see with MCP, as someone using it every day, is that most MCP Server developers clearly are missing the point and simply using MCP as a thin translation layer over some existing APIs. The biggest value with MCP is when you realize that an MCP Server should be a *curated* experience for the LLM to interact with and the output should be purposefully designed for the LLM, not just a raw data dump from an API endpoint. Sure, some calls are more like raw data dumps and should have minimal curation, but many other MCP tools should be more like what the OP of this post is doing. The OP is defining a local multi-step workflow where steps feed into other steps and *don't* need LLM mediation. That should be a *single* MCP Server Tool. They could wrap the local bash scripts up into a simple single tool stdio MCP Server and now that tool is easily portable across any agent that speaks MCP, even if the agent doesn't have the ability to directly run local CLI commands.
Anyway, maybe take a breath and be objective about what MCP is and is not meant to do and disconnect what MCP is from how people are *currently* using (and frequently misusing) MCP.
badlogic
Also not disagreeing with your argument. Just want to point out that you can achieve the same by putting minimal info about your CLI tools in your global or project specific CLAUDE.md.
The only downside here is that it's more work than `claude mcp add x -- npx x@latest`. But you get composability in return, as well as the intermediate tool outputs not having to pass through the model's context.
redhale
> 3. This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.
What? Why?
> unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available
I think I'm missing something, because I thought this is what MCP does, literally. It just injects the instructions about what tools it has and how to use them into the context window. With MCP it just does it for you rather than you having to add a bit to your CLAUDE.md. What am I misunderstanding?
cstrahan
You are correct.
I think many here have no idea what exactly MCP is, and think it's some sort of magic sauce that transcends how LLMs usually work.
“But Brawndo has what plants crave! It's got electrolytes! '...Okay - what are electrolytes? Do you know? Yeah. It's what they use to make Brawndo.' But why do they use them in Brawndo? What do they do?''They're part of what plants crave.'But why do plants crave them?'Because plants crave Brawndo, and Brawndo has electrolytes.”
― Idiocracy Movieundefined
nestorD
So far I have seen two genuinely good arguments for the use of MCPs:
* They can encapsulate (API) credentials, keeping those out of reach of the model,
* Contrary to APIs, they can change their interface whenever they want and with little consequences.
the_mitsuhiko
> * Contrary to APIs, they can change their interface whenever they want and with little consequences.
I already made this argument before, but that's not entirely right. I understand that this is how everybody is doing it right now, but that in itself cause issues for more advanced harnesses. I have one that exposes MCP tools as function calls in code, and it encourages the agent to materialize composed MCP calls into scripts on the file system.
If the MCP server decides to change the tools, those scripts break. That is is also similar issue for stuff like Vercel is advocating for [1].
[1]: https://vercel.com/blog/generate-static-ai-sdk-tools-from-mc...
lsaferite
Wouldn't the answer to this be to have the agent generate a new materialized workflow though? You already presumably have automated the agent's ability to create these workflows based off some prompting and a set of MCP Servers.
rsanheim
But …you have to give the MCP the creds somehow. Maybe it’s via a file on disk (bad), maybe via an env var (less bad). Maybe you do it via your password CLI that you biometricly auth to, which involves a timeout of some sort for security, but that often means you can’t leave an agent unattended.
In any case, how is any of this better than a CLI? CLIs have the same access models and tradeoffs, and a persistent agent will plumb the depths of your file system and environment to find a token to do a thing if your prompt was “do a thing, use tool/mcp/cli”.
So where is this encapsulation benefit?
tuananh
mcp is easy to self-host. model? a little less so.
cstrahan
You're not wrong, but I figured I'd point out the cons / alternatives:
> They can encapsulate (API) credentials, keeping those out of reach of the model
An alternative to MCP, which would still provide this: code (as suggested in https://www.anthropic.com/engineering/code-execution-with-mc... and https://blog.cloudflare.com/code-mode/).
Put the creds in a file, or secret manager of some sort, and let the LLM write code to read and use the creds. The downside is that you'd need to review the code to make sure that it isn't printing (or otherwise moving) the credentials, but then again you should probably be reviewing what the LLM is doing anyway.
* Contrary to APIs, they can change their interface whenever they want and with little consequences.
The upside is as stated, but the downside is that you're always polluting the context window with MCP tool descriptions.
tptacek
What's the alternative design where the model has access to API credentials?
baby_souffle
> What's the alternative design where the model has access to API credentials?
All sorts of ways this can happen but it usually boils down to leaving them on disk or in an environment variable in the repo/dir(s) where the agent is operating in.
moneywoes
what about things like rate limiting, how are those implemented, any Goodreads
zombiwoof
[dead]
_ea1k
Yeah, I'm still confused as to why so many people in "AI engineering" seem to think that MCPs are the key to everything.
They are great if you have a UI that you want and it needs a plugin system, obviously.
But the benefits become much more marginal for a developer of enterprise AI systems with predefined tool selections. They are actually getting overused in this space, if anything, sometimes with security as a primary casualty.
lsaferite
If you are writing a bespoke Agent with a constrained set of tools known in advance, MCP is a detriment. All it will do is introduce complexity, fragility, and latency.
If you have that nice Agent and suddenly marketing "needs" it to talk to Super Service A, you either go back into a dev cycle to create a new set of curated tools that live inside the Agent around SSA *or* you make the Agent capable of acting as an MCP Host and configure a new MCP Client connection to an MCP Server offered by the SSA team. If SSA doesn't have their own MCP Server you could potentially leverage a 3rd-party one or write your own as a fully encapsulated project that doesn't live inside the Agent.
MCP isn't meant to be *the* way you provide tools for your Agent, it's meant to prove a *standard* that allows you to easily add off-the-shelf tool sets via simply configuring the Agent.
lemming
Mario has some fantastic content, and has really shaped how I think about my interface to coding tools. I use a modified version of his LLM-as-crappy-state-machine model (https://github.com/badlogic/claude-commands) for nearly all my coding work now. It seems pretty clear these days that progressive discovery is the way forward (e.g. skills), and using CLI tools rather than MCP really facilitates that. I've gone pretty far down the road of writing complex LLM tooling, and the more I do that the more the simplicity and composability is appealing. He has a coding agent designed along the same principles, which I'm planning to try out (https://github.com/badlogic/pi-mono/tree/main/packages/codin...).
clintonb
I like MCP for _remote_ services such as Linear, Notion, or Sentry. I authenticate once and Claude has the relevant access to access the remote data. Same goes for my team by committing the config.
Can I “just call the API”? Yeah, but that takes extra work, and my goal is to reduce extra work.
jngiam1
This is the key. MCP encapsulates tools, auth, instructions.
We always need something for that - and it needs to work for non tech users too
cadamsdotcom
You don’t need formal tools. You only need a bash tool that can run shell scripts and cli tools!
Overwhelmed by Sentry errors recently I remembered sentry-cli. I asked the agent to use it to query for unresolved Sentry errors and make a plan that addresses all of them at once. Zeroed out my Sentry inbox in one Claude Code plan. All up it took about an hour.
The agent was capable of sussing out sentry-cli, even running it with --help to understand how to use it.
The same goes for gh, the github cli tool.
So rather than MCPs or function style tools, I highly recommend building custom cli tools (ie. shell scripts), and adding a 10-20 word description of each one in your initial prompt. Add --help capabilities for your agent to use if it gets confused or curious.
CuriouslyC
To add to this, agents view the world through sort of a "choose your own adventure" lens. You want your help output to basically "prompt" the agent, and provide it a curated set of options for next steps (ideally between 4-8 choices). If your CLI has more options than that, you want to break as much as possible into commands. The goal is to create an "decision tree" for the agent to follow based on CLI output.
didibus
> Each tool is a simple Node.js script that uses Puppeteer Core. By reading that README, the agent knows the available tools, when to use them, and how to use them via Bash.
> When I start a session where the agent needs to interact with a browser, I just tell it to read that file in full and that's all it needs to be effective. Let's walk through their implementations to see how little code this actually is.
Cool, now you want to package that so others can use it? What next?
Put it behind an MCP is an easy approach. Then I can just install that MCP and by choosing it I have all the capabilities mentioned here.
Or in this particular case, a Claude Skill could likely do as well.
But I mean, that's MCP. I don't even really understand the people discussing that MCP is bad or whatever, it's a plug and play protocol so I can package tools for others to use in their preferred agent client.
CLI access also has the issue that if you want to integrate it in an application, well how do you bundle bash in a secure way so your agent can use it? And would you allow users custom tool call, now they can run arbitrary bash commands?
ripley12
I can see where Mario is coming from, but IMO MCP still has a place because it 1) solves authentication+discoverability, 2) doesn't require code execution.
MCP shines when you want to add external functionality to an agent quickly, and in situations where it's not practical to let an agent go wild with code execution and network access.
Feels like we're in the "backlash to the early hype" part of the hype cycle. MCP is one way to give agents access to tools; it's OK that it doesn't work for every possible use case.
badlogic
Oh, I didn't intend this to come across as MCP being useless. I've written this from the perspective of someone who uses LLMs mostly for coding/computer tasks, where I found MCP to be less than ideal for my use cases.
I actually think MCP can be a multiplier for non-technical users, where it not for some nits like being a bit too technical and the various security footguns many MCP servers hand you.
ripley12
That makes sense to me, thanks for the clarification.
emilsedgh
Oh you're misunderstanding MCP here.
MCP was created so llm companies can have a plugin system. So instead of them being the API provider, they can become the platform that we build apps/plugins for, and they become the user interface to end consumers.
moneywoes
what's the difference between that and those providers exposing an api?
dymk
MCP defines the API so vendors of LLM tools like cursor, claude code, codex etc don't all make their own bespoke, custom ways to call tools.
The main issue is the disagreement on how to declare the MCP tool exists. Cursor, vscode, claude all use basically the same mcp.json file, but then codex uses `config.toml`. There's very little uniformity in project-specific MCP tools as well, they tend to be defined globally.
Schiendelman
Maybe this is a dumb question, but isn't this solved by publishing good API docs, and then pointing the LLM to those docs as a training resource?
zby
LLMs were trained on the how we use text interfaces. You don't need to adopt command line for an LLM to use. You don't really need RAG - just connect the LLM to the shell tools we are using for search. And ultimately it would be much more useful if the language servers had good cli commands and LLMs were using them instead of going via MCP or some other internal path - ripgrep is already showing how much more usable it is this way.
moltar
So basically rewrite MCP tools with your own scripts.
MCP is just an API with docs.
The problem isn’t MCP itself. It’s that each MCP “server” has to expose every tool and docs which consumes context.
I think the tools should use progressive reveal and only give a short summary like the skill does. Then agent can get full API of the tool on request.
Right now loading GitHub MCP takes something like 50k tokens.
Get the top HN stories in your inbox every day.
MCP was a really shitty attempt at building a plugin framework that was vague enough to lure people into and then allow other companies to build plugin platforms to take care of the MCP non-sense.
"What is MCP, what does it bring to the table? Who knows. What does it do? The LLM stuff! Pay us $10 a month thanks!"
LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.
Not only do you not need MCP, but you should actively avoid using it.
Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.