MCP tools with dependent types
vlaaad.github.io
MCP tools with dependent types
1–10 of 15 posts
Re: MCP tools with dependent types
#2I was considering making an MCP SEP (specification enhancement proposal) — https://modelcontextprotocol.io/community/sep-guidelines, though I'm curious if other MCP tinkerers feel the issue exists, should be solved like that, etc. What do you think?
Re: MCP tools with dependent types
#3> there is no way to tell the AI agent “for this argument, look up a JSON schema using this other tool”
There is a description field, it seems sufficient for most cases. You can also dynamically change your tools using `listChanged` capability.
Re: MCP tools with dependent types
#4> there is no way to tell the AI agent “for this argument, look up a JSON schema using this other tool” There is a description field, it seems sufficient for most cases. You can also dynamically change your tools using `listChanged` capability.
Sure, but the need for accuracy will only increase; there is a difference between suggesting an LLM to put a schema in its context before calling the tool vs forcing the LLM to use a structured output returned from a tool dynamically.
We already have 100% reliable structured outputs if we are making chatbots with LLM integrations directly; I don't want to lose this.
Re: MCP tools with dependent types
#5I don't think this is a protocol issue, the LLMs simply weren't RLHFed to do that
Re: MCP tools with dependent types
#6I don't think this is a protocol issue, the LLMs simply weren't RLHFed to do that
Not true, structured outputs enforce output formats with 100% reliability, e.g., https://platform.openai.com/docs/guides/structured-outputs says "Structured Outputs is a feature that ensures the model will always generate responses that adhere to your supplied JSON Schema, so you don't need to worry about the model omitting a required key, or hallucinating an invalid enum value"
Re: MCP tools with dependent types
#7> there is no way to tell the AI agent “for this argument, look up a JSON schema using this other tool” There is a description field, it seems sufficient for most cases. You can also dynamically change your tools using `listChanged` capability.
Sure, but the need for accuracy will only increase; there is a difference between suggesting an LLM to put a schema in its context before calling the tool vs forcing the LLM to use a structured output returned from a tool dynamically. We already have 100% reliable structured outputs if we are making chatbots with LLM integrations directly; I don't want to lose this.
And LLMs will get more accurate. What happens when the LLM uses the wrong parameters? If it's an immediate error then it will just try again, no need for protocol changes, just better LLMs.
Re: MCP tools with dependent types
#8This is already supported via listChanged. The problem is that >90% of clients currently don’t implement this - including Anthropic’s, https://modelcontextprotocol.io/clients
Re: MCP tools with dependent types
#9The Arazzo specification[0] (from OpenAPI contributors) aims to solve the dependent arguments issue by introducing the concept of a "runtime expressions"[1] within a series of independent tool calls which compose a workflow.
[0] - https://www.openapis.org/arazzo-specification [1] - https://spec.openapis.org/arazzo/v1.0.1.html#runtime-express...
Re: MCP tools with dependent types
#10Earlier quoted context omitted.
Sure, but the need for accuracy will only increase; there is a difference between suggesting an LLM to put a schema in its context before calling the tool vs forcing the LLM to use a structured output returned from a tool dynamically. We already have 100% reliable structured outputs if we are making chatbots with LLM integrations directly; I don't want to lose this.
And LLMs will get more accurate. What happens when the LLM uses the wrong parameters? If it's an immediate error then it will just try again, no need for protocol changes, just better LLMs.
The difference between 99% reliability and 100% reliability is huge in this case.