7 ms·

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 "door

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 1y ago
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 1y ago
  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 1y ago
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 1y ago
> 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 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 1y ago
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-mostly-bullshit-a42e59a09b04 https://medium.com/thoughts-on-machine-learning/mcp-is-mostl...
- Eisenstein 1y ago
  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 1y ago
> 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 1y ago
  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 1y ago
  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 1y ago
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 1y ago
  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.
peterlada 1y ago
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 1y ago
> It's not the road's job to make you follow the speed limit. Good road design makes it impossible to speed.
- deleted 1y ago
  [deleted]
noodletheworld 1y ago
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 1y ago
  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 1y ago
    > 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?

Spivak 1y ago

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 1y ago
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 1y ago

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 1y ago

> 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 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 1y ago

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-mostly-bullshit-a42e59a09b04 https://medium.com/thoughts-on-machine-learning/mcp-is-mostl...

Eisenstein 1y ago
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 1y ago

> 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 1y ago
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 1y ago
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 1y ago

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 1y ago
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.

peterlada 1y ago

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 1y ago

> It's not the road's job to make you follow the speed limit. Good road design makes it impossible to speed.

deleted 1y ago
[deleted]

noodletheworld 1y ago

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 1y ago
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 1y ago
  > 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?