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