[HN Gopher] Everything wrong with MCP
___________________________________________________________________
Everything wrong with MCP
Author : sshh12
Score : 471 points
Date : 2025-04-13 23:53 UTC (23 hours ago)
(HTM) web link (blog.sshh.io)
(TXT) w3m dump (blog.sshh.io)
| cratermoon wrote:
| "Authentication is tricky and so it was very fair that the
| designers chose not to include it in the first version of the
| protocol."
|
| No, it's not fair at all. You can't add security afterwards like
| spreading icing on baked cake. If you forgot to add sugar to the
| cake batter, there's not enough buttercream in the world to fix
| it.
| sshh12 wrote:
| I haven't read a good justification from them on this but it
| did seem reasonable to me that if the protocol allows auth to
| be added on top then it's less critical to be in the spec v1
| itself.
|
| It's not no security vs security but not standardized vs
| standardized.
|
| Agree though that's it's not ideal and there will definitely be
| non zero harm from that decision.
| chrisweekly wrote:
| great analogy
| mickael-kerjean wrote:
| I made a MCP server to access remote storage using any kind of
| protocols (S3, SFTP, FTP, .... ), and authentication was not as
| much of a problem that most people would make you think. Is it
| technically pure and beautiful? No. Does it work? Yes and you
| can check by yourself by pointing the mcp inspector to
| "https://demo.filestash.app/sse" and play around
| fnordpiglet wrote:
| I'll admit I'm a total dunce with respect to using MCP but
| given it uses TLS why not just use mutual TLS and validate the
| client certificate for authentication? You don't need to use
| higher level protocols for authentication if your transport
| protocol supports it already.
|
| I would think authZ is the trickier unhandled part of MCP as I
| don't remember any primitives for authorization denial or
| granularity, but, again, HTTP provides a coarse authZ exchange
| protocol.
| throw1290381290 wrote:
| There are 2 transports, HTTP and STDIO.
|
| You can use whatever authN/authZ you want for the HTTP
| transport. It's entirely up to the client and server
| implementers.
| fnordpiglet wrote:
| Presumably STDIO depends on the local AuthN/PAM that
| enabled the user space IO to begin with? I suspect what
| people are concerned about is the authorization of the LLM
| to the agent and its data rather than authN. AuthN in stdio
| would be the user that started the processes, or went
| through some AuthN chain allowing stdio to forward (I.e.,
| ssh, sudo, etc). Am I missing something?
| mehdibl wrote:
| No they are concerne with SSE/HTTP as some made some MCP
| server over HTTP without auth in 2025. Then call it MCP
| issue.
| fnordpiglet wrote:
| Right - that's my point. It's janky to put AuthN into a
| high level protocol like MCP when low level protocols do
| a better job that's more reliable and thoroughly vetted.
| You can do full on SAML etc and go hog wild without ever
| touching MCP while inheriting all the thorough analysis
| and implementation pressure testing down stack. Doing
| something unsafe because you don't know what safe looks
| like isn't application protocols fault.
| jacobr1 wrote:
| The bigger issue is that we need a good why to
| authenticate more dynamically. In the context of a
| desktop app (desktop claude, claude code) where you are
| running an application locally, for your own purposes it
| can run as your own user.
|
| But when you are running things in any kind of multi-
| user/multi-tenant scenario, this is much harder and the
| protocol doesn't really address this (though also doesn't
| prevent us from layering something on top). As a dumb
| (but real) example, I don't want a web-enabled version of
| of an MCP plugin to have access to my company's google
| drive and expose that to all our chat users. That would
| bypass the RBAC we have. Also I don't want to bake that
| in at the level of the tool calls, as that can be
| injected. I need some side channel information on the
| session to have the client and server to manage that.
| throw1290381290 wrote:
| MCP can use HTTP or STDIO as transports.
|
| There is no need to implement a new form of authentication
| that's specific to the protocol because you already have a
| myriad of options available with HTTP.
|
| Any form of auth used to secure a web service can be used with
| MCP. It's no different than adding authN to a REST API.
|
| Please just read the spec. It just builds on top of JSON-RPC,
| there's nothing special or inherently new about this protocol.
|
| https://modelcontextprotocol.io/specification/2025-03-26
|
| There are way too many commentators like yourself that have no
| idea what they are talking about because they couldn't be
| bothered to RTFM.
| RamblingCTO wrote:
| Exactly, lots of people without any idea on what's going on.
| I implemented an authenticated MCP that uses the context
| bearer token and passes it on to the backend. Fully
| authenticated and authorized.
| seuros wrote:
| Did you read the spec ? Everything you said is already a
| recommendation.
| sshh12 wrote:
| I think recommendation != being enforceably part of it or being
| implemented.
|
| There are a lot of great recs in the docs but I wrote this
| based on what I actually saw in the wild. I definitely don't
| think it's all on the spec to solve these.
| mehdibl wrote:
| You didn't read the spec. And you didn't mention Stdio. Stdio
| is secure and that's what is used by Claude Desktop the first
| MCP client and they don't support SSE yet. Since the start,
| SSE was set a draft and there was a long discussion over the
| authentification implementation first round already got
| defined and second is defined again.
|
| I saw a lot of articles since MCP was buzzing same claims
| copy & paste. And the post show a lot of confusion for what
| MCP is and MCP do.
| sshh12 wrote:
| A lot of servers don't use the stdio transport.
| klntsky wrote:
| MCP is a dead end for chatbots. Building valuable workflows
| requires more than tool calling, most importantly, understanding
| the context of a conversation to adjust the tools dynamically.
| simonw wrote:
| What does that have to do with MCP? Those sound like things you
| would build on a separate layer from MCP.
| klntsky wrote:
| MCP tools are completely static. If you have to expose some
| APIs bypassing MCP, then you don't need MCP in the first
| place, because you don't have the tools abstracted anymore.
|
| I believe it is possible to build nuanced workflows with well
| abstracted / reusable / pluggable tools, it's just not as
| simple as implementing a static discovery / call dispatch
| layer.
| chipgap98 wrote:
| Static in what sense?
| mdaniel wrote:
| I'm not the person you asked, but it does jam me up that
| Claude Desktop currently makes you edit a .json file and
| restart the app to add new MCP servers[1], so that's at
| least one static thing. I'm sure someone will show up
| with a github link of awesome-org/mcp-mcp-server
|
| 1: https://modelcontextprotocol.info/docs/quickstart/user
| /#3-re...
| cmsparks wrote:
| MCP isn't static. It explicitly includes support for
| dynamically modifying tools, resources, etc via it's client
| notifications[0]. Sure, context is usually opaque to the
| server itself (unless you use the sampling feature[1]), but
| there's nothing preventing MCP clients/hosts from adjusting
| or filtering tools on their own.
|
| [0] https://modelcontextprotocol.io/specification/2025-03-2
| 6/ser...
|
| [1] https://modelcontextprotocol.io/specification/2025-03-2
| 6/cli...
| ahamilton454 wrote:
| Server notifications are a bad way of implementing
| semantic retrieval on tools. There when would one update
| the tools? You can't "trigger" an event which causes a
| tool change without some hacky workarounds
| cmsparks wrote:
| >There when would one update the tools? You can't
| "trigger" an event which causes a tool change without
| some hacky workarounds
|
| Tool calls can trigger tool changes. Consider an MCP
| server exposes a list of accounts and tools to manage
| resources on those accounts:
|
| 1. MCP session starts, only tool exposed to the client is
| the `select_account` and `list_accounts` tools
|
| 2. MCP Client selects an account with `select_account`
| tool
|
| 3. MCP Server updates tools for the session to include
| `account_tool_a`. This automatically dispatches a
| listChanged notification
|
| 4. MCP Client receives notification and updates tools
| accordingly
|
| IME this is pretty ergonomic and works well with the
| spec. But that's assuming your client is well behaved,
| which many aren't
| ahamilton454 wrote:
| A tool change can send a notification to the client, but
| the client chooses when to actually update the tools.
| This could take time and the LLM may not be aware of the
| new tool. I don't think there is a concept of a "well-
| behaved" client since MCP is about giving flexibility of
| implementation.
|
| I wouldn't call this ergonomic. Alternatively, you could
| just notify the server when a user message is sent, and
| allow the server to adjust the tools and resources prior
| to execution of the agent (this is clearly different from
| the MCP spec).
|
| On a separate note, what client are you using that
| supports notification, I haven't seen one yet?
| aoeusnth1 wrote:
| Can you give an example where you would need to adjust tools
| dynamically based on context? Is that for all tools or just for
| some?
|
| For example, why does a "Google search" tool need to change
| from context to context?
| lyu07282 wrote:
| It's great for general and open ended conversation systems
| where there is no predefined flow or process to follow. Where
| you have general capabilities you add to the agent (web
| search, code execution, web drivers, etc.). But a lot of
| agentic architecture patterns aren't like that, there you
| want to closely model the flow, guard rails and constraints
| of the agent. You can't just take a bunch of MCP services and
| plug them together to solve every business problem. I think
| it's a bit unfair to MCP because it doesn't seem to even
| attempt to solve these problems in the first place. It's not
| replacing things like LangChain.
|
| Everyone should welcome MCP as an open community-driven
| standard, because the alternative are fractured, proprietary
| and vendor-locked protocols. Even if right now MCP is a
| pretty bad standard over time it's going to improve. I take a
| bad standard that can evolve with time, over no standard at
| all.
| jacobr1 wrote:
| Right ... the best way to think about MCP right now
| flipping the switch from every app/agent developer building
| their own client wrappers around 3rd party APIs to either
| the API providers building them or community maintained
| wrappers. But all that gives it is a large toolbox. Like
| NPM or PyPi or any Apt or any our package maintainer. You
| still need systems to orchestrate them, secure them, define
| how to use them, etc ... The next-gen of langchains will be
| all the much better for having a big toolchest ... but it
| doesn't negate the need for us to innovate and figure out
| what that will look like
| sshh12 wrote:
| I could see some cases were the tools are user data specific.
| You upload some csv and now there are some tools customized
| for slicing and manipulating that data.
|
| It's totally possible to build tools in way that everything
| is static but might be less intuitive for some use cases.
| aledalgrande wrote:
| > understanding the context of a conversation to adjust the
| tools dynamically
|
| This just sounds like a small fine tuned model that knows
| hundreds of MCP tools and chooses the right ones for the
| current conversation.
| totaldude87 wrote:
| isnt langchain doing the exact same thing? (sorry ai noob here)
| simonw wrote:
| Langchain is one of many frameworks that implement the "tool
| calling" pattern, where LLM applications can request that a
| tool is run (eg "search the web for X" or "execute this Python
| code") and see the result of that.
|
| MCP is a standard for describing and exposing tools to LLM
| applications.
|
| So they're not the same category of thing. Langchain could
| implement aspects of the MCP specification, in fact it looks
| like they're doing that already: https://github.com/langchain-
| ai/langchain-mcp-adapters
| the_arun wrote:
| So, is MCP a spec for tool calling API?
| simonw wrote:
| There's a MCP "server" spec for writing code that exposes
| tool definitions and the ability to execute them, and an
| MCP "client" spec for building systems that can make use of
| those servers.
| tuananh wrote:
| it's more than just tools. there're prompts & resources too
| pizza wrote:
| It's a spec for how external info can get into a language
| model's context window. Part of that is tool calling, but
| there's also templated input, cancellation, progress
| tracking, recursive generation sampling, statefulness of
| tool servers, etc.
| sshh12 wrote:
| It's a common question!
|
| Related: > Tool-Calling - If you're like me, when you first saw
| MCP you were wondering "isn't that just tool-calling?"...
|
| Not everyone uses langchain nor does langchain cover some of
| the lower level aspects of actually connecting things up. MCP
| just helps standardize some of those details so any
| assistant/integration combo is compatible.
|
| Edit: +1 simonw above
| behnamoh wrote:
| Yeah, I don't feel comfortable downloading tiny server programs
| from random devs on the internet to give my LLM client apps extra
| "tools". I can LuLu or LittleSnitch regular apps but not these
| ones.
| jwpapi wrote:
| I have read 30 MCP articles now and I still don't understand why
| we not just use API?
| jasondigitized wrote:
| I played around with MCP this weekend and I agree. I just want
| to get a users X and then send X to my endpoint so I can do
| something with it. I don't need any higher level abstraction
| than that.
| pcarolan wrote:
| Right. And if you use OpenAPI the agent can get the api spec
| context it needs from /openapi.json.
| kristoff200512 wrote:
| I think it's fine if you only need a standalone API or know
| exactly which APIs to call. But when users ask questions or
| you're unsure which APIs to use, MCP can solve this issue--and
| it can process requests based on your previous messages.
| pizza wrote:
| I just want to mention something in a chat in 5 seconds instead
| of preparing the input data, sending it to the API, parsing the
| output for the answer, and then doing it all again for every
| subsequent message.
| mehdibl wrote:
| Because you need mainly a bridge between the Function calling
| schema defined that you expose to the AI model so you can
| leverage them. The model need a gateway as API can't be used
| directly.
|
| MCP core power is the TOOLS and tools need to translate to
| function calls and that's mainly what MCP do under the hood.
| Your tool can be an API, but you need this translation layer
| function call ==> Tool and MCP sits in the middle
|
| https://platform.openai.com/docs/guides/function-calling
| throw1290381290 wrote:
| Here's the kicker. It is an API.
| arthurcolle wrote:
| It is an API. You can implement all this stuff from scratch
| with raw requests library in python if you want. Its the idea
| of a standard around information interchange, specifically
| geared around agentic experiences like claude code, (tools like
| aider, previously, that are much worse) - its like a FastAPI
| web app framework around building stuff that can helps LLMs and
| VLMs and model wrapped software in ways that can speak over the
| network.
|
| Basically like Rails-for-Skynet
|
| I'm building this: https://github.com/arthurcolle/fortitude
| yawnxyz wrote:
| I have an API, but I built an MCP around my API that makes it
| easier for something like Claude to use -- normally something
| that's quite tough to do (giving special tools to Claude).
| throw310822 wrote:
| I'm not sure I get it too. I get the idea of a standard api to
| connect one or more external resources _providers_ to an llm
| (each exposing tools + state). Then I need one single standard
| client-side connector to allow the llm to talk to those
| external resources- basically something to take care of the
| network calls or other forms of i /o in my local (llm-side)
| environment. Is that it?
| lsaferite wrote:
| Sounds mostly correct. The standard LLM tool call 'shape'
| matches the MCP tool call 'shape' very closely. It's really
| just a simple standard to support connecting a tool to an
| agent (and by extension an LLM).
|
| There are other aspects, like Resources, Prompts, Roots, and
| Sampling. These are all relevant to that
| LLM<->Agent<->Tools/Data integration.
|
| As with all things AI right now, this is a solution to a
| current problem in a fast moving problem space.
| serverlessmania wrote:
| MCP allows LLM clients you don't control--like Claude, ChatGPT,
| Cursor, or VSCode--to interact with your API. Without it, you'd
| need to build your own custom client using the LLM API, which
| is far more expensive than just using existing clients like
| ChatGPT or Claude with a $20 subscription and teaching them how
| to use your tools.
|
| I built an MCP server that connects to my FM hardware
| synthesizer via USB and handles sound design for me:
| https://github.com/zerubeus/elektron-mcp.
| jonfromsf wrote:
| But couldn't you just tell the LLM client your API key and
| the url of the API documentation? Then it could interact with
| the API itself, no?
| romanovcode wrote:
| Yes but it's not as revolutionary as MCP. You don't get
| it...
| serverlessmania wrote:
| Not all clients support that--currently limited to ChatGPT
| custom GPT actions. It's not a standard. Fortunately,
| Anthropic, Google, and OpenAI have agreed to adopt MCP as a
| shared protocol to enable models to use tools. This
| protocol mainly exists to simplify things for those
| building LLM-powered clients like Claude, ChatGPT, Cursor,
| etc. If you want an LLM (through API calls) to interact
| with an your API, you can't just hand it an API key and
| expect it to work--you need to build an Agent for that.
| mhast wrote:
| You could do that. But then you need to explain to the LLM
| how to do the work every time you want to use that tool.
|
| And you also run into the risk that the LLM will randomly
| fail to use the tool "correctly" every time you want to
| invoke it. (Either because you forgot to add some
| information or because the API is a bit non-standard.)
|
| All of this extra explaining and duplication is also going
| to waste tokens in the context and cost you extra money and
| time since you need to start over every time.
|
| MCP just wraps all of this into a bundle to make it more
| efficient for the LLM to use. (It also makes it easier to
| share these tools with other people.)
|
| Or if you prefer it. Consider that the first time you use a
| new API you can give these instructions to the LLM and have
| it use your API. Then you tell it "make me an MCP
| implementation of this" and then you can reuse it easily in
| the future.
| jacobr1 wrote:
| In some sense that is actually what MCP is. A way to
| document APIs and describe how to call them, along with
| some standardized tooling to expose that documentation and
| make the calls. MCP hit a sweet spot of just enough
| abstraction to wrap APIs without complicating things. Of
| course, since they didn't add a bunch of extra stuff ...
| that leads allowing users to footgun themselves per the
| article.
| zoogeny wrote:
| Yes, but then you have to add that yourself to every
| prompt. It would be nice to tell your LLM provider just
| once "here is a tool you can use" along with a description
| of the API documentation so that you could use it in a
| bunch of different chat's without having to remind it every
| single time. That way, when you want to use the tool you
| can just ask for the tool without having to provide that
| detail again and again.
|
| Also, it would be kind of cool if you could tell a desktop
| LLM client how it could connect to a program running on
| your machine. It is a similar kind of thing to want to do,
| but you have to do a different kind of processes exec
| depending on what OS you are running on. But maybe you just
| want it to ultimately run a Python script or something like
| that.
|
| MCP addresses those two problems.
| siva7 wrote:
| ChatGPT still doesn't support MCP. It really fell behind
| Google or Anthropic in the last months in most categories.
| Gemini pro blows o1 pro away.
| aoeusnth1 wrote:
| If you are a tool provider, you need a standard protocol for
| the AI agent frontends to be able to connect to your tool.
| geysersam wrote:
| I think the commenter is asking "why can't that standard
| protocol be http and open api?"
| stevenhuang wrote:
| MCP is a meta-api and it basically is that, but with
| further qualifications that the endpoints and how they work
| themselves are part of the spec so LLMs can work with them
| better.
| edanm wrote:
| It is an API. It's an API standardization for LLMs to interact
| with outside tools.
| idonotknowwhy wrote:
| I feel like this is being pushed to get more of the system
| controlled by the provider's side. After a few years,
| Anthropic, google, etc might start turning off the api. Similar
| to how Google made it very difficult to use IMAP / SMTP with
| Gmail
| nzach wrote:
| > why we not just use API
|
| Did you meant to write "a HTTP API"?
|
| I asked myself this question before playing with it a bit. And
| now I have a slightly better understanding, I think the main
| reason was created as a way to give access of your local
| resources (files, envvars, network access...) to your LLM. So
| it was designed to be something you run locally and the LLM has
| access.
|
| But there is nothing preventing you making an HTTP call from a
| MCP server. In fact, we already have some proxy servers for
| this exact use-case[0][1].
|
| [0] - https://github.com/sparfenyuk/mcp-proxy
|
| [1] - https://github.com/adamwattis/mcp-proxy-server
| raldi wrote:
| Did you read this one?
|
| https://norahsakal.com/blog/mcp-vs-api-model-context-protoco...
| dend wrote:
| Coordinator of the authorization RFC linked in this post[1].
|
| The protocol is in very, very early stages and there are a lot of
| things that still need to be figured out. That being said, I can
| commend Anthropic on being very open to listening to the
| community and acting on the feedback. The authorization spec RFC,
| for example, is a coordinated effort between security experts at
| Microsoft (my employer), Arcade, Hello, Auth0/Okta, Stytch,
| Descope, and quite a few others. The folks at Anthropic set the
| foundation and welcomed others to help build on it. It will
| mature and get better.
|
| [1]:
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| sshh12 wrote:
| Awesome! Thanks for your work on this.
| dend wrote:
| Can't take any credit - it's a massive effort across many
| folks much smarter than me.
| magicalhippo wrote:
| A nice, comprehensive yet accessible blog post about it can be
| found here[1], got submitted earlier[2] but didn't gain
| traction.
|
| [1]: https://aaronparecki.com/2025/04/03/15/oauth-for-model-
| conte...
|
| [2]: https://news.ycombinator.com/item?id=43620496
| dend wrote:
| Great news - Aaron has been a core reviewer and contributor
| to the aforementioned RFC.
| magicalhippo wrote:
| Yeah figured he had to be involved and saw his name on the
| pull request after I posted.
|
| Really enjoyed the article he wrote, just wanted to promote
| it some more. I learned of several things that will be
| useful to me beyond MCP.
| martypitt wrote:
| Impressive to see this level of cross-org coordination on
| something that appears to be maturing at pace (compared to
| other consortium-style specs/protocol I've seen attempted)
|
| Congrats to everyone.
| Y_Y wrote:
| This reminds me of something Adam Smith said in _The Wealth of
| Nations_ :
|
| "People of the same trade seldom meet together, even for
| merriment and diversion, but the conversation ends in a
| conspiracy against the public, or in some contrivance to raise
| prices."
|
| Ymmv, but I cannot image that this "innovation" will result in
| a better outcome for the general public.
| rglover wrote:
| Yet another piece of rushed technology that's being heralded as
| "the way" which will most certainly be discarded when the next
| hype-able acronym comes along.
|
| The only upside to these technologies being shotgun implemented
| and promoted is that they'll inevitably lead to a failure that
| can't be pushed under the rug (and will irreversibly damage the
| credibility of AI usage in business).
| pizza wrote:
| To paraphrase the Bjarne Stroustrop quote: _There are only two
| kinds of language model tool calling protocols: the ones people
| complain about and the ones nobody uses_
| rglover wrote:
| Okay and now what? Throwing out empty platitudes like this in
| the face of legitimate criticism is only going to expedite
| what I said above.
| rvz wrote:
| Totally agree.
|
| It appears Anthropic developed this "standard" in a vacuum with
| no scrutiny or review and it turns out it's riddled with
| horrific security issues, ignored by those hyping up the
| "standard" for more VC money.
|
| Reminds me of the micro-services hype, which that helps the big
| cloud providers more than it helps startups with less money
| even with some over-doing it and being left with enormous
| amount of technical debt and complex diagrams costing them
| millions to run.
| mehdibl wrote:
| MCP have a BAD UI?
|
| MCP is not a UI. Seem someone here quite confused about what is
| MCP.
|
| MCP have no security? Someone don't know that stdio is secure and
| over SSE/HTTP there was already specs:
| https://modelcontextprotocol.io/specification/2025-03-26/bas....
|
| MCP can run malicious code? Apply to any app you download. How
| this is the MCP issue? Happen in vscode extensions. NPM libs. But
| blame MCP.
|
| MCP transmits unstructured text by design?
|
| This is totally funny. It's the tool that decide what to respond.
| Annd the dialogue is quite
|
| I start feeling this post is a troll.
|
| I stopped reading and even worth continuing over prompt injection
| and so on.
| throw1290381290 wrote:
| > Someone don't know that stdio is secure
|
| I'm sure someone in the comments will say that inter-process
| communication requires auth (-^l.
| frogsRnice wrote:
| It absolutely does
| ramesh31 wrote:
| MCP is absolutely a UI. It's just that the "user" is an LLM
| agent. Properly defining that interface is the main crucial
| piece of developing any tool.
| mehdibl wrote:
| OK the HTTP is a UI. Seriously, these comment are trolling.
| dang wrote:
| Please don't resort to accusing others of trolling, or of
| telling them they didn't read something
| (https://news.ycombinator.com/item?id=43677540). These are
| swipes, which the HN guidelines ask you to edit out of your
| posts here:
| https://news.ycombinator.com/newsguidelines.html.
|
| If people are posting bad information or bad arguments,
| it's enough to respond with good information and good
| arguments. It's in your interests to do this too, because
| if you make them without swipes, your arguments will be
| more credible.
| alternatex wrote:
| We have to draw some line on good faith vs bad faith
| arguments though. Not understanding the difference
| between a UI and API is a stretch and purposefully
| conflating them just to win a semantic argument is not
| productive.
| dang wrote:
| The problem is that internet readers are far, far too
| prone to classify others as being in bad faith, so in
| practice, "drawing the line" usually amounts to a
| provocation. This bias is so strong that I don't think
| people can be persuaded to draw that line more
| accurately.
|
| Moreover, the concept of good faith / bad faith refers to
| intent, and we can't know for sure what someone's intent
| was. So the whole idea of assessing someone else's good-
| faith level is doomed from the start.
|
| Fortunately, there is a strategy that does work pretty
| well: assume good faith, and reply to bad information
| with correct information and bad arguments with better
| arguments. If the conversation stops being productive,
| then stop replying. Let the other person have the last
| word, if need be--it's no big deal, and in cases where
| they're particularly wrong, that last word is usually
| self-refuting.
| mcintyre1994 wrote:
| > MCP can run malicious code? Apply to any app you download.
| How this is the MCP issue? Happen in vscode extensions. NPM
| libs. But blame MCP.
|
| Nobody is saying MCP is the only way to run malicious code,
| just that like VSCode extensions and NPM install scripts it has
| that problem.
| sunpazed wrote:
| Let's remind ourselves that MCP was announced to the world in
| November 2024, only 4 short months ago. The RFC is actively being
| worked on and evolving.
| sealeck wrote:
| It's April 2025
| marcellus23 wrote:
| Yes, and it's been about 4 and a half months since Nov 25,
| 2024.
| rvz wrote:
| Another article accurately critiquing the short-comings of this
| terrible "spec".
|
| This is exactly why MCP is hardly a mature standard and was not
| designed to be secure at all making it acceptable for AI agents
| to claim to execute commands but could also be stealing your
| credentials or running a totally different command such or could
| download malware.
|
| The spec appears to to be designed by 6 month-old vibe-coding
| developers learning Javascript with zero scrutiny rather than
| members of the IETF at leading companies with maximum scrutiny.
|
| Next time, Anthropic should consult professionals that have
| developed mature standards for decades and learn from bad
| standards such as JWT and Oauth.
| EigenLord wrote:
| The author makes good general points but seems to be overloading
| MCP's responsibilities imo. My understanding of MCP is that it
| just provides a ready-made "doorway" for LLMs to enter and
| interact with externally managed resources. It's a bridge or
| gateway. So is it really MCP's fault that it:
|
| >makes it easier to accidentally expose sensitive data.
|
| So does the "forward" button on emails. Maybe be more careful
| about how your system handles sensitive data. How about:
|
| >MCP allows for more powerful prompt injections.
|
| This just touches on wider topic of only working with trusted
| service providers that developers should abide by generally. As
| for:
|
| >MCP has no concept or controls for costs.
|
| Rate limit and monitor your own usage. You should anyway. It's
| not the road's job to make you follow the speed limit.
|
| Finally, many of the other issues seem to be more about coming to
| terms with delegating to AI agents generally. In any case it's
| the developer's responsibility to manage all these problems
| within the boundaries they control. No API should have that many
| responsibilities.
| Spivak wrote:
| I think the author's point is that the architecture of MCP is
| fundamentally _extremely_ high trust between not only your
| agent software and the integrations, but the (n choose 2)
| relationships between all of them. We 're doing the LLM
| equivalent of loading code directly into our address space and
| executing it. This isn't a bad thing, dlopen is incredibly
| powerful with this power, but the problem being solved with MCP
| just isn't that level of trust.
|
| The real level of trust is on the order OAuth flows where the
| data provider has a gun sighted on every integration. Unless
| something about this protocol and it's implementations change I
| expect every MCP server to start doing side-channel
| verification like getting an email "hey your LLM is asking to
| do thing, click the link to approve." Where in this future it
| severely inhibits the usefulness of agents in the same vein as
| Apple's "click the notification to run this automation."
| zoogeny wrote:
| Sure, at first, until the users demand a "always allow this
| ..." kind of prompt and we are back in the same place.
|
| A lot of these issues seem trivial when we consider having a
| dozen agents running on tens of thousands of tokens of
| context. You can envision UIs that take these security
| concerns into account. I think a lot of the UI solutions will
| break down if we have hundreds of agents each injecting 10k+
| tokens into a 1m+ context. The problems we are solving for
| today won't hold as LLMs continue to increase in size and
| complexity.
| sshh12 wrote:
| Totally agree, hopefully it's clear closer to the end that I
| don't actually expect MCP to solve and be responsible for a lot
| of this. More so MCP creates a lot of surface area for these
| issues that app developers and users should be aware of.
| Someone wrote:
| > Rate limit and monitor your own usage. You should anyway.
| It's not the road's job to make you follow the speed limit.
|
| In some sense, urban planners _do_ design roads to make you
| follow the speed limit.
| https://en.wikipedia.org/wiki/Traffic_calming:
|
| _"Traffic calming uses physical design and other measures to
| improve safety for motorists, car drivers, pedestrians and
| cyclists. It has become a tool to combat speeding and other
| unsafe behaviours of drivers"_
| fsndz wrote:
| why would anyone accept to expose sensitive data so easily with
| MCP ? also MCP does not make AI agents more reliable, it just
| gives them access to more tools, which can decrease reliability
| in some cases:https://medium.com/thoughts-on-machine-
| learning/mcp-is-mostl...
| Eisenstein wrote:
| People accept lots of risk in order to do things. LLMs offer
| so much potential that people want to use so they will try,
| and it is but through experience that we can learn to
| mitigate any downsides.
| ZiiS wrote:
| > Rate limit and monitor your own usage. You should anyway.
| It's not the road's job to make you follow the speed limit.
|
| A better metaphor is the car, not the road. It is legally
| required to accurately tell you your speed and require
| deliberate control to increase it.
|
| Even if you stick to a road; whoever made the road is required
| to research and clearly post speed limits.
| jacobr1 wrote:
| Exactly. It is pretty common for APIs to actually signal this
| too. Headers to show usage limits or rates. Good error codes
| (429) with actual documentation on backoff timeframes. If you
| use instrument your service to respect read and respect the
| signals it gets, everything moves smoother. Backing stuff
| like that back into the MCP spec or at least having common
| conventions that are applied on top will be very useful.
| Similarly for things like tracking data taint, auth, tracing,
| etc ... Having a good ecosystem makes everything play
| together much nicer.
| TeMPOraL wrote:
| Also extending the metaphor, you _can_ make a road that
| controls where you go and makes sure you don 't stray from it
| (whether by accident or on purpose): it's called _rail_ , and
| its safety guarantees come with reduced versatility.
|
| Don't blame roads for not being rail, when you came in a car
| because you need the flexibility that the train can't give
| you.
| TeMPOraL wrote:
| Yeah. That's another in a long line of MCP articles and
| blogposts that's been coming up over the past few weeks, that
| can be summarized as "breaking news: this knife is sharp and
| can cut someone if you swing it at people, it can cut you if
| you hold it the wrong way, and is not a toy suitable for small
| children".
|
| Well, yes. A knife cuts things, it's literally its only job. It
| will cut whatever you swing it at, including people and things
| you didn't intend to - that's the nature of a _general-purpose
| cutting tool_ , as opposed to e.g. safety razor or plastic
| scissors for small children, which are _much_ safer, but can
| only cut few very specific things.
|
| Now, I get it, young developers don't know that knives and
| remote access to code execution on a local system are both
| sharp tools and need to be kept out of reach of small children.
| But it's one thing to remind people that the tool needs to be
| handled with care; it's another to blame it on the tool design.
|
| Prompt injection is a consequence of the nature of LLMs, you
| can't eliminate it without degrading capabilities of the model.
| No, "in-band signaling" isn't the problem - "control vs. data"
| separation is not a thing in nature, it's designed into
| systems, and what makes LLMs useful and general is that _they
| don 't have it_. Much like people, by the way. Remote MCPs as a
| Service are a bad idea, but that's not the fault of the
| protocol - it's the problem of giving power to third parties
| you don't trust. And so on.
|
| There is technical and process security to be added, but that's
| mostly _around_ MCP, not in it.
| Joker_vD wrote:
| Well. To repurpose you knife analogy, they (we?) duct-taped a
| knife on an erratic, PRNG-controlled roomba and now discover
| that people are getting their Achilles tendons sliced.
| Technically, it's all functioning exactly as intended, but:
| this knife was designed specifically to be attached to such
| roombas, and apparently nobody stopped to think whether it
| was such a great idea.
|
| And admonishments of "don't use it when people are around,
| but if you do, it's those people's fault when they get cut:
| they should've be more careful and probably wore some
| protective foot-gear" while technically accurate, miss the
| bigger problem. That is, that somebody decided to strap a
| sharp knife to a roomba and then let it whiz around in the
| space full of people.
|
| Mind you, we have actual woodcutting table saws with built-in
| safety measures: they instantly stop when they detect contact
| with human skin. So you absolutely can have safe knives. They
| just cost more, and I understand that most people value
| (other) people's health and lives quite cheaply indeed, and
| so don't bother buying/designing/or even considering such
| frivolities.
| dharmab wrote:
| This is a total tangent, but we can't have 100% safe knives
| because one of the uses for a knife is to cut meat.
| (Sawstop the company famously uses hot dogs to simulate
| human fingers in their demos.)
| TeMPOraL wrote:
| Yes. Also, equally important is the fact that _table saws
| are not knives_. The versatility of a knife was the whole
| point of using it as an example.
|
| --
|
| EDIT: also no, your comment isn't a tangent - it's
| _exactly on point_ , and a perfect illustration of why
| knives are a great analogy. A knife in its archetypal
| form is at the highest point of its generality as a tool.
| A cutting surface attached to a handle. There is nothing
| you could change in this that would improve it without
| making it less versatile. In particular, there is no
| change you could make that would make a knife safer
| without making it less general (adding a handle to the
| blade was the last such change).
|
| No, you[0] can't add a Sawstop-like system to it, because
| as you[1] point out, it works by detecting meat -
| specifically, by detecting the blade coming in contact
| with something more conductive than wood. Such "safer"
| knife thus can't be made from non-conductive materials
| (e.g. ceramics), and it can't be used to work with fresh
| food, fresh wood, in humid conditions, etc.[2]. You've
| just turned a general-purpose tool into a highly
| specialized one - but we already have a better version of
| this, it's the table saw!
|
| Same pattern will apply to any other idea of redesigning
| knives to make them safer. Add a blade cage of some sort?
| Been done, plenty of that around your kitchen, none of it
| will be useful in a workshop. Make knife retractable and
| add a biometric lock? Now you can't easily share the
| knife with someone else[3], _and_ you 've introduced so
| many operational problems it isn't even funny.
|
| And so on, and so on; you might think that with enough
| sensors and a sufficiently smart AI, a perfectly safe
| knife could be made - but then, that's also exist, it's
| called _you the person who is wielding the knife_.
|
| To end this essay my original witty comment has now
| become, I'll spell it out: like a knife, LLMs are by
| design general-purpose tools. You can make them
| increasingly safer by sacrificing some aspects of their
| functionality. You cannot keep them fully general _and_
| make them strictly safer, because the meaning of
| "safety" is itself highly situational. If you feel the
| tool is too dangerous for your use case, then _don 't use
| it_. Use a table saw for cutting wood, use a safety razor
| for shaving, use a command line and your brain for
| dealing with untrusted third-party software - or don't,
| but then don't go around blaming the knife or the LLM
| when you hurt yourself by choosing to use too powerful a
| tool for the job at hand. Take responsibility, or stick
| to Fisher-Price alternatives.
|
| Yes, this is a long-winded way of saying: what's wrong
| with MCP is that a bunch of companies are now trying to
| convince you to use it in a dangerous way. Don't. Your
| carelessness is your loss, but their win. LLMs + local
| code execution + untrusted third parties don't mix
| (neither do they mix if you remove "LLMs", but that's
| another thing people still fail to grasp).
|
| As for solutions to make systems involving LLMs safer and
| more secure - again, look at how society handles knives,
| or how we secure organizations in general. The measures
| are built _around_ the versatile-but-unsafe parts, and
| they look less technical, and more legal.
|
| (This is to say: one of the major measures we need to
| introduce is to treat attempts at fooling LLMs the same
| way as fooling people - up to and including criminalizing
| them in some scenarios.)
|
| --
|
| [0] - The "generic you".
|
| [1] - 'dharmab
|
| [2] - And then if you use it to cut through wet stuff,
| the scaled-down protection systems will likely break your
| wrist; so much for safety.
|
| [3] - Which could easily become a lethal problem in an
| emergency, or in combat.
| skybrian wrote:
| The problem with the "knife is sharp" argument is that it's
| too generic. It can be deployed against most safety
| improvements. The modern world is built on driving accident
| rates down to near-zero. That's _why_ we have specialized
| tools like safety razors. Figuring out what to do to reduce
| accident rates is what postmortems are for - we don't just
| blame human error, we try to fix things systematically.
|
| As usual, the question is what counts as a reasonable safety
| improvement, and to do that we would need to go into the
| details.
|
| I'm wondering what you think of the CaMeL proposal?
|
| https://simonwillison.net/2025/Apr/11/camel/#atom-everything
| peterlada wrote:
| Love the trollishness/carelessness of your post. Exactly as you
| put it: "it is not the road's job to limit your speed".
|
| Like a bad urban planner building a 6 lane city road with the
| 25mph limit and standing there wondering why everyone is doing
| 65mph in that particular stretch. Maybe sending out the police
| with speed traps and imposing a bunch of fines to "fix" the
| issue, or put some rouge on that pig, why not.
| reliabilityguy wrote:
| > It's not the road's job to make you follow the speed limit.
|
| Good road design makes it impossible to speed.
| noodletheworld wrote:
| Some of the other issues are less important than others, but
| even if you accept "you have to take responsibility for
| yourself", let me quote the article:
|
| > As mentioned in my multi-agent systems post, LLM-reliability
| often negatively correlates with the amount of instructional
| context it's provided. This is in stark contrast to most users,
| who (maybe deceived by AI hype marketing) believe that the
| answer to most of their problems will be solved by providing
| more data and integrations. I expect that as the servers get
| bigger (i.e. more tools) and users integrate more of them, an
| assistants performance will degrade all while increasing the
| cost of every single request. Applications may force the user
| to pick some subset of the total set of integrated tools to get
| around this.
|
| I will rephrase it in stronger terms.
|
| MCP does not scale.
|
| It _cannot_ scale beyond a certain threshold.
|
| It is _Impossible_ to add an unlimited number of tools to your
| agents context without negatively impacting the capability of
| your agent.
|
| This is a fundamental limitation with the entire concept of MCP
| and needs addressing far more than auth problems, imo.
|
| You will see posts like "MCP used to be good but now..." as
| people experience the effects of having many MCP servers
| enabled.
|
| They _interfere with each other_.
|
| This is fundamentally and utterly different from installing a
| package in any normal package system, where _not interfering_
| is a _fundamental property_ of package management in general.
|
| Thats the problem with MCP.
|
| As an _idea_ it is different to what people trivially expect
| from it.
| weird-eye-issue wrote:
| I think this can largely be solved with good UI. For example,
| if an MCP or tool gets executed that you didn't want to get
| executed, the UI should provide an easy way to turn it off or
| to edit the description of that tool to make it more clear
| when it should be used and should not be used by the agent.
|
| Also, in my experience, there is a huge bump in performance
| and real-world usage abilities as the context grows. So I
| definitely don't agree about a negative correlation there,
| however, in some use cases and with the wrong contexts it
| certainly can be true.
| robertlagrant wrote:
| > For example, if an MCP or tool gets executed that you
| didn't want to get executed, the UI should provide an easy
| way to turn it off or to edit the description of that tool
| to make it more clear when it should be used and should not
| be used by the agent.
|
| Might this become more simply implemented as multiple
| individual calls, possibly even to different AI services,
| chained together with regular application software?
| weird-eye-issue wrote:
| I don't understand your question at all
|
| If you are saying why have autonomous agents at all and
| not just workflows, then obviously the answer is that it
| just depends on the use case. Most of the time workflows
| that are not autonomous are much better, but not always,
| and sometimes they will also include autonomous parts in
| those workflows
| zoogeny wrote:
| I don't think that could be sufficient to solve the
| problem.
|
| I'm using Gemini with AI Studio and the size of a 1 million
| token context window is becoming apparent to me. I have a
| large conversation, multiple paragraphs of text on each
| side of the conversation, with only 100k tokens or so. Just
| scrolling through that conversation is a chore where it
| becomes easier just to ask the LLM what we were talking
| about earlier rather than try to find it myself.
|
| So if I have several tools, each of them adding 10k+
| context to a query, and all of them reasonable tool
| requests - I still can't verify that it isn't something
| "you [I] didn't want to get executed" since that is a vague
| description of the failure states of tools. I'm not going
| to read the equivalent of a novel for each and every
| request.
|
| I say this mostly because I think some level of
| inspectability would be useful for these larger requests.
| It just becomes impractical at larger and larger context
| sizes.
| kiitos wrote:
| > It is Impossible to add an unlimited number of tools to
| your agents context without negatively impacting the
| capability of your agent.
|
| Huh?
|
| MCP servers aren't just for agents, they're for any/all
| _clients_ that can speak MCP. And capabilities provided by a
| given MCP server are on-demand, they only incur a cost to the
| client, and only impact the user context, if/when they're
| invoked.
| noodletheworld wrote:
| > they only incur a cost to the client, and only impact the
| user context, if/when they're invoked.
|
| Look it up. Look up the cross server injection examples.
|
| I _guarantee_ you this is not true.
|
| An MCP server is at it's heart some 'thing' that provides a
| set of 'tools' that an LLM can invoke.
|
| This is done by adding a 'tool definition'.
|
| A 'tool definition' is content that goes into the LLM
| prompt.
|
| That's how it works. How do you imagine an LLM can decide
| to use a tool? It's _only possible_ if the tool definition
| is _in the prompt_.
|
| The API may hide this, but I _guarantee you_ this is how it
| works.
|
| Putting an arbitrary amount of 3rd party content into your
| prompts has a direct tangible impact on LLM performance
| (and cost). The more MCP servers you enable the more you
| pollute your prompt with tool definitions, and, I assure
| you, the worse the results are as a result.
|
| Just like pouring any large amount of unrelated crap into
| your system prompt does.
|
| At a small scale, it's ok; but as you scale _up_ , the LLM
| performance goes _down_.
|
| Here's some background reading for you:
|
| https://github.com/invariantlabs-ai/mcp-injection-
| experiment...
|
| https://docs.anthropic.com/en/docs/build-with-claude/tool-
| us...
| cruffle_duffle wrote:
| I think makers of LLM "chat bots" like the Claude desktop
| or cursor have a ways to go when it comes to exposing
| precisely what the LLM is being promoted.
|
| Because yes, for the LLM to find the MCP servers it needs
| that info on its prompt. And the software is currently
| hiding how that information is being exposed. Is it
| prepended to your own message? Does it put it at the
| start of the entire context? If yes, wouldn't real-time
| changes in tool availability invalidate the entire
| context? So then does it add it to end of the context
| window instead?
|
| Like nobody really has this dialed in completely.
| Somebody needs to make a LLM "front end" that is the raw
| de-tokenized input and output. Don't even attempt to
| structure it. Give me the input blob and output blob.
|
| ... I dunno. I wish these tools had ways to do more
| precise context editing. And more visibility. It would
| help make more informed choices on what to prompt the
| model with.
|
| /Ramble mode off.
|
| But slightly more serious; what is the token cost for a
| MCP tool? Like the llm needs its name, a description,
| parameters... so maybe like 100 tokens max per tool? It's
| not a lot but it isn't nothing either.
| kiitos wrote:
| I've recently written a custom MCP server.
|
| > An MCP server is at it's heart some 'thing' that
| provides a set of 'tools' that an LLM can invoke.
|
| A "tool" is one of several capabilities that a MCP server
| can provide to its callers. Other capabilities include
| "prompt" and "resource".
|
| > This is done by adding a 'tool definition'. A 'tool
| definition' is content that goes into the LLM prompt.
| That's how it works. How do you imagine an LLM can decide
| to use a tool? It's only possible if the tool definition
| is in the prompt.
|
| I think you're using an expansive definition of "prompt"
| that includes not just the input text as provided by the
| user -- which is generally what most people understand
| "prompt" to mean -- but also all available user- and
| client-specific metadata. That's fine, just want to make
| it explicit.
|
| With this framing, I agree with you, that every MCP
| server added to a client -- whether that's Claude.app, or
| some MyAgent, or whatever -- adds some amount of overhead
| to that client. But that overhead is gonna be fixed-cost,
| and paid one-time at e.g. session initialization, not
| every time per e.g. request/response. So I'm struggling
| to imagine a situation where those costs are anything
| other than statistical line noise, compared to the costs
| of actually processing user requests.
|
| > https://docs.anthropic.com/en/docs/build-with-
| claude/tool-us...
|
| To be clear, this concept of "tool" is completely
| unrelated to MCP.
|
| > https://github.com/invariantlabs-ai/mcp-injection-
| experiment...
|
| I don't really understand this repo or its criticisms.
| The authors wrote a related blog post
| https://invariantlabs.ai/blog/whatsapp-mcp-exploited
| which says (among other things) that
|
| > In this blog post, we will demonstrate how an untrusted
| MCP server ...
|
| But there is no such thing as "an untrusted MCP server".
| Every MCP server is assumed to be trusted, at least as
| the protocol is defined today.
| zoogeny wrote:
| > But that overhead is gonna be fixed-cost, and paid one-
| time at e.g. session initialization, not every time per
| e.g. request/response.
|
| I don't work for a foundational model provider, but how
| do you think the tool definitions get into the LLM? I
| mean, they aren't fine-tuning a model with your specific
| tools definitions, right? Your just using OpenAI's base
| model (or Claude, Gemini, etc.) So at some point the tool
| definitions have to be added to the prompt. It is just
| getting added to the prompt auto-magically by the
| foundation provider. That means it is eating up some
| context window, just a portion of the context window that
| is normally reserved for the provider, a section of the
| final prompt that you don't get to see (or alter).
|
| Again, while I don't work for these companies or
| implement these features, I cannot fathom how the feature
| could work unless it was added to every request. And so
| the original point of the thread author stands.
| kiitos wrote:
| You're totally right, in that: whatever MCP servers your
| client is configured to know about, have a set of
| capabilities, each of which have some kind of definition,
| all of which need to be provided to the LLM, somehow, in
| order to be usable.
|
| And you're totally right that the LLM is usually general-
| purpose, so the MCP details aren't trained or baked-in,
| and need to be provided by the client. And those details
| probably gonna eat up some tokens for sure. But they
| don't necessarily need to be included with every request!
|
| Interactions with LLMs aren't stateless request/response,
| they're session-based. And you generally send over
| metadata like what we're discussing here, or user-defined
| preferences/memory, or etc., as part of session
| initialization. This stuff isn't really part of a
| "prompt" at least as that concept is commonly understood.
| zoogeny wrote:
| I think we are confusing the word "prompt" here leading
| to miscommunication.
|
| There is the prompt that I, as a user, send to OpenAI
| which then gets used. There there is "prompt" which is
| being sent to the LLM. I don't know how these things are
| talked about internally at the company. But they take the
| "prompt" you send them and add a bunch of extra stuff to
| it. For example, they add in their own system message and
| they will add your system message. So you end up with
| something like <OpenAI system message> + <User system
| message> + <user prompt>. That creates a "final prompt"
| that gets sent to the LLM. I'm sure we both agree on
| that.
|
| With MCP, we are also adding in <tool description> to
| that final prompt. Again, it seems we are agreed on that.
|
| So the final piece of the argument is, as that "final
| prompt" (or whatever is the correct term) is growing. It
| is the size of the provider system prompt, plus the size
| of the user system prompt, plus the size of the tool
| description, plus the size of the actual user prompt. You
| have to pay that "final prompt" cost for each and every
| request you make.
|
| If the size of the "final prompt" affects the performance
| of the LLM, such that very large "final prompt" sizes
| adversely affect performance, than it stands to reason
| that adding many tool definitions to a request will
| eventually degrade the LLM performance.
| kiitos wrote:
| > With MCP, we are also adding in <tool description> to
| that final prompt. Again, it seems we are agreed on that.
|
| Interactions with a LLM are session-based, when you
| create a session there is some information sent over
| _once_ as part of that session construction, that
| information applies to all interactions made via that
| session. That initial data includes contextual
| information, like user preferences, model configuration
| as specified by your client, and MCP server definitions.
| When you type some stuff and hit enter that is a user
| prompt that may get hydrated with some additional stuff
| before it gets sent out, but it doesn't include any of
| that initial data stuff provided at the start of the
| session.
| empath75 wrote:
| "Sequential thinking" is one that I tried recently because so
| many people recommend it, and I have never, ever, seen the
| chatbot actually do anything but write to it. It never
| follows up any of it's chains of thoughts or refers to it's
| notes.
| DavidPP wrote:
| In which client and with which LLM are you using it?
|
| I use it in Claude Desktop for the right use case, it's
| much better than thinking mode.
|
| But, I admit, I haven't tried it in Cursor or with other
| LLMs yet.
| TeMPOraL wrote:
| Simple: if the choice is getting overwhelming to the LLM,
| then... divide and conquer - add a tool for choosing tools!
| Can be as simple as another LLM call, with prompt (ugh,
| "agent") tasked strictly with selecting a subset of available
| tools that seem most useful for the task at hand, and
| returning that to "parent"/"main" "agent".
|
| You kept adding more tools and now the tool-master "agent" is
| overwhelmed by the amount of choice? Simple! Add more
| "agents" to organize the tools into categories; you can do
| that up front and stuff the categorization into a database
| and now it's a rag. Er, RAG module to select tools.
|
| There are so many ways to do it. Using cheaper models for
| selection to reduce costs, dynamic classification,
| prioritizing tools already successfully applied in previous
| chat rounds (and more "agents" to evaluate if a tool
| application was successful)...
|
| Point being: just keep adding extra layers of indirection,
| and you'll be fine.
| soulofmischief wrote:
| The problem is that even just having the tools in the
| context can greatly change the output of the model. So
| there can be utility in the agent seeing contextually
| relevant tools (RAG as you mentioned, etc. is better than
| nothing) and a negative utility in hiding all of them
| behind a "get_tools" request.
| ezyang wrote:
| I quite liked this article, actually, and I'm quite an MCP stan.
| These all seem like legitimate problems that the burgeoning
| ecosystem needs to figure out. Some of them will be logically
| solved inside the MCP spec, but I also think some won't.
| jeswin wrote:
| > MCP servers can run (malicious code) locally.
|
| I wrote an MCP Server (called Codebox[1]) which starts a Docker
| container with your project code mounted. It works quite well,
| and I've been using it with LibreChat and vscode. In my
| experience, Agents save 2x the time (over using an LLM
| traditionally) and is less typing, but at roughly 3x the cost.
|
| The idea is to make the entire Unix toolset available to the LLM
| (such as ls, find), along with project specific tooling (such as
| typescript, linters, treesitter). Basically you can load whatever
| you want into the container, and let the LLM work on your project
| inside it. This can be done with a VM as well.
|
| I've found this workflow (agentic, driven through a Chat based
| interface) to be more effective compared to something like
| Cursor. Will do a Show HN some time next week.
|
| [1]: https://github.com/codespin-ai/codebox-js
| jillesvangurp wrote:
| Any interpreter can run malicious code. Mostly the guidance is:
| don't run malicious code if you don't want it to run. The
| problem isn't the interpreter/tool but the entity that's using
| it. Because that's the thing that you should be (mis)-trusting.
|
| The issue is two fold:
|
| - models aren't quite trustworthy yet.
|
| - people put a lot of trust in them anyway.
|
| This friction always exist with security. It's not a technical
| problem that can or should be solved on the MCP side.
|
| Part of the solution is indeed going to come from
| containerization. Give MCP agents access to what they need but
| not more. And part of it is going to come from some common
| sense and the tool UX providing better transparency into what
| is happening. Some of the better examples I've seen of Agentic
| tools work like you outline.
|
| I don't worry too much about the cost. This stuff is getting
| useful enough that paying a chunk of what normally would go
| into somebody's salary actually isn't that bad of a deal. And
| of course cost will come down. My main worry is actually speed.
| I seem to spend a lot of time waiting for these tools to do
| their thing. I'd love this stuff to be a bit zippier.
| jeswin wrote:
| > Give MCP agents access to what they need but not more.
|
| My view is that you should give them (Agents) a computer,
| with a complete but minimal Linux installation - as a VM or
| Containerized. This has given me better results, because now
| it can say fetch information from the internet, or do
| whatever it wants (but still in the sandbox). Of course,
| depending on what you're working on, you might decide that
| internet access is a bad idea, or that it should just see the
| working copy, or allow only certain websites.
| jacobr1 wrote:
| If you give it access to the internet ... it can basically
| do anything, exfil all your code, receive malicious
| instructions. The blast radius (presuming it doesn't get
| out of your sandbox) is limited to loss of whatever your
| put in (source code) and theft of resources (running a
| coinminer, host phishing attacks, etc ...). As you say, you
| can limit things to trusted websites which helps .. but
| even then, if you trust, say github, anyone can host
| malicious instructions. The risk tradeoffs (likelihood of
| of hitting malicious instruction, vs productivity benefit)
| might nevertheless be worth it ... not to much targetted
| maliciousness in wild yet. And just a bit more gaurdrailing
| and logging can go a long way.
| ycombinatrix wrote:
| >now it can say fetch information from the internet...(but
| still in the sandbox)
|
| If it is talking to the internet, it is most definitely not
| sandboxed.
| peterlada wrote:
| Let me give you some contrast here:
|
| - employees are not necessarily trustworthy
|
| - employers place a lot of trust in them anyway
| mdaniel wrote:
| This argument comes up a lot, similar to the "humans lie,
| too" line of reasoning
|
| The difference in your cited case is that employees are a
| class of legal person which is subject to the laws of the
| jurisdiction in which they work, along with any legal
| contracts they signed as a condition of their employment.
| So, that's a shitload of words to say "there are
| consequences" which isn't true of a bunch of matrix
| multiplications that happen to speak English and know how
| to invoke RPCs
| lacker wrote:
| Is anyone successfully using Claude Code along with MCP?
|
| I feel like I hear very many stories of some company integrating
| with MCP, many fewer stories from users about how it helps them.
| zoogeny wrote:
| I've heard the opposite, stories from users that MCP has been a
| flop. One of my acquaintances works in marketing and is a heavy
| LLM user. He got swept up in the hype of MCPs and tried a bunch
| of them out. He was expressing his disappointment and
| frustration.
|
| It is a drawback of hype and early adoption. I think highly
| technical users can get value out of it for now and can keep
| their expectations in line. If I am building my own MCP server
| and it is a bit flaky, I manage that responsibility myself. If
| I am wiring up a MCP server that makes some claims of
| automating some workflow and it doesn't work, then I negatively
| associate that with the very idea of MCP.
| israrkhan wrote:
| I feel MCP emerged too quickly. It will take some time and
| further protocol versions/enhancements for it to mature, and
| address stuff like security. Also it was not vetted by a
| conventional standards body, but just made public by a company.
| Lots of hype around it, everyone seems to be talking MCP these
| days.
| sgt101 wrote:
| This is a key point - where are the applications?
|
| Normally we have a standard when we have applications, but I am
| not seeing these yet... perhaps I am blind and mad!
| jacobr1 wrote:
| Three big places:
|
| 1 - Claude Desktop (and some more niche AI chat apps) - you
| can use MCPs to extend these chat systems today. I use a
| small number daily.
|
| 2 - Code Automation tools - they pretty much all have added
| MCP. Cursor, Claude Code, Cline, VSCode GH Codepilot, etc ...
|
| 3 - Agent/LLM automation frameworks. There are a ton of tools
| to build agentic apps and many support using MCP to to
| integrate third party APIs with limited to no boilerplate.
| And if there are are large libraries of every third party
| system you can imagine (like npm - but for APIs) then these
| are going to get used.
|
| Still early days - but tons of real use, at least by the
| early adopter crowd. It isn't just a spec sitting on a shelf
| for all the many faults.
| sgt101 wrote:
| These examples seem to be tools built on this tool - which
| is cool and all, but it's not the equivalent of "a mail
| order catalogue you can access through your computer", or
| "a replacement for a travel agent".
|
| What are the applications at the level of Amazon.com,
| Expedia, or Hacker News?
| cruffle_duffle wrote:
| They are little things like "hey I want to get the LLM to
| fetch logs from elasticsearch" or "hey I want to create a way
| for the LLM to query my database in a more structured way".
|
| And yeah in theory openapi can do it but not nearly as token
| efficient or user efficient. OpenAPI doesn't help actually
| "connect" the LLM to anything, it's not a tool itself but a
| spec. To use an OpenAPI compliant server you'd still need to
| tell the LLM how to authenticate, what the server address is,
| what tool needs to be used to call out (curl?) and even then
| you'd still need an affordance for the LLM to even make that
| call to curl. That "afforance" is exactly what MCP defines.
| It provides a structured way for the LLM to make tool calls.
| seinecle wrote:
| A natural follow up: is Google's newly launched a2a better
| equipped to handle these security issues?
| krige wrote:
| Does it at least say "END OF LINE" and banish wannabe hackers to
| the game grid?
| otabdeveloper4 wrote:
| > It's so over
|
| > We are so back
| sixhobbits wrote:
| I'm sure MCP does have legitimate problems and some might even be
| covered in this article but the author would benefit by spending
| more time refining their criticisms.
|
| There's a whole section on how people can do things like analyse
| a combination of slack messages, and how they might use that
| information. This is more of an argument suggesting agents are
| dangerous. You can think MCP is a good spec that lets you create
| dangerous things but conflating these arguments under "mcp bad"
| is disingenuous.
|
| Id rather have more details and examples on the problem with the
| spec itself. "You can use it to do bad things" doesn't cut it. I
| can use http and ssh to bad things too, so it's more interesting
| to show how Eve might use MCP to do malicious things to Alice or
| Bob who are trying to use MCP as intended.
| lbeurerkellner wrote:
| I think what is not to be overlooked in these discussions, is the
| user base of MCP.
|
| In my experience, many less-technical folks started using MCP,
| and that makes security issues all the more relevant. This
| audience often lacks intuition around security best-practices. So
| it's definitely important to raise awareness around this.
| madrox wrote:
| Nothing the author said is wrong, but I don't know how much it
| matters or if it would've been better if it handled all this out
| of the gate. I think if MCP were more complicated no one would've
| adopted it.
|
| Being pretty close to OAuth 1.0 and the group that shaped it I've
| seen how new standards emerge, and I think it's been so long
| since new standards mattered that people forgot how they happen.
|
| I was one of the first people to criticize MCP when it launched
| (my comment on the HN announcement specifically mentioned auth)
| but I respect the groundswell of support it got, and at the end
| of the day the standard that matters is the one people follow,
| even if it isn't the best.
| a3w wrote:
| BetaMax is better than VHS, the latter won.
|
| Rkt is better than Docker, later won.
|
| ${TBD} is better than MCP, my bet is on MCP.
| mdaniel wrote:
| > Rkt is better than Docker, later won.
|
| Your experience with rkt is _way_ different from mine. I would
| gladly accept "podman is..." or even "nerdctl is..." but I
| hate rkt so much and was thrilled when it disappeared from my
| life
| rcarmo wrote:
| There is one thing I pointed out in
| https://taoofmac.com/space/notes/2025/03/22/1900 and seems to be
| missing from the article:
|
| "... MCP tends to crowd the model context with too many options.
| There doesn't seem to be a clear way to set priorities or a set
| of good examples to expose MCP server metadata-so your model API
| calls will just pack all the stuff an MCP server can do and shove
| it into the context, which is both wasteful of tokens and leads
| to erratic behavior from models."
| sshh12 wrote:
| It's in there briefly in the llm limitations section.
| jascha_eng wrote:
| Something that I struggle with in regards to MCP and no-ones
| really touches on: We don't even know if this "general" Chatbot
| paradigm will persist. So far I got the feeling that we end up
| building specialized apps for specialized use-cases (e.g. cursor
| or claude code for coding) These then bring their own set of
| tools (for file writing, reading, running bash commands, etc.)
| and don't really need MCP (except for very niche use-cases
| maybe).
|
| I don't really see the point yet where LLMs become so good that I
| throw my specialized LLM tools out and do everything in one
| claude desktop window. It simply doesn't work generic enough.
|
| Also... if you end up building something custom, you end up
| having to reimplement the tool calling again anyways. MCP really
| is just for the user facing chat agents, which is just one
| section of AI applications. It's not as generically applicable as
| implied.
| fragmede wrote:
| If you have a better idea you could get millions in VC funding
| to pursue that. Chat is where it's at. It's fine to think that
| it's not gonna be the be-all and end-all of AI, but it's pretty
| fundamentally how we interact with each other, so I don't see
| it going away any time soon. There's also a thing as being too
| generic. So really they just hit this sweet spot.
| skydhash wrote:
| > _If you have a better idea you could get millions in VC
| funding to pursue that._
|
| I would like to see:
|
| - Some Smalltalk-like IWE (Integrated Work Environment),
| creating prompt snippets and chaining them together.
|
| - A spreadsheet like environment. Prompt's result are always
| tables and you have the usual cell reference available.
| zoogeny wrote:
| Interestingly, my criticism is exactly the opposite of yours. I
| think as LLMs become more and more capable (and crucially
| multi-modal) we will need the external tools less and less.
|
| For example, why would I want an MCP that can drive Photoshop
| on my behalf? Like I say to the LLM "remove this person from
| the photo" and it opens Photoshop, uses the magic wand select
| tool, etc. That is silly in my mind. I want to say "remove this
| person" and the LLM sends me a perfect image with the person
| gone.
|
| I extend that idea for just about any purpose. "Edit this video
| in such and such a way". "Change this audio in such and such a
| way". "Update this 3d model in such and such a way". No tool
| needed at all.
|
| And that will lead to more multi-modal input. Like, if I could
| "mark up" a document with pen marks, or an image. I want tools
| that are a bit better than language for directing the attention
| of the model towards the goals I want them to achieve. Those
| will be less "I am typing text into a chat interface with
| bubbles" but the overall conversational approach stays intact.
| torginus wrote:
| Is it just me, or is this thing really, really stupid?
|
| I mean the whole AI personal assistant shebang from all possible
| angles.
|
| Imagine, for example if booking.com built an MCP server allowing
| you to book a hotel room, query all offers in an area in a given
| time, quickly, effortlessly, with a rate limit of 100
| requests/caller/second, full featured, no hiding or limiting
| data.
|
| That would essentially be asking them to just offer you their
| internal databases, remove their ability to show you ads, remove
| the possibility to sell advertisers better search rankings, etc.
|
| It would be essentially asking them to keel over and die, and
| voluntarily surrender all their moat.
|
| But imagine for a second they did do that. You get the API, all
| the info is there.
|
| Why do you need AI then?
|
| Let's say you want to plan a trip to Thailand with your family.
| You could use the fancy AI to do it for you, or you could build a
| stupid frontend with minimal natural language understanding.
|
| It would be essentially a smart search box, where you could type
| in 'book trip to Thailand for 4 people, 1 week, from July 5th',
| and then it would parse your query, call out to MCP, and display
| the listings directly to you, where you could book with a click.
|
| The AI value add here is minimal, even non-existent.
|
| This applies to every service under the sun, you're essentially
| creating a second Internet just for AIs, without all the BS
| advertising, fluff, clout chasing and time wasting. I, as a human
| am dying to get access to that internet.
|
| Edit: I'm quite sure this AI MCP future is going to be
| enshittified in some way.
| FirmwareBurner wrote:
| _" What is Hooli? Excellent question. Hooli isn't just another
| high tech company. Hooli isn't just about software.
| Hooli...Hooli is about people. Hooli is about innovative
| technology that makes a difference, transforming the world as
| we know it. Making the world a better place, through minimal
| message oriented transport layers. I firmly believe we can only
| achieve greatness if first we achieve goodness."_
| bob1029 wrote:
| It's not just you.
|
| However, I would say that I've grown to accept that most people
| prefer these more constrained models of thinking. Constraints
| can help free the mind up in other ways. If you do not perceive
| MCP as constraining, then you should definitely use it. Wait
| until you can feel the pain of its complexity and become
| familiar with it. This will be an excellent learning
| experience.
|
| Also consider the downstream opportunities that this will
| generate. Why not plan a few steps ahead and start thinking
| about a consultancy for resolving AI microservices
| clusterfucks.
| sgt101 wrote:
| This is what torpedoed the first AI Assistant push in the late
| 1990's and early 2000s (see electric elves as an example).
| Basically we thought that personal travel assistants and open
| trading platforms would be cool things, but then discovered
| that content aggregators a) had a business model and b) could
| offer vertical integration and bulk buys, & discounts to goods
| providers and consumers, while also policing the platform. So
| we got Expedia and Ebay.
|
| There is a more fundamental problem as well. Multi-agent
| systems require the programmer of the agent to influence the
| state of the agent in order that the agent can act to influence
| the states of other agents in the system. This is a very hard
| programming task.
| criley2 wrote:
| It doesn't make sense for a middleman like booking.com to let
| you completely bypass everything they offer.
|
| However it certainly might make sense for an individual hotel
| to let you bypass the booking.com middleman (a middleman that
| the hotel dislikes already).
|
| Scenario 1: You logon to booking.com, deal with a beg to join a
| subscription service (?), block hundreds of ads and trackers,
| just to search searching through page after page of slop trying
| to find a matching hotel. You find it, go to the hotels actual
| webpage and book there, saving a little bit of money.
|
| Scenario 2: You ask your favorite Deep Research AI (maybe
| they've come up with Diligent Assistant mode) to scan for Thai
| hotels meeting your specific criteria (similar to the search
| filters you entered on booking.com) and your AI reaches out to
| Hotel Discovery MCP servers run by hotels, picks a few matches,
| and returns them to you with a suggestion. You review the
| results and select one. The AI agent points out some helpful
| deals and rewards programs that might apply. Your AI completes
| the booking.
|
| The value that AI gave you is you no longer did the searching,
| dealt with the middleman, viewed the ads, got begged to join a
| subscription service, etc.
|
| However to the hotel, they already don't really like
| booking.com middleman. They already strongly prefer you book
| directly with them and give you extra benefits for doing so.
| From the hotel's perspective, the AI middleman is cheaper to
| them than booking.com and still preserves the direct business
| relationship.
| viraptor wrote:
| You're arguing against your own straw man. "Imagine, for
| example if booking.com built an MCP server allowing you to book
| a hotel room (...) no hiding or limiting data." They're not
| doing that and they're not interested in that. Yes, they would
| need a public API for that and people could use it directly.
| But that's not happening.
|
| MCP makes sense where the API already exists and makes the
| biggest difference if the API call is just a part of the
| process, not the only and final action.
|
| Even in the booking example, you could push much more of your
| context into the process and integrate other tools. Rank the
| results by parking availability or distance to the nearest
| public/street parking, taking your car's height into account,
| looking through reviews for phrases you care about (soft bed,
| child care, ...) and many others things. So now we've got
| already 4+ different tools that need to work together,
| improving the results.
| jacobr1 wrote:
| If computer use gets good enough (it isn't just yet ... but it
| is getting better _fast_) then it doesn't matter, you'll be
| able to browse the sites the same way a human does to bypass
| whatever shit they want to toss in your way. This makes their
| business models much more precarious. Also it makes removing
| the aggregator easier - you could search for the hotels, query
| their sites directly. Hotels and airlines have been trying to
| cut out middlemen for years, they just can't afford to lose the
| inbound traffic/sales it gives them. But the dynamic shifts
| every 5-10 years in small ways. Maybe this will be a big shift.
|
| That said, even if the equilibrium changes from today (and I
| think it will) I still share your cynicism that
| enshittification will ensue in some form. One example right now
| is the increasing inability to trust any reviews from any
| service.
| dboreham wrote:
| Yes, the metaproblem is: it has to make money. It turns out
| that "doing genuinely useful things for end users" almost never
| makes money. I found this out long ago when I had the
| experience that booking air travel for optimized
| cost/convenience was a total pain. I figured software can solve
| this, so built a ticket search engine that supported the query
| semantics a human typically wants. Dumb idea because you can't
| get the data over which to search except from airlines, and
| airlines know that making it convenient to find low convenient
| fares makes them less money. So they won't give you the data.
| In fact the entire problem "finding cheap convenient air fare"
| is actually there in support of someone else's (the airlines)
| business model.
| tomjen3 wrote:
| I don't buy it.
|
| If they had an API Booking would not likely return their data
| to you, they would almost certainly have an API that you would
| search and which would then return the same result you get on
| their website. Probably with some nice JSON or XML formatting.
|
| Booking makes a small amount of ads, but they are paid by the
| hotels that you book with. And yes, today they already have to
| compete with people who go there see a hotel listing and go
| find the actual hotel off-site. That would not really change if
| they create an MCP.
|
| It might make it marginally more easy to do, especially
| automatically. But I suspect the real benefits of booking.com
| is: A) that you are perceived to get some form of discount and
| B) you get stamps toward the free stay. And of course the third
| part which is you trust Booking more than some random hotel.
|
| I actually think it would be a good idea for Booking to have an
| API. What is the alternative?
|
| I can right now run a Deep search for great hotels in Tokyo -
| that will probably go through substantially all hotels in
| Tokyo. Go to the hotel's website and find the information, then
| search through and find exactly what I want.
|
| Booking.com might prefer I go go to their website, but I am
| sure they would prefer above all that you book through them.
|
| In fact I think the idea of advertisement is given above impact
| here, possibly because its a popular way for the places that
| employ the kind of people who post here to make money, but
| substantially all businesses that are not web-based and that do
| not sell web-based services for free don't make their money
| through ads (at least not directly). For all those places ads
| are an expense and they would much prefer your AI search their
| (comparably cheap to serve) websites.
|
| Basically, the only website owners who should object to you
| going to their website through an AI agent are those who are in
| the publishing industry and who primarily make money through
| ads. That is a small number of all possible businesses.
| zoogeny wrote:
| Companies that want to maintain a data moat will work to
| maintain that moat in the face of any new technology.
|
| But not all data in the world is protected in that way. The use
| cases they promote are just easy to grasp, although they are
| misleading due to the reality that those examples are often
| ones protected by data moats.
|
| I mean, I doubt Facebook is going to create an MCP that allows
| you to deeply access your social graph in a way that will allow
| you to bypass whatever tracking they want to do to feed their
| ad business. But Blender, the open source 3d application, may
| provide a decent MCP to interact with their application. And
| Wikipedia might get a few decent MCP integrations to expose
| their knowledge base for easier integration with LLMs (although
| less useful I suppose considering every LLM would be trained on
| that data anyway).
|
| I guess it is just a matter of optimism vs. pessimism, (glass
| half empty vs. glass half full). MCP won't make data moats
| disappear, but they may make data that isn't behind a moat
| easier to work with for LLMs.
| novoreorx wrote:
| How well the protocol is designed doesn't matter, the most
| popular choice is not necessarily the best one. Sometimes "worse
| is better."
| _pdp_ wrote:
| Like IE6?
| jtrn wrote:
| What do we gain by using MCP that cloud not be achieved worth
| OpenAPI standard. It feels extremely redundant to me.
| emilsedgh wrote:
| The biggest advantage of this is for the llm providers like OAI
| not application developers.
|
| LLM's are brains with no tools (no hands, legs, etc).
|
| When we use tool calling we use them to empower the brain. But
| using normal API's the language model providers like OpenAI
| have no access to those tools.
|
| With MCP they do. The brain they create can now have access to
| a lot of tools that the community builds directly _from_ llm,
| not through the apps.
|
| This is here to make ChatGPT/Claude/etc _the gateway_ to AI
| rather than them just being API providers for other apps.
| cruffle_duffle wrote:
| What will the LLM use to call out to an OpenAPI system? Will it
| use a shell command like curl? How will it bind to the shell?
| How will the LLM's host orchestrate that on the LLM's behalf?
|
| And who will define the credentials? And what is the URL? Oh,
| those are in the environment variables? How will the LLM get
| that info? Do I need to prompt the LLM all that info, wasting
| context window on minutia that has nothing to do with my task?
|
| ...if only there was a standard for _that_ ... I know! Maybe it
| can provide a structured way for the LLM to call curl and
| handle all the messy auth stuff and smooth over the edges
| between operating systems and stuff. Perhaps it can even think
| ahead and load the OpenAPI schema and provide a structured way
| to navigate such a large "context blowing" document so the LLM
| doesn't have to use precious context window figuring it out?
| But at that point why not just provide the LLM with pre-built
| wrappers on top specifically for whatever problem domain the
| rest api is dealing with?
|
| Maybe we can call this protocol MCP?
|
| Because think about it. OpenAPI doesn't help the LLM actually
| reach out and talk to the API. It still needs a way to do that.
| Which is precisely what MCP does.
| jtrn wrote:
| So why do I have to make an MCP server? Could it not just
| hook into the OpenAPI JSON spec?
|
| And who will define the credentials? The OpenAPI spec defines
| the credentials. MCP doesn't even allow for credentials, it
| seems, for now. But I don't think deleting a requirement is a
| good thing in this instance. I would like to have an API that
| I could reach from anywhere on the net and could secure with,
| for instance, an API key.
|
| And what is the URL? You have to define this for MCP also.
| For instance, in Cursor, you have to manually enter the
| endpoint with a key named "url."
|
| How will the LLM get that info? This was shown to be easily
| 1.5 years ago with GPT's easy understanding of the OpenAPI
| spec and its ability to use any endpoint on the net as a
| tool.
|
| I don't disagree that there needs to be a framework for using
| endpoints. But why can't it reach out to an OpenAPI endpoint?
| What do we gain from using a new "protocol"? I created a
| couple of MCP servers, and it just feels like going back 10
| years in progress for creating and documenting web APIs.
|
| Let me ask you this in reverse then: Have you created a basic
| API and used it as a tool in a GPT? And have you created an
| MCP server and added it to applications on your computer? If
| you have done both and still feel that there is something
| better with MCP, please tell, because I found MCP to be
| solving an issue that didn't need solving.
|
| Create an awesome framework for reaching out to Web APIs and
| read the OpenAPI definition of the endpoint? GREAT! Enforce a
| new Web API standard that is much less capable than what we
| already have? Not so great.
|
| You seem to miss that an MCP server IS an HTTP server
| already. It's not just safe to expose it to the net and
| contains a new and limited spec for how to document and set
| it up.
| serbuvlad wrote:
| This article reads less like a criticism of MCP, the internal
| technical details of which I don't know that much about, and they
| make the subject of but a part of the srticle, but a general
| criticism of the general aspect of "protocol to allow LLM to run
| actions on services"
|
| A large problem in this article stems from the fact that the LLM
| may take actions I do not want it to take. But there are clearly
| 2 types of actions the LLM can take: those I want it to take on
| it's own, and those I want it to take only after prompting me.
|
| There may come a time when I want the LLM to run a business for
| me, but that time is not yet upon us. For now I do not even want
| to send an e-mail generated by AI without vetting it first.
|
| But the author rejects the solution of simply prompting the user
| because "it's easy to see why a user might fall into a pattern of
| auto-confirmation (or 'YOLO-mode') when most of their tools are
| harmless".
|
| Sure, and people spend more on cards than they do with cash and
| more on credit cards than they do on debit cards.
|
| But this is a psychological problem, not a technological one!
| angusturner wrote:
| I have been developing with MCP for a few weeks now, making some
| small python and javascript servers to integrate with Claude
| Desktop.
|
| I am yet to see a use case that wouldn't be better served with an
| HTTP API. I understand the need to standardize some conventions
| around this, but at the heart of it, all "tool" use boils down
| to: 1. an API endpoint to expose capabilities / report the API
| schema 2. other endpoints ("tools") to expose functionality
|
| Want state? ("resources") - put a database or some random in-
| memory data structure behind an API endpoint. Want "prompts"?
| This is just a special case of a tool.
|
| Fundamentally (like most everyone else experimenting with this
| tech), I need an API that returns some text and maybe images. So
| why did I just lose two days trying to debug the Python MCP SDK,
| and the fact that its stdio transport can't send more than a few
| KB without crashing the server?
|
| If only there was a stateless way to communicate data between a
| client and a server, that could easily recover from and handle
| errors...
| crabmusket wrote:
| APIs aren't self describing by default, but it feels like a
| missed opportunity for REST and HATEOAS proponents to show the
| value in those approaches. I've always said REST is for human
| clients, and LLMs seem like they should be human enough for
| this kind of thing.
| ikiris wrote:
| Rest is for people who thought xml was a good idea.
| crabmusket wrote:
| XML _was_ a good idea -\\_(tsu)_ /-
| codydkdc wrote:
| the only one of these points I personally care about is:
|
| > The protocol has a very LLM-friendly interface, but not always
| a human friendly one.
|
| similar to the people asking "why not just use the API directly",
| I have another question: why not just use the CLI directly? LLMs
| are trained on natural language. CLIs are an extremely common
| solution for client/server interactions in a human-readable,
| human-writeable way (that can be easily traversed down
| subcommands)
|
| for instance, instead of using the GitHub MCP server, why not
| just use the `gh` CLI? it's super easy to generate the help and
| feed it into the LLM, super easy to allow the user to inspect the
| command before running it, and already provides a sane exposure
| of the REST APIs. the human and the LLM can work in the same way,
| using the exact same interface
| jacobr1 wrote:
| FWIW - that is what claude code does, at least how I use it. It
| uses the BashTool to call `gh`
| jappgar wrote:
| Amazing to see so many comments out here in support of a very new
| and very boring protocol.
|
| I have to think the enthusiasm is coming mostly from the vibe-
| coding snakeoil salespeople that seem to be infecting every
| software company right now.
| cruffle_duffle wrote:
| Alternatively it's actually pretty cool and useful and you just
| personally don't have a use for it?
| mlenhard wrote:
| One of the biggest issues I see, briefly discussed here, is how
| one MCP server tool's output can affect other tools later in the
| same message thread. To prevent this, there really needs to be
| sandboxing between tools. Invariant labs did this with tool
| descriptions [1], but I also achieved the same via MCP resource
| attachments[2]. It's a pretty major flaw exacerbated by the type
| of privilege and systems people are giving MCP servers access to.
|
| This isn't necessarily the fault of the spec itself, but how most
| clients have implemented it allows for some pretty major prompt
| injections.
|
| [1] https://invariantlabs.ai/blog/mcp-security-notification-
| tool... [2] https://www.bernardiq.com/blog/resource-poisoning/
| cyanydeez wrote:
| Isn't this basically a lot of hand waving that ends up being
| isomorphic to SQL injection?
|
| Thats what we're talking about? A bunch of systems cobbled
| together where one could SQL inject at any point and there's
| basically zero observability?
| mlenhard wrote:
| Yeah, you aren't far off with SQL injection comparison. That
| being said it's not really a fault of the MCP spec, more so
| with current client implementations of it.
| seanhunter wrote:
| Yes, and the people involved in all this stuff have also
| reinvented SQL injection in a different way in the prompt
| interface, since it's impossible[1] for the model to tell
| what parts of the prompt are trustworthy and what parts are
| tainted by user input, no matter what delimeters etc you try
| to use. This is because what the model sees is just a bunch
| of token numbers. You'd need to change how the encoding and
| decoding steps work and change how models are trained to
| introduce something akin to the placeholders that solve the
| sql injection problem.
|
| Therefore it's possible to prompt inject _and_ tool inject.
| So you could for example prompt inject to get a model to call
| your tool which then does an injection to get the user to run
| some untrustworthy code of your own devising.
|
| [1] See the excellent series by Simon Willison on this
| https://simonwillison.net/series/prompt-injection/
| superfreek wrote:
| Great point in the article about tools lacking output schemas.
| Makes reliable multi-step planning tough.
|
| We based Xops (https://xops.net) on OpenRPC for this exact reason
| (disclosure: we are the OpenRPC founders). It requires defining
| the result schema, not just params, which helps plan how outputs
| connect to the any step's inputs. Feels necessary for building
| complex workflows and agents reliably.
| Havoc wrote:
| Much like the early days of JS and APIs in general this is
| presumably going to need time to evolve and settle.
| cynicalpeace wrote:
| MCP has a LangChain smell.
|
| Doesn't solve a pressing problem that can't be solved via a few
| lines of code.
|
| Overly abstract.
|
| Tons of articles trying to explain its advantages, yet all
| somehow fail.
| kordlessagain wrote:
| MCP is built on JSON-RPC 2.0. JSON-RPC 2.0 is a super
| lightweight, stateless protocol that lets a client and a server
| talk to each other using plain old JSON. It's not tied to HTTP,
| but it often rides on it. It's like the chill cousin of REST: no
| verbs, no URL gymnastics--just methods and parameters, passed as
| structured JSON.
|
| MCP calls itself a "protocol," but let's be honest--it's a
| framework _description_ wrapped in protocol cosplay. Real
| protocols define message formats and transmission semantics
| across transport layers. JSON-RPC, for example, is dead simple,
| dead portable, and works no matter who implements it. MCP, on the
| other hand, bundles prompt templates, session logic, SDK-specific
| behaviors, and application conventions--all under the same
| umbrella.
|
| As an example, I evidently need to install something called "uv",
| using a piped script pulled in from the Internet, to "run" the
| tool, which is done by putting this into a config file for Claude
| Desktop (which then completely hosed my Claude Desktop):
| { "mcpServers": { "weather": {
| "command": "uv", "args": [ "run",
| "--with", "fastmcp", "fastmcp",
| "run", "C:\\Users\\kord\\Code\\mcptest\\weather.py"
| ] } } }
|
| They (the exuberant authors) do mention transport--stdio and HTTP
| with SSE--but that just highlights the confusion here we are
| seeing. A real _protocol_ doesn't care how it's transported, or
| it defines the transport clearly. MCP tries to do both and ends
| up muddying the boundaries. And the auth situation? It waves
| toward OAuth2.1, but offers almost zero clarity on
| implementation, trust delegation, or actual enforcement. It's a
| rats nest waiting to unravel once people start pushing for real-
| world deployments that involve state, identity, or external APIs
| with rate limits and abuse vectors.
|
| This feels like yet another centralized spec written for one
| ecosystem (TypeScript AI crap), claiming universality without
| earning it.
|
| And let's talk about streaming vs formatting while we're at it.
| MCP handwaves over the reality that content coming in from a
| stream (like SSE) has totally different requirements than a local
| response. When you're streaming partials from a model and
| interleaving tool calls, you need a very well-defined contract
| for how to chunk, format, and parse responses--especially when
| tools return mid-stream or you're trying to do anything
| interactive.
|
| Right now, only a few clients are actually supported (Anthropic's
| Claude, Copilot, OpenAI, and a couple local LLM projects). But
| that's not a bug--it's the feature. The clients are where the
| value capture is. If you can enforce that tools, prompts, and
| context management only work smoothly inside your shell, you keep
| devs and users corralled inside your experience. This isn't open
| protocol territory; it's marketing. Dev marketing dressed up as
| protocol design. Give them a "standard" so they don't ask
| questions, then upsell them on hosted toolchains, orchestrators,
| and AI-native IDEs later. The LLM is the bait. The client is the
| business.
|
| And yes, Claude helped write this, but it's exactly what I would
| say if I had an hour to type it out clearly.
| pgt wrote:
| MCP is just a transport + wire format with request/response
| lifecycle and most importantly: tool-level authorization.
|
| The essay misses the biggest problem with MCP: 1.
| it does not enable AI agents to functionally compose tools.
| 2. MCP should not exist in the first place.
|
| LLMs already know how to talk to every API that documents itself
| with OpenAPI specs, but the missing piece is authorization. Why
| not just let the AI make HTTP requests but apply authorization to
| endpoints? And indeed, people are wrapping existing APIs with
| thin MCP tools.
|
| Personally, the most annoying part of MCP is the lack of support
| for streaming tool call results. Tool calls have a single
| request/response pair, which means long-running tool calls can't
| emit data as it becomes available - the client has to repeat a
| tool call multiple times to paginate. IMO, MCP could have used
| gRPC which is designed for streaming. Need an onComplete trigger.
|
| I'm the author of Modex[^1], a Clojure MCP library, which is used
| by Datomic MCP[^2].
|
| [^1]: Modex: Clojure MCP Library -
| https://github.com/theronic/modex
|
| [^2]: Datomic MCP: Datomic MCP Server -
| https://github.com/theronic/datomic-mcp/
| keithwhor wrote:
| I mean you don't need gRPC. You can just treat all tool calls
| as SSEs themselves and you have streaming. HTTP is pretty
| robust.
| pgt wrote:
| HTTP Server-Sent Events (SSE) does not natively support
| batched streaming with explicit completion notifications in
| its core specification.
| cruffle_duffle wrote:
| There are plenty of things out there that don't use OpenAPI. In
| fact most things aren't.
|
| Even if the universe was all OpenAPI, you'd still need a lower
| level protocol to define exactly how the LLM reaches out of the
| box and makes the OpenAPI call in the first place. That is what
| MCP does. It's the protocol for calling tools.
|
| It's not perfect but it's a start.
| taeric wrote:
| I mean... you aren't wrong that OpenAPI doesn't have
| universal coverage. This is true. Neither did WSDL and
| similar things before it.
|
| I'm not entirely clear on why it make sense to jump in with a
| brand new thing, though? Why not start with OpenAPI?
| cruffle_duffle wrote:
| Because OpenAPI doesn't solve the problem that MCP does.
| How does the LLM and its host make tool calls?
|
| OpenAPI doesn't solve that at all.
| taeric wrote:
| Most of the bookkeeping in how to make calls should be
| covered in the same details for how anything else makes a
| call? I'm not clear what makes this different? If
| necessary, you could add specific data types for this,
| but the general ideas are almost certainly close enough
| to there that a whole new thing doesn't bring in too
| much?
| pgt wrote:
| AI can read docs, Swagger, OpenAI and READMEs, so MCP adds
| nothing here. All you need is an HTTP client with
| authorization for endpoints.
|
| E.g. in Datomic MCP[^1], I simply tell the model that the
| tool calls datomic.api/q, and it writes correct Datomic
| Datalog queries while encoding arguments as EDN strings
| without _any_ additional READMEs about how EDN works, because
| AI knows EDN.
|
| And AI knows HTTP requests, it just needs an HTTP client,
| i.e. we don't need MCP.
|
| So IMO, MCP is an Embrace, Extend (Extinguish?) strategy by
| Anthropic. The arguments that "foundational model providers
| don't want to deal with integration at HTTP-level" are
| uncompelling to me.
|
| All you need is an HTTP client + SSE support + endpoint authz
| in the client + reasonable timeouts. The API docs will do the
| rest.
|
| Raw TCP/UDP sockets more dangerous, but people will expose
| those over MCP anyway.
|
| [^1]: https://github.com/theronic/datomic-
| mcp/blob/main/src/modex/...
| resters wrote:
| > 1. it does not enable AI agents to functionally compose
| tools.
|
| Is there something about the OpenAI tool calling spec that
| prevents this?
| pgt wrote:
| I haven't looked at the OpenAI tool calling spec, but the
| lack of return types in MCP, as reported by Erik Meijers,
| makes composition hard.
|
| Additionally, the lack of typed encodings makes I/O
| unavoidable because the model has to interpret the schema of
| returned text values first to make sense of it before passing
| it as input to other tools. Makes it impossible to pre-
| compile transformations while you wait on tool results.
|
| IMO endgame for MCP is to delete MCP and give AI access to a
| REPL with eval authorized at function-level.
|
| This is why, in the age of AI, I am long dynamic languages
| like Clojure.
| pgt wrote:
| Previous thoughts on MCP, which I won't rehash here:
|
| - "MCP is a schema, not a protocol" -
| https://x.com/PetrusTheron/status/1897908595720688111
|
| - "PDDL is way more interesting than MCP" -
| https://x.com/PetrusTheron/status/1897911660448252049
|
| - "The more I learn about MCP, the less I like it"
| https://x.com/PetrusTheron/status/1900795806678233141
|
| - "Upon further reflection, MCP should not exist"
| https://x.com/PetrusTheron/status/1897760788116652065
|
| - "in every new language, framework or paradigm, there is a
| guaranteed way to become famous in that community" -
| https://x.com/PetrusTheron/status/1897147862716457175
|
| I don't know if it's taboo to link to twitter, but I ain't
| gonna copypasta all that.
| kiitos wrote:
| MCP is literally defined as a protocol.
|
| It doesn't have anything to say about the transport layer,
| and certainly doesn't mandate stdio as a transport.
|
| > The main feature of MCP is auth
|
| MCP has no auth features/capabilities.
|
| I think you're tilting at windmills here.
| pgt wrote:
| I regret to inform you that you are the victim of quality
| control, Sir @kiitos:
|
| 1. MCP specifies two transport layers: stdio/stdout + HTTP
| w/SSE [^1]
|
| 2. MCP specifies JSON-RPC as the wire format [^2].
|
| In my opinion, this is a schema on top of a pre-existing
| RPC protocol, not a new protocol.
|
| I implemented the stdio transport, the JSON-RPC wire format
| & Tools support of the spec in Modex[^3].
|
| - [^1]:
| https://modelcontextprotocol.io/docs/concepts/transports
|
| - [^2]:
| https://modelcontextprotocol.io/specification/2025-03-26
|
| - [^3]: https://github.com/theronic/modex
| pgt wrote:
| Re: Auth, you are correct that MCP does not specify auth
| (aside from env vars for e.g. API keys which is host-
| specific - another gripe of mine).
|
| However, practically the host (e.g. Claude Desktop by
| Anthropic) asks for permission before calling specific MCP
| tools.
|
| It is not part of the MCP spec, but it's part of most host
| implementations of MCP and one of the big practical reasons
| for MCP's existence is to avoid giving models carte blanche
| HTTP access.
|
| IMO this should be part of the MCP spec, e.g. "you can call
| this GET /weather endpoint any time, but to make payments
| via this POST /transactions request, ask for permission
| once or always."
|
| Aside: just because someone "defines <X> as something" does
| not make it true.
| pgt wrote:
| And this why I call it EEE: if Anthropic had simply added
| HTTP API endpoints with auth, everyone would have copied
| it, and Anthropic would have no control over the spec,
| which can keep future contenders out.
|
| The MCP spec is a moat, and we've seen this movie before,
| whether they intended it to be or not. I use it, but I
| don't have to like it, i.e. MCP should not exist.
|
| As previously stated [^1], OpenAI can one-up them by
| simply supporting any API endpoint + auth and it would be
| way more powerful, no moat to defend against startups. No
| VC-funded corp can resist a moat.
|
| [^1]: 2025-03-06: https://x.com/petrustheron/status/18977
| 60788116652065?s=46
| RKFADU_UOFCCLEL wrote:
| I don't see the problem. I've just been using services with 3 -
| 10 verbs that the agent can use without adding any that can do
| harmful things. Even when they have no auth mechanism I can just
| put a temporary token in the URL.
| K7mR2vZq wrote:
| Great post. The lack of an option for decentralized content
| moderation is concerning. While MCP might help with extreme
| content, its opaque nature, potential for mission creep, and
| consolidation of power could lead to unintended consequences for
| smaller platforms and free expression online.
___________________________________________________________________
(page generated 2025-04-14 23:01 UTC)