23 ms·

What if you don't need MCP at all?

237 points by jdkee 11mo ago

emilsedgh 11mo ago
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 11mo ago
  what's the difference between that and those providers exposing an api?
  - dymk 11mo ago
    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 11mo ago
      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?
      - CuriouslyC 11mo ago
        It is. Anthropic builds stuff like MCP and skills to try and lock people into their ecosystem. I'm sure they were surprised when MCP totally took off (I know I was).
        cstrahan 11mo ago
        I don't think there is any attempt at lock in here, it's simply that skills are superior to MCP. See this previous discussion on "Show HN: Playwright Skill for Claude Code – Less context than playwright-MCP (github.com/lackeyjb)": https://news.ycombinator.com/item?id=45642911 https://news.ycombinator.com/item?id=45642911 MCP deficiencies are well known: https://www.anthropic.com/engineering/code-execution-with-mcp https://www.anthropic.com/engineering/code-execution-with-mc... https://blog.cloudflare.com/code-mode/ https://blog.cloudflare.com/code-mode/
      - whoknowsidont 11mo ago
        >but isn't this solved by publishing good API docs, and then pointing the LLM to those docs as a training resource? Yes. It's not a dumb question. The situation is so dumb you feel like an idiot for asking the obvious question. But it's the right question to ask. Also you don't need to "train" the LLM on those resources. All major models have function / tool calling built in. Either create your own readme.txt with extra context or, if it's possible, update the API's with more "descriptive" metadata (aka something like swagger) to help the LLM understand how to use the API.
        riverdweller 11mo ago
        You keep saying that major models have "tool calling built in". And that by giving them context about available APIs, the LLM can "use the API". But you don't explain, in any of your comments, precisely how an LLM in practice is able to itself invoke an API function. Could you explain how? A model is typically distributed as a set of parameters, interpreted by an inference framework (such as llama.cpp), and not as a standalone application that understands how to invoke external functions. So I am very keen to understand how these "major models" would invoke a function in the absence of a chassis container application (like Claude Code, that tells the model, via a prompt prefix, what tokens the model should emit to trigger a function, and which on detection of those tokens invokes the function on the model's behalf - which is not at all the same thing as the model invoking the function itself). Just a high level explanation of how you are saying it works would be most illuminating.
        cstrahan 11mo ago
        The LLM output differentiates between text output intended for the user to see, vs tool usage. You might be thinking "but I've never seen any sort of metadata in textual output from LLMs, so how does the client/agent know?" To which I will ask: when you loaded this page in your browser, did you see any HTML tags, CSS, etc? No. But that's only because your browser read the HTML rendered the page, hiding the markup from you. Similarly, what the LLM generates looks quite different compared to what you'll see in typical, interactive usage. See for example: https://platform.openai.com/docs/guides/function-calling https://platform.openai.com/docs/guides/function-calling The LLM might generate something like this for text: { "content": [ { "type": "text", "text": "Hello there!" } ], "role": "assistant", "stop_reason": "end_turn" } Or this for a tool call: { "content": [ { "type": "tool_use", "id": "toolu_abc123", "name": "get_current_weather", "input": { "location": "Boston, MA" } } ], "role": "assistant", "stop_reason": "tool_use" } The schema is enforced much like end-user visible structured outputs work -- if you're not familiar, many services will let you constrain the output to validate against a given schema. See for example: https://simonwillison.net/2025/Feb/28/llm-schemas/ https://simonwillison.net/2025/Feb/28/llm-schemas/ https://platform.openai.com/docs/guides/structured-outputs https://platform.openai.com/docs/guides/structured-outputs
dennisy 11mo ago
This is incredibly simple and neat! Love it! Will have a think about how this can extended to other types of uses. I have personally been trying to replace all tools/MCPs with a single “write code” tool which is a bit harder to get to work reliably in large projects.
- brouser 11mo ago
  You hit it! I am also thinking of programatic control of DevTools so I made this: https://github.com/devtoolcss/chrome-inspector https://github.com/devtoolcss/chrome-inspector It is a core library and I am extending it to usable tools. Hopefully agents can directly script it.
lemming 11mo ago
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 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/coding-agent https://github.com/badlogic/pi-mono/tree/main/packages/codin...).
Bobaso 11mo ago
Moderne Ai agent tool have have a setting where you can trimm down the numbers of tools from an MCP server. Usefull to avoid overwhelming the LLM with 80 tools description when you only need 1
- the_mitsuhiko 11mo ago
  I don't find that to help much at all, particularly because some tools really only make sense with a bunch of other tools and then your context is already polluted. It's surprisingly hard to do this right, unless you have a single tool MCP (eg: a code/eval based tool, or an inference based tool).
  - stavros 11mo ago
    Don't you have a post about writing Python instead of using MCP? I can't see how MCP is more efficient than giving the LLM a bunch of function signatures and allow it to call them, but maybe I'm not familiar enough with MCP.
    - the_mitsuhiko 11mo ago
      > Don't you have a post about writing Python instead of using MCP? Yes, and that works really well. I also tried various attempts of letting agents to write code that exposes MCP tool calls via an in-language API. But it's just really, really hard to work with because MCP tools are generally not in the training set, but normal APIs are.
      - stavros 11mo ago
        Yeah, I've always thought that your proposal was much better. I don't know why one of the big companies hasn't released something that standardised on tool-calling via code, hm.
- incoming1211 11mo ago
  Remote MCP with API key which has claims works well to reduce the tool count to only that of what you need.
_ea1k 11mo ago
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 11mo ago
  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.
deadbabe 11mo ago
You don't need MCP. You need Claude Skills.
- nextworddev 11mo ago
  Actually you just need a prompt and some tools
  - vidarh 11mo ago
    Skills are basically just a prompt and (optionally) some tools, only with a preamble that means they are selectively brought into context only as needed.
- CuriouslyC 11mo ago
  Claude Skills are just good documentation wrapped into Anthropic's API in a proprietary way that's designed to foster lock-in.
  - sunaookami 11mo ago
    How are skills vendor lock-in when they're just Markdown files that any LLM can read? You are not locked to Anthropic at all.
    - CuriouslyC 11mo ago
      The API runs your skills, it's not client side coordinated. You have to replicate the skill-running behavior locally.
      - sunaookami 11mo ago
        Claude just reads the SKILL.md frontmatter into initial context and when the instructions match it reads the rest of the SKILL.md. Every LLM can do that.
        11mo ago
hendersoon 11mo ago
MCP is convenient and the context pollution issue is easily solved by running them in subagents. The real miss here was not doing that from the start. Well, stdio security issues when not sandboxed are another huge miss, although that's a bit of a derail.
DeathArrow 11mo ago
For Claude Code this approach looks easy. But if you use Cursor you need other approach as it doesn't have a format for tools.
- zby 11mo ago
  The agent in Cursor is constantly using command line tools.
  - DeathArrow 11mo ago
    Sure, but there isn't a standard way to instruct it in how to use new tools. It might not stick to instructions from MD files.
rtcode_io 11mo ago
[flagged]
jrm4 11mo ago
Yeah, "MCP" felt like BS from jump. Basically it's the problem that will always be a problem, namely "AI stuff is non-deterministic." If there was some certainty MCP could add to this equation that would perhaps be theoretically nice, but otherwise it's just .. parsing, a perhaps not "solved" problem, but one for which there's already ample solutions.
- chpatrick 11mo ago
  Why are they nondeterministic? You can use a fixed seed or temperature=0.
  - datadrivenangel 11mo ago
    The whole point of "agentic AI" is that you don't have to rigorously test every potential interaction, which means that even a temperature zero model may behave unexpectedly, which is bad for security.
  - urbandw311er 11mo ago
    Even with zero temperature (and some of the latest models don’t allow that) you’re still not absolutely guaranteed deterministic output.
    - deleted 11mo ago
      [deleted]
    - ares623 11mo ago
      Just repeatable output.
    - chpatrick 11mo ago
      What does deterministic mean in this case?
      - jrm4 11mo ago
        Right, I'm using a perhaps loose definition of deterministic here, as in -- "With AI tools, you cannot 100% predict any output based on input, the way you can with most programming."
whoknowsidont 11mo ago
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.
- cyanydeez 11mo ago
  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.
  - tacticus 11mo ago
    > Add a "description" field to your rest API that describes how to call it. Isn't that swagger\grpc etc?
  - jes5199 11mo ago
    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 11mo ago
      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.
  - mycall 11mo ago
rizky05 11mo ago
[dead]
zby 11mo ago
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.
ripley12 11mo ago
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 11mo ago
  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 11mo ago
    That makes sense to me, thanks for the clarification.
elliotto 11mo ago
[flagged]
- almosthere 11mo ago
  AI is in it's "pre react" state if you were to compare this with FE software development of 2008-2015
  - CuriouslyC 11mo ago
    I think that's being generous, we haven't even had the Rails moment with AI yet. Shit, I'm not sure we've had the jQuery moment yet. I think we're still in the Perl+CGI phase.
  - mountainriver 11mo ago
    We won’t have a rails or react for AI, that’s insane. As it gets smarter you’ll just talk to it lol. All of this is just software engineers grasping to stay relevant
- zby 11mo ago
  AI has lots of this 'fake till you make it' vibe from startups. And unfortunately it wins - because these hustler guys get a lot of money from VCs before their tools are vetted by the developers.
- weberer 11mo ago
  >TrueState unburdens analytics teams from the repetitive analysis and accelerates the delivery of high-impact solutions. Ehh, that's pretty vague. How does it work? >Request demo Oh. Well how much is it? >Request pricing Oh never mind
  - antonvs 11mo ago
    It’s like the email scams that filter people out with bad spelling and obvious red flags. If someone makes it through those hurdles they’re probably a good prospect. You weren’t really thinking of buying it, were you?
fragmede 11mo ago
fwiw, for those on a Mac, osascript can run JavaScript in chrome if you let it.
clintonb 11mo ago
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 11mo ago
  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 11mo ago
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 11mo ago
  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.
sshh12 11mo ago
IMO MCP isn't totally dead, but its role has shrunk. Quoting from my post [1]: "Instead of a bloated API, an MCP should be a simple, secure gateway... MCP’s job isn’t to abstract reality for the agent; its job is to manage the auth, networking, and security boundaries and then get out of the way." You still need some standard to hook up data to agents esp when the agents are not running on your local dev machine. I don't think e.g. REST/etc are nearly specific enough to do this without a more constrained standard for requests. [1] https://blog.sshh.io/p/how-i-use-every-claude-code-feature https://blog.sshh.io/p/how-i-use-every-claude-code-feature
_heimdall 11mo ago
MCP is yet another waste of effort trying to recreate what we had with REST over 20 years ago. Yes, APIs should be self-documenting. Yes, response data should follow defined schemas that are understandable without deep knowledge of the backend. No, you don't need MCP for this. I wish Google would have realized, or acknowledged, that XML and proper REST APIs solve both of these use cases rather than killing off XSLT support and presumably helping to coerce the other browsers and WhatWG to do the same.
nestorD 11mo ago
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.
- zombiwoof 11mo ago
  [dead]
- the_mitsuhiko 11mo ago
  > * 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-mcp-servers-with-mcp-to-ai-sdk https://vercel.com/blog/generate-static-ai-sdk-tools-from-mc...
  - lsaferite 11mo ago
    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.
- tptacek 11mo ago
  What's the alternative design where the model has access to API credentials?
  - baby_souffle 11mo ago
    > 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.
graemefawcett 11mo ago
I agree with what Mario says overall and I can be honest, I don't really use MCP I don't think - at least not what it's intended for (some sort of plugin system for extensbile capabilities). I use it for an orchestration layer, and for that it's great. When MCP itself works it's great. For example, we organize units of work into "detective cases" for framing and the corresponding tool is wanderland__get_detective_case. Spawn a Claude Code session, speak "get up to speed on our current case" and we have instant context loading in a sub-agent session, useful when the Jira ticket requires input from another repository (or two). They're all writing back through the same wanderland__add_detective_case_note call and that routes everything through the central attractor to the active case. Most of the time, the case we're working on was just a "read DVOPS-XXXXX in Jira and create a case for me". That's wanderland_get_jira_ticket (a thin wrapper on the jira cli) and wanderland__create_detecive_case in turn. The secret to mcp is that it breaks a lot, or they forget about it because their context is polluted (or you broke it because you're working on it). But it's just a thin wrapper over your API anyways, so just ensure you've got a good /docs endpoint hanging off that and a built in fetch (or typically a fallback to bash with curl -s for some reason) and you're back up and running until you can offload that context. At least you should be if you've designed it properly. Throw in a CLI wrapper for your API as well, they love those :) Three interfaces to the same tool. The MCP just offers the lowest friction, the context on how to use it injected automatically at a level low enough to pick it up in those natural language emissions and map it to the appropriate calls. And, if you're building your own stack anyways, you can do naughty things to the protocol like like inject reminders from your agenda with weighted probabilities (gets more nagging the more you're overdue) or inject user-guides from the computational markdown graph the platform is built on when their tools are first used (we call that the helpful, yet somewhat forceful barrista pattern, no choice but to accept the paper and a summary of the morning news with your coffee in the morning). Or restrict the tools available based on previous responses (the more frustrated you get, the more we're likely to suggest you read a book Claude). Or when your knowledge graph is spatially oriented, you can do fun things like make sure we go east or west once in a while (variations on related items) rather than purely north south (into and out of specific knowledge veriticals) with simple vector math. MCP isn't strictly necessary for all of this, that could be (and in some cases rightly is) implemented at the API layer, but the MCP layer does give us a simple place to reason about agentic behaviour and keeps it away from the tools itself. In other words, modeling error rates as frustration and restricting tool use / injecting help guides make sense in one layer and injecting reminders into a response from the same system that's processing the underlying tool calls makes sense in another, if the protocol you've designed for such things allows for such two way context passing. Absent any other layer in the current stack (and no real desire to implement the agentic loop on my own at the moment), the MCP protocol seems perfectly suited for these types of shennanigans - view it like something like Apigee or (...) API Gateway, adding a bit of intelligence and remixability on top of your tools for better UX with your agents
orliesaurus 11mo ago
I have a feeling that MCP is going the way GraphQL is going ...
- CuriouslyC 11mo ago
  As abstruse as GraphQL is, it does have legitimate use cases. I say this as someone who avoided it for a long time for aesthetic reasons. MCP on the other hand is all hype.
upghost 11mo ago
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>
- throwaway314155 11mo ago
  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 11mo ago
    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.
zombiwoof 11mo ago
[dead]
yieldcrv 11mo ago
My vote is “don't need MCP” given that a) I have agents in production for enterprise companies that did what they were supposed to (automate a human process, alter the point of the whole division, lower cost, increase revenue) b) the whole industry seems to be failing at doing a) to the point they think its all hype c) the whole industry thinks they need MCP servers and I don’t
jngiam1 11mo ago
There’s too much rage baiting on the internet now; the headlines that take the extreme position get reshared, while the truth is more in the middle.
arjunchint 11mo ago
Hey we actually just released rtrvr.ai, our AI Web Agent Chrome Extension, as a Remote MCP Server that obviates lot of the setup you needed to do. We had the same intuition that the easiest way to scrape is through your own browser and so we expose dedicated MCP tools to do actions, scrape pages, and execute arbitrary code in Chrome's built in sandbox. We give a copy/pasteable MCP url that you can use with your favorite agent/chatbot/site and give those providers browser context and allow them to do browser actions. So compared to Playwright MCP and others that require you to run npx and can only be connected to local clients, with ours you just paste a url and can use with any client. Checkout our recent posts: https://news.ycombinator.com/item?id=45898043 https://news.ycombinator.com/item?id=45898043 https://www.youtube.com/watch?v=B4BTWNTuE-s https://www.youtube.com/watch?v=B4BTWNTuE-s
robot-wrangler 11mo ago
MCP is how you wrap/distribute/compose things related to tool-use. Tool-use is how you insist on an IO schema that LLMs must conform to. Schemas are how you combat hallucination, and how you can use AI in structured ways for things that it wasn't explicitly trained on. And this is really just scratching the surface of what MCP is for. You can throw all that away by rejecting MCP completely or by boiling tool-use down to just generating and running unstructured shell commands. But setting aside security issues or why you'd want to embrace more opportunities for hallucination instead of less.. shelling out for everything is perfect faith in the model's ability to generate correct bash for an infinite space of CLI surfaces. You've lost the ability to ever pivot to smaller/cheaper/local models, and now you're more addicted to external vendors/SOTA models. Consider the following workflow with a large CLI surface that's a candidate for a dedicated LLM tool, maybe ffmpeg. Convert the man page to a JSON schema. Convert the JSON schema to a tool. Add the tool to a MCP server, alongside similar wizards for imagemagick/blender. The first steps can use SOTA models if necessary, but the later steps can all feasibly work for free, as a stand-alone app that has no cloud footprint and no subscription fee. This still works if ffmpeg/blender/imagemagick were private custom tools instead of well-known tools that are decades old. You can test the tools in offline isolation too. And since things like fastmcp support server composition you can push and pop that particular stack of wizards in or out of LLM capabilities. Good luck getting real composition with markdown files and tweaking prompts for tone by adding a "Please" preamble. Good luck engineering real systems with vague beliefs about magic, no concrete specifications for any part of any step, constantly changing external dependencies, and perfect faith in vendors.
_pdp_ 11mo ago
GraphQL works better https://chatbotkit.com/reflections/why-graphql-beats-mcp-for-agentic-ai https://chatbotkit.com/reflections/why-graphql-beats-mcp-for...
cagataycali 11mo ago
select * from protocols # ipc, tcp, http, websockets, ...? MCP and A2A are JSONRPC schemas people follow to build abstraction around their tools. Agents can use MCP to discover tools, invoke and more. OpenAPI Schemas are good alternatives to MCP servers today. In comparison to OpenAPI Schemas, MCP servers are pretty new. my fav protocol is TCP, which I am a proud user of nc localhost 9999. but not everyone have same taste of building software. https://github.com/cagataycali/devduck https://github.com/cagataycali/devduck
rule2025 11mo ago
I still think it's better to have MCP, after all, it's unrealistic for any company to integrate all functions into one
calebhwin 11mo ago
If I may make a suggestion, many problems folks face with MCP would be solved if their agents were JIT compiled, not ran in a static while loop. We've been developing this in case folks are interested: https://github.com/stanford-mast/a1 https://github.com/stanford-mast/a1
- brouser 11mo ago
  Not sure what you are compiling and what static while loop is.
  - cstrahan 11mo ago
    I just skimmed the README. I believe the point is to do something akin to "promise pipelining": https://capnproto.org/rpc.html https://capnproto.org/rpc.html http://erights.org/elib/distrib/pipeline.html http://erights.org/elib/distrib/pipeline.html When an MCP tool is used, all of the output is piped straight into the LLM's context. If another MCP tool is needed to aggregate/filter/transform/etc the previous output, the LLM has to try ("try" is a keyword -- LLMs are by their nature nondeterministic) and reproduce the needed bits as inputs into the next tool use. This increases latency dramatically and is an inefficient use of tokens. This "a1" project, if I'm reading it correctly, allows for pipelining multiple consecutive tool uses without the LLM/agent being in the loop, until the very end when the final results are handed off to the LLM. An alternative approach inspired by the same problems identified in MCP: https://blog.cloudflare.com/code-mode/ https://blog.cloudflare.com/code-mode/
alganet 11mo ago
Instead of tools for humans, and a separate set of tools for machines, we should just make tools for humans+machines. The agent should look at my README.md, not a custom human-like text that is meant to be read by machines only. It also should look at `Makefile`, my bash aliases and so on, and just use that. In fact, many agents are quite good at this (Code Fast 1, Sonnet). Issue is, we have a LONG debt around those. READMEs often suck, and build files often suck. We just need to make them better. I see agents as an opportunity for making friendlier repos. The agent is a free usability tester in some sense. If it can't figure out by reading the human docs, then either the agent is not good enough or your docs aren't good enough.
didibus 11mo ago
> 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?
brouser 11mo ago
You hit it! I am also thinking of programatic control of DevTools so I made this: https://github.com/devtoolcss/chrome-inspector https://github.com/devtoolcss/chrome-inspector Though it is more about debugging CSS, I think we are on the same way: let agents use tool by scripting.
bradgessler 11mo ago
MCP has been a weird ride. I built https://terminalwire.com https://terminalwire.com before MCP was a thing to make it way easier for people to add a CLI/TUI to their web apps/SaaS. Then MCP comes out and AI explodes, sucking all the air out of the room for non-AI tools. Now it seems like AI can work with CLIs better than MCP, so I’m tempted to slap AI integration all over the project to better convey the idea. It’s crazy how quickly MCP has run it’s course and watching an entire ecosystem rediscover things from first principals.
72deluxe 11mo ago
MCP sounds like the modern equivalent of COM, where you could query an object to see what functions it exposed but had zero idea of what they did. MCP is the same: apparently it is LLM-readable, but the explanations of what everything does are human readable, and there is no standard on operations available.
filearts 11mo ago
What I've started experimenting with and will continue to explore is to have project-specific MCP tools. I add MCP tools to tighten the feedback loop. I want my Agent to be able to act autonomously but with a tight set of capabilities that don't often align with off-the-shelf tools. I don't want to YOLO but I also don't want to babysit it for non-value-added, risk-free prompts. So, when I'm developing in go, I create `cmd/mcp` and configure a `go run ./cmd/mcp` MCP server for the Agent. It helps that I'm quite invested in MCP and built github.com/ggoodman/mcp-server-go, which is one of the few (only?) MCP SDKs that let you scale horizontally over https while still supporting advanced features like elicitation and sampling. But for local tools, I can use the familiar and ergonomic stdio driver and have my Agent pump out the tools for me.
- lsaferite 11mo ago
  Horizontal scaling of remote MCP Servers is something the spec is sadly lacking any recognition around. If you've done work in this space, bravo. I've been using a message bus to decouple the HTTP servers from the MCP request handlers. I'm still evolving the solution, but it's been interesting so far.
  - filearts 11mo ago
    This is the interface I landed on to make pluggable 'session hosts': https://github.com/ggoodman/mcp-server-go/blob/b8216cc1830ad78928589932cf5a1a78dd25e2b6/sessions/host.go#L16-L76 https://github.com/ggoodman/mcp-server-go/blob/b8216cc1830ad... It goes a tad beyond the spec minimum because I think it's valuable to be able to persist some small KV data with sessions and users.
moltar 11mo ago
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.
chowfi 11mo ago
Admittedly, the scripts+README approach works well for individual setups and is extremely token-efficient, since it only loads a tiny README and the model can infer how to run the scripts. But that convenience depends on a single local environment—one shell, one OS, etc. MCP is aimed at the opposite scenario: distributing tools to many users without relying on their environments. It provides automatic tool discovery, a server boundary that isolates credentials, and strict control over exposed capabilities. Its heavier JSON-schema definitions exist because they’re machine-readable contracts that behave consistently across clients, whereas CLI tools vary drastically across systems. So while MCP adds context overhead, it solves portability and distribution problems that scripts simply can’t.

237 points by jdkee 11mo ago

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 11mo ago
what's the difference between that and those providers exposing an api?
- dymk 11mo ago
  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 11mo ago
    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?
    - CuriouslyC 11mo ago
      It is. Anthropic builds stuff like MCP and skills to try and lock people into their ecosystem. I'm sure they were surprised when MCP totally took off (I know I was).
      - cstrahan 11mo ago
        I don't think there is any attempt at lock in here, it's simply that skills are superior to MCP. See this previous discussion on "Show HN: Playwright Skill for Claude Code – Less context than playwright-MCP (github.com/lackeyjb)": https://news.ycombinator.com/item?id=45642911 https://news.ycombinator.com/item?id=45642911 MCP deficiencies are well known: https://www.anthropic.com/engineering/code-execution-with-mcp https://www.anthropic.com/engineering/code-execution-with-mc... https://blog.cloudflare.com/code-mode/ https://blog.cloudflare.com/code-mode/
    - whoknowsidont 11mo ago
      >but isn't this solved by publishing good API docs, and then pointing the LLM to those docs as a training resource? Yes. It's not a dumb question. The situation is so dumb you feel like an idiot for asking the obvious question. But it's the right question to ask. Also you don't need to "train" the LLM on those resources. All major models have function / tool calling built in. Either create your own readme.txt with extra context or, if it's possible, update the API's with more "descriptive" metadata (aka something like swagger) to help the LLM understand how to use the API.
      - riverdweller 11mo ago
        You keep saying that major models have "tool calling built in". And that by giving them context about available APIs, the LLM can "use the API". But you don't explain, in any of your comments, precisely how an LLM in practice is able to itself invoke an API function. Could you explain how? A model is typically distributed as a set of parameters, interpreted by an inference framework (such as llama.cpp), and not as a standalone application that understands how to invoke external functions. So I am very keen to understand how these "major models" would invoke a function in the absence of a chassis container application (like Claude Code, that tells the model, via a prompt prefix, what tokens the model should emit to trigger a function, and which on detection of those tokens invokes the function on the model's behalf - which is not at all the same thing as the model invoking the function itself). Just a high level explanation of how you are saying it works would be most illuminating.
        cstrahan 11mo ago
        The LLM output differentiates between text output intended for the user to see, vs tool usage. You might be thinking "but I've never seen any sort of metadata in textual output from LLMs, so how does the client/agent know?" To which I will ask: when you loaded this page in your browser, did you see any HTML tags, CSS, etc? No. But that's only because your browser read the HTML rendered the page, hiding the markup from you. Similarly, what the LLM generates looks quite different compared to what you'll see in typical, interactive usage. See for example: https://platform.openai.com/docs/guides/function-calling https://platform.openai.com/docs/guides/function-calling The LLM might generate something like this for text: { "content": [ { "type": "text", "text": "Hello there!" } ], "role": "assistant", "stop_reason": "end_turn" } Or this for a tool call: { "content": [ { "type": "tool_use", "id": "toolu_abc123", "name": "get_current_weather", "input": { "location": "Boston, MA" } } ], "role": "assistant", "stop_reason": "tool_use" } The schema is enforced much like end-user visible structured outputs work -- if you're not familiar, many services will let you constrain the output to validate against a given schema. See for example: https://simonwillison.net/2025/Feb/28/llm-schemas/ https://simonwillison.net/2025/Feb/28/llm-schemas/ https://platform.openai.com/docs/guides/structured-outputs https://platform.openai.com/docs/guides/structured-outputs

dennisy 11mo ago

This is incredibly simple and neat! Love it! Will have a think about how this can extended to other types of uses. I have personally been trying to replace all tools/MCPs with a single “write code” tool which is a bit harder to get to work reliably in large projects.

brouser 11mo ago
You hit it! I am also thinking of programatic control of DevTools so I made this: https://github.com/devtoolcss/chrome-inspector https://github.com/devtoolcss/chrome-inspector It is a core library and I am extending it to usable tools. Hopefully agents can directly script it.

lemming 11mo ago

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 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/coding-agent https://github.com/badlogic/pi-mono/tree/main/packages/codin...).

Bobaso 11mo ago

Moderne Ai agent tool have have a setting where you can trimm down the numbers of tools from an MCP server. Usefull to avoid overwhelming the LLM with 80 tools description when you only need 1

the_mitsuhiko 11mo ago
I don't find that to help much at all, particularly because some tools really only make sense with a bunch of other tools and then your context is already polluted. It's surprisingly hard to do this right, unless you have a single tool MCP (eg: a code/eval based tool, or an inference based tool).
- stavros 11mo ago
  Don't you have a post about writing Python instead of using MCP? I can't see how MCP is more efficient than giving the LLM a bunch of function signatures and allow it to call them, but maybe I'm not familiar enough with MCP.
  - the_mitsuhiko 11mo ago
    > Don't you have a post about writing Python instead of using MCP? Yes, and that works really well. I also tried various attempts of letting agents to write code that exposes MCP tool calls via an in-language API. But it's just really, really hard to work with because MCP tools are generally not in the training set, but normal APIs are.
    - stavros 11mo ago
      Yeah, I've always thought that your proposal was much better. I don't know why one of the big companies hasn't released something that standardised on tool-calling via code, hm.
incoming1211 11mo ago
Remote MCP with API key which has claims works well to reduce the tool count to only that of what you need.

_ea1k 11mo ago

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 11mo ago
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.

deadbabe 11mo ago

You don't need MCP. You need Claude Skills.

nextworddev 11mo ago
Actually you just need a prompt and some tools
- vidarh 11mo ago
  Skills are basically just a prompt and (optionally) some tools, only with a preamble that means they are selectively brought into context only as needed.
CuriouslyC 11mo ago
Claude Skills are just good documentation wrapped into Anthropic's API in a proprietary way that's designed to foster lock-in.
- sunaookami 11mo ago
  How are skills vendor lock-in when they're just Markdown files that any LLM can read? You are not locked to Anthropic at all.
  - CuriouslyC 11mo ago
    The API runs your skills, it's not client side coordinated. You have to replicate the skill-running behavior locally.
    - sunaookami 11mo ago
      Claude just reads the SKILL.md frontmatter into initial context and when the instructions match it reads the rest of the SKILL.md. Every LLM can do that.
      - 11mo ago

hendersoon 11mo ago

MCP is convenient and the context pollution issue is easily solved by running them in subagents. The real miss here was not doing that from the start. Well, stdio security issues when not sandboxed are another huge miss, although that's a bit of a derail.

DeathArrow 11mo ago

For Claude Code this approach looks easy. But if you use Cursor you need other approach as it doesn't have a format for tools.

zby 11mo ago
The agent in Cursor is constantly using command line tools.
- DeathArrow 11mo ago
  Sure, but there isn't a standard way to instruct it in how to use new tools. It might not stick to instructions from MD files.

rtcode_io 11mo ago

[flagged]

jrm4 11mo ago

Yeah, "MCP" felt like BS from jump. Basically it's the problem that will always be a problem, namely "AI stuff is non-deterministic." If there was some certainty MCP could add to this equation that would perhaps be theoretically nice, but otherwise it's just .. parsing, a perhaps not "solved" problem, but one for which there's already ample solutions.

chpatrick 11mo ago
Why are they nondeterministic? You can use a fixed seed or temperature=0.
- datadrivenangel 11mo ago
  The whole point of "agentic AI" is that you don't have to rigorously test every potential interaction, which means that even a temperature zero model may behave unexpectedly, which is bad for security.
- urbandw311er 11mo ago
  Even with zero temperature (and some of the latest models don’t allow that) you’re still not absolutely guaranteed deterministic output.
  - deleted 11mo ago
    [deleted]
  - ares623 11mo ago
    Just repeatable output.
  - chpatrick 11mo ago
    What does deterministic mean in this case?
    - jrm4 11mo ago
      Right, I'm using a perhaps loose definition of deterministic here, as in -- "With AI tools, you cannot 100% predict any output based on input, the way you can with most programming."

whoknowsidont 11mo ago

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.

cyanydeez 11mo ago
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.
- tacticus 11mo ago
  > Add a "description" field to your rest API that describes how to call it. Isn't that swagger\grpc etc?
- jes5199 11mo ago
  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 11mo ago
    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.
- mycall 11mo ago

rizky05 11mo ago

[dead]

zby 11mo ago

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.

ripley12 11mo ago

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 11mo ago
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 11mo ago
  That makes sense to me, thanks for the clarification.

elliotto 11mo ago

[flagged]

almosthere 11mo ago
AI is in it's "pre react" state if you were to compare this with FE software development of 2008-2015
- CuriouslyC 11mo ago
  I think that's being generous, we haven't even had the Rails moment with AI yet. Shit, I'm not sure we've had the jQuery moment yet. I think we're still in the Perl+CGI phase.
- mountainriver 11mo ago
  We won’t have a rails or react for AI, that’s insane. As it gets smarter you’ll just talk to it lol. All of this is just software engineers grasping to stay relevant
zby 11mo ago
AI has lots of this 'fake till you make it' vibe from startups. And unfortunately it wins - because these hustler guys get a lot of money from VCs before their tools are vetted by the developers.
weberer 11mo ago
>TrueState unburdens analytics teams from the repetitive analysis and accelerates the delivery of high-impact solutions. Ehh, that's pretty vague. How does it work? >Request demo Oh. Well how much is it? >Request pricing Oh never mind
- antonvs 11mo ago
  It’s like the email scams that filter people out with bad spelling and obvious red flags. If someone makes it through those hurdles they’re probably a good prospect. You weren’t really thinking of buying it, were you?

fragmede 11mo ago

fwiw, for those on a Mac, osascript can run JavaScript in chrome if you let it.

clintonb 11mo ago

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 11mo ago
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 11mo ago

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 11mo ago
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.

sshh12 11mo ago

IMO MCP isn't totally dead, but its role has shrunk. Quoting from my post [1]: "Instead of a bloated API, an MCP should be a simple, secure gateway... MCP’s job isn’t to abstract reality for the agent; its job is to manage the auth, networking, and security boundaries and then get out of the way." You still need some standard to hook up data to agents esp when the agents are not running on your local dev machine. I don't think e.g. REST/etc are nearly specific enough to do this without a more constrained standard for requests. [1] https://blog.sshh.io/p/how-i-use-every-claude-code-feature https://blog.sshh.io/p/how-i-use-every-claude-code-feature

_heimdall 11mo ago

MCP is yet another waste of effort trying to recreate what we had with REST over 20 years ago. Yes, APIs should be self-documenting. Yes, response data should follow defined schemas that are understandable without deep knowledge of the backend. No, you don't need MCP for this. I wish Google would have realized, or acknowledged, that XML and proper REST APIs solve both of these use cases rather than killing off XSLT support and presumably helping to coerce the other browsers and WhatWG to do the same.

nestorD 11mo ago

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.

zombiwoof 11mo ago
[dead]
the_mitsuhiko 11mo ago
> * 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-mcp-servers-with-mcp-to-ai-sdk https://vercel.com/blog/generate-static-ai-sdk-tools-from-mc...
- lsaferite 11mo ago
  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.
tptacek 11mo ago
What's the alternative design where the model has access to API credentials?
- baby_souffle 11mo ago
  > 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.

graemefawcett 11mo ago

I agree with what Mario says overall and I can be honest, I don't really use MCP I don't think - at least not what it's intended for (some sort of plugin system for extensbile capabilities). I use it for an orchestration layer, and for that it's great. When MCP itself works it's great. For example, we organize units of work into "detective cases" for framing and the corresponding tool is wanderland__get_detective_case. Spawn a Claude Code session, speak "get up to speed on our current case" and we have instant context loading in a sub-agent session, useful when the Jira ticket requires input from another repository (or two). They're all writing back through the same wanderland__add_detective_case_note call and that routes everything through the central attractor to the active case. Most of the time, the case we're working on was just a "read DVOPS-XXXXX in Jira and create a case for me". That's wanderland_get_jira_ticket (a thin wrapper on the jira cli) and wanderland__create_detecive_case in turn. The secret to mcp is that it breaks a lot, or they forget about it because their context is polluted (or you broke it because you're working on it). But it's just a thin wrapper over your API anyways, so just ensure you've got a good /docs endpoint hanging off that and a built in fetch (or typically a fallback to bash with curl -s for some reason) and you're back up and running until you can offload that context. At least you should be if you've designed it properly. Throw in a CLI wrapper for your API as well, they love those :) Three interfaces to the same tool. The MCP just offers the lowest friction, the context on how to use it injected automatically at a level low enough to pick it up in those natural language emissions and map it to the appropriate calls. And, if you're building your own stack anyways, you can do naughty things to the protocol like like inject reminders from your agenda with weighted probabilities (gets more nagging the more you're overdue) or inject user-guides from the computational markdown graph the platform is built on when their tools are first used (we call that the helpful, yet somewhat forceful barrista pattern, no choice but to accept the paper and a summary of the morning news with your coffee in the morning). Or restrict the tools available based on previous responses (the more frustrated you get, the more we're likely to suggest you read a book Claude). Or when your knowledge graph is spatially oriented, you can do fun things like make sure we go east or west once in a while (variations on related items) rather than purely north south (into and out of specific knowledge veriticals) with simple vector math. MCP isn't strictly necessary for all of this, that could be (and in some cases rightly is) implemented at the API layer, but the MCP layer does give us a simple place to reason about agentic behaviour and keeps it away from the tools itself. In other words, modeling error rates as frustration and restricting tool use / injecting help guides make sense in one layer and injecting reminders into a response from the same system that's processing the underlying tool calls makes sense in another, if the protocol you've designed for such things allows for such two way context passing. Absent any other layer in the current stack (and no real desire to implement the agentic loop on my own at the moment), the MCP protocol seems perfectly suited for these types of shennanigans - view it like something like Apigee or (...) API Gateway, adding a bit of intelligence and remixability on top of your tools for better UX with your agents

orliesaurus 11mo ago

I have a feeling that MCP is going the way GraphQL is going ...

CuriouslyC 11mo ago
As abstruse as GraphQL is, it does have legitimate use cases. I say this as someone who avoided it for a long time for aesthetic reasons. MCP on the other hand is all hype.

upghost 11mo ago

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>

throwaway314155 11mo ago
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 11mo ago
  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.

zombiwoof 11mo ago

[dead]

yieldcrv 11mo ago

My vote is “don't need MCP” given that a) I have agents in production for enterprise companies that did what they were supposed to (automate a human process, alter the point of the whole division, lower cost, increase revenue) b) the whole industry seems to be failing at doing a) to the point they think its all hype c) the whole industry thinks they need MCP servers and I don’t

jngiam1 11mo ago

There’s too much rage baiting on the internet now; the headlines that take the extreme position get reshared, while the truth is more in the middle.

arjunchint 11mo ago

Hey we actually just released rtrvr.ai, our AI Web Agent Chrome Extension, as a Remote MCP Server that obviates lot of the setup you needed to do. We had the same intuition that the easiest way to scrape is through your own browser and so we expose dedicated MCP tools to do actions, scrape pages, and execute arbitrary code in Chrome's built in sandbox. We give a copy/pasteable MCP url that you can use with your favorite agent/chatbot/site and give those providers browser context and allow them to do browser actions. So compared to Playwright MCP and others that require you to run npx and can only be connected to local clients, with ours you just paste a url and can use with any client. Checkout our recent posts: https://news.ycombinator.com/item?id=45898043 https://news.ycombinator.com/item?id=45898043 https://www.youtube.com/watch?v=B4BTWNTuE-s https://www.youtube.com/watch?v=B4BTWNTuE-s

robot-wrangler 11mo ago

MCP is how you wrap/distribute/compose things related to tool-use. Tool-use is how you insist on an IO schema that LLMs must conform to. Schemas are how you combat hallucination, and how you can use AI in structured ways for things that it wasn't explicitly trained on. And this is really just scratching the surface of what MCP is for. You can throw all that away by rejecting MCP completely or by boiling tool-use down to just generating and running unstructured shell commands. But setting aside security issues or why you'd want to embrace more opportunities for hallucination instead of less.. shelling out for everything is perfect faith in the model's ability to generate correct bash for an infinite space of CLI surfaces. You've lost the ability to ever pivot to smaller/cheaper/local models, and now you're more addicted to external vendors/SOTA models. Consider the following workflow with a large CLI surface that's a candidate for a dedicated LLM tool, maybe ffmpeg. Convert the man page to a JSON schema. Convert the JSON schema to a tool. Add the tool to a MCP server, alongside similar wizards for imagemagick/blender. The first steps can use SOTA models if necessary, but the later steps can all feasibly work for free, as a stand-alone app that has no cloud footprint and no subscription fee. This still works if ffmpeg/blender/imagemagick were private custom tools instead of well-known tools that are decades old. You can test the tools in offline isolation too. And since things like fastmcp support server composition you can push and pop that particular stack of wizards in or out of LLM capabilities. Good luck getting real composition with markdown files and tweaking prompts for tone by adding a "Please" preamble. Good luck engineering real systems with vague beliefs about magic, no concrete specifications for any part of any step, constantly changing external dependencies, and perfect faith in vendors.

_pdp_ 11mo ago

GraphQL works better https://chatbotkit.com/reflections/why-graphql-beats-mcp-for-agentic-ai https://chatbotkit.com/reflections/why-graphql-beats-mcp-for...

cagataycali 11mo ago

select * from protocols # ipc, tcp, http, websockets, ...? MCP and A2A are JSONRPC schemas people follow to build abstraction around their tools. Agents can use MCP to discover tools, invoke and more. OpenAPI Schemas are good alternatives to MCP servers today. In comparison to OpenAPI Schemas, MCP servers are pretty new. my fav protocol is TCP, which I am a proud user of nc localhost 9999. but not everyone have same taste of building software. https://github.com/cagataycali/devduck https://github.com/cagataycali/devduck

rule2025 11mo ago

I still think it's better to have MCP, after all, it's unrealistic for any company to integrate all functions into one

calebhwin 11mo ago

If I may make a suggestion, many problems folks face with MCP would be solved if their agents were JIT compiled, not ran in a static while loop. We've been developing this in case folks are interested: https://github.com/stanford-mast/a1 https://github.com/stanford-mast/a1

brouser 11mo ago
Not sure what you are compiling and what static while loop is.
- cstrahan 11mo ago
  I just skimmed the README. I believe the point is to do something akin to "promise pipelining": https://capnproto.org/rpc.html https://capnproto.org/rpc.html http://erights.org/elib/distrib/pipeline.html http://erights.org/elib/distrib/pipeline.html When an MCP tool is used, all of the output is piped straight into the LLM's context. If another MCP tool is needed to aggregate/filter/transform/etc the previous output, the LLM has to try ("try" is a keyword -- LLMs are by their nature nondeterministic) and reproduce the needed bits as inputs into the next tool use. This increases latency dramatically and is an inefficient use of tokens. This "a1" project, if I'm reading it correctly, allows for pipelining multiple consecutive tool uses without the LLM/agent being in the loop, until the very end when the final results are handed off to the LLM. An alternative approach inspired by the same problems identified in MCP: https://blog.cloudflare.com/code-mode/ https://blog.cloudflare.com/code-mode/

alganet 11mo ago

Instead of tools for humans, and a separate set of tools for machines, we should just make tools for humans+machines. The agent should look at my README.md, not a custom human-like text that is meant to be read by machines only. It also should look at `Makefile`, my bash aliases and so on, and just use that. In fact, many agents are quite good at this (Code Fast 1, Sonnet). Issue is, we have a LONG debt around those. READMEs often suck, and build files often suck. We just need to make them better. I see agents as an opportunity for making friendlier repos. The agent is a free usability tester in some sense. If it can't figure out by reading the human docs, then either the agent is not good enough or your docs aren't good enough.

didibus 11mo ago

> 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?

brouser 11mo ago

You hit it! I am also thinking of programatic control of DevTools so I made this: https://github.com/devtoolcss/chrome-inspector https://github.com/devtoolcss/chrome-inspector Though it is more about debugging CSS, I think we are on the same way: let agents use tool by scripting.

bradgessler 11mo ago

MCP has been a weird ride. I built https://terminalwire.com https://terminalwire.com before MCP was a thing to make it way easier for people to add a CLI/TUI to their web apps/SaaS. Then MCP comes out and AI explodes, sucking all the air out of the room for non-AI tools. Now it seems like AI can work with CLIs better than MCP, so I’m tempted to slap AI integration all over the project to better convey the idea. It’s crazy how quickly MCP has run it’s course and watching an entire ecosystem rediscover things from first principals.

72deluxe 11mo ago

MCP sounds like the modern equivalent of COM, where you could query an object to see what functions it exposed but had zero idea of what they did. MCP is the same: apparently it is LLM-readable, but the explanations of what everything does are human readable, and there is no standard on operations available.

filearts 11mo ago

What I've started experimenting with and will continue to explore is to have project-specific MCP tools. I add MCP tools to tighten the feedback loop. I want my Agent to be able to act autonomously but with a tight set of capabilities that don't often align with off-the-shelf tools. I don't want to YOLO but I also don't want to babysit it for non-value-added, risk-free prompts. So, when I'm developing in go, I create `cmd/mcp` and configure a `go run ./cmd/mcp` MCP server for the Agent. It helps that I'm quite invested in MCP and built github.com/ggoodman/mcp-server-go, which is one of the few (only?) MCP SDKs that let you scale horizontally over https while still supporting advanced features like elicitation and sampling. But for local tools, I can use the familiar and ergonomic stdio driver and have my Agent pump out the tools for me.

lsaferite 11mo ago
Horizontal scaling of remote MCP Servers is something the spec is sadly lacking any recognition around. If you've done work in this space, bravo. I've been using a message bus to decouple the HTTP servers from the MCP request handlers. I'm still evolving the solution, but it's been interesting so far.
- filearts 11mo ago
  This is the interface I landed on to make pluggable 'session hosts': https://github.com/ggoodman/mcp-server-go/blob/b8216cc1830ad78928589932cf5a1a78dd25e2b6/sessions/host.go#L16-L76 https://github.com/ggoodman/mcp-server-go/blob/b8216cc1830ad... It goes a tad beyond the spec minimum because I think it's valuable to be able to persist some small KV data with sessions and users.

moltar 11mo ago

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.

chowfi 11mo ago

Admittedly, the scripts+README approach works well for individual setups and is extremely token-efficient, since it only loads a tiny README and the model can infer how to run the scripts. But that convenience depends on a single local environment—one shell, one OS, etc. MCP is aimed at the opposite scenario: distributing tools to many users without relying on their environments. It provides automatic tool discovery, a server boundary that isolates credentials, and strict control over exposed capabilities. Its heavier JSON-schema definitions exist because they’re machine-readable contracts that behave consistently across clients, whereas CLI tools vary drastically across systems. So while MCP adds context overhead, it solves portability and distribution problems that scripts simply can’t.