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.
What does that have to do with MCP? Those sound like things you would build on a separate layer from MCP.
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.
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-26/ser...
[1] https://modelcontextprotocol.io/specification/2025-03-26/cli...
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
>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
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?
Static in what sense?
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...
> 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.
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?
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.
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
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.