Should MCP support authoritative tool results? #3181
Replies: 1 comment 1 reply
|
If an authoritative result passes through untouched, that part of the output wasn't model-generated. Since 2 August, Article 50 of the EU AI Act has made what is and isn't AI-generated a legal question, so a flag meaning "passed through unaltered" is useful well beyond the token saving. Worth designing against the inverse too: if a result is marked authoritative and the host reformats it anyway, the marking becomes a claim that doesn't hold. |
|
This is a really important point and honestly, I hadn't thought about the regulatory/provenance angle when I opened this discussion. I was initially looking at authoritative results mainly as a way to avoid unnecessary model calls and recomputation. But if the result is explicitly authoritative, then the question becomes much bigger: what guarantees that the host doesn't alter or reinterpret it? That makes provenance and integrity part of the protocol problem, not just an optimization. And with Article 50 of the EU AI Act now applying, I think this deserves more attention. I'm not suggesting that the Act directly requires MCP to implement this, but it does make the distinction between AI-generated content and content passed through from an authoritative source much more important. Your inverse case is particularly interesting: if a host modifies an authoritative result, it can no longer claim that the output is authoritative. I think this may actually strengthen the case for a SEP around authority, provenance and integrity of tool results, rather than just "authoritative results". Thanks for raising this, it definitely changed how I'm thinking about the proposal. |
Uh oh!
There was an error while loading. Please reload this page.
I'm working on an MCP runtime and noticed a recurring issue with deterministic tools.
Today, after a tool returns a result, the host typically feeds that result back into the language model so it can generate the final response. While this is the right behavior for many tools, it creates unnecessary overhead for deterministic operations where the tool's output is already the final, authoritative answer.
Examples include:
In these cases, the model often recomputes, reformats, or "validates" the returned value, even though the tool has already produced the correct result.
Example
User:
Tool returns:
{ "success": true, "result": "6085.2" }The model then frequently performs the entire calculation again before responding.
This has several consequences:
Current MCP Behavior
As far as I understand the current specification, MCP standardizes:
However, it intentionally does not define the semantic authority of a tool result.
A ToolResult is simply returned to the host, and the host is free to pass it back to the language model.
This means there is currently no standard way for a trusted MCP server to express:
Why prompts are not enough
A prompt can ask the model not to recompute a value, but this is not a protocol guarantee.
Different models behave differently, prompts evolve over time, and hosts may use completely different prompting strategies.
This feels like a protocol concern rather than a prompt engineering concern.
Possible direction
Rather than inventing implementation-specific conventions, should MCP eventually provide a standard mechanism for expressing that a tool result is authoritative?
I'm intentionally not proposing a concrete API yet.
The important question is whether the protocol should distinguish between:
This would only make sense when the host already trusts the MCP server.
Questions for the community
Have others observed unnecessary recomputation of deterministic tool results?
Is this considered a host responsibility, or is it something the protocol should eventually standardize?
Would there be value in exploring a future SEP around authoritative tool results, or is there already another direction being considered?
I'd love to hear how others are approaching this problem in production.
All reactions