3 ms·

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

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 2y 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 2y 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?
  - weird-eye-issue 2y ago
    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 2y ago
  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 2y ago
> 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 2y ago
  > 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-experiments https://github.com/invariantlabs-ai/mcp-injection-experiment... https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview#tool-use-system-prompt https://docs.anthropic.com/en/docs/build-with-claude/tool-us...
  - cruffle_duffle 2y ago
    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.
empath75 2y ago
"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 2y ago
  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 2y ago
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 2y ago
  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.

weird-eye-issue 2y 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 2y 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?
- weird-eye-issue 2y ago
  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 2y ago
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 2y ago

> 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 2y ago
> 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-experiments https://github.com/invariantlabs-ai/mcp-injection-experiment... https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview#tool-use-system-prompt https://docs.anthropic.com/en/docs/build-with-claude/tool-us...
- cruffle_duffle 2y ago
  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.

empath75 2y ago

"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 2y ago
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 2y ago

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