Replies: 1 comment 1 reply
-
Just thinking out loud, could also this be solved without any changes by grouping them through MCP Server proxies? so you have a specific MCP Server (proxy) for each one of those categories |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Pre-submission Checklist
Your Idea
I use metadata heavily, for tools/prompts and resources. This works to manage the state in the client.
A custom MCP client requires distinction between the core entities. For example, a delete_tool has entirely different handlers than a 'web_search' tool.
As an example, I find myself heavily using the following metadata (and much more).
Hidden: boolean -> Don't expose in client
Ignore: boolean -> human use only,
Title: string -> UI interface,
Description: string -> UI interface,
this helps me handle the use of tools differently within the client, for example I don't give access to my LLMs to dangerous tools, but I do provide a UI for human use within the client. There is also a distinction between descriptions for people and descriptions for LLMs. (NEVER USE THIS TOOL IS VERY DANGEROUS!!!) is not a human friendly title :)
This seems to me to be the intended use of Metadata, and it works very well.
From a spec point of view, my life would be improved by having a discovery mechanism and getters on the client (that could easily be typed), as I imagine that this Metadata implementation will repeated (in an opinionated way) in nearly every MCP client that is implemented.
Possibly enhancement might be Client<--Server discovery of _metadata types... i.e. Server strictly defines metadata for each entity.
This helps implement type-safe and reliable clients.
Scope
Beta Was this translation helpful? Give feedback.
All reactions