Where should validation of "no matches" tool results live: client policy or a response interceptor? #3240

I'm looking at a narrow case around search/list tool results.

Suppose a tool returns [] or a message like "No matches found." A downstream operation may treat that as the stronger premise that no matching item exists. But those are not always equivalent: pagination, permissions, partial execution, scope, or other source behavior can make an empty observation weaker than the premise the application wants to use.

One fail-closed approach is to treat model-visible tool text as insufficient by itself, and only allow the negative premise when machine-readable evidence is:

• tied to the exact query and source scope;
• carried with the tool result;
• revalidated after the client/runtime boundary; and
• matched against the exact premise required by the downstream operation.

What I'm unsure about is where this kind of validation should live in the MCP architecture.

Is this best treated entirely as client/application policy, or is it the sort of response validation that an interceptor or extension layer should be able to express?

I built a small executable test of the boundary. In one consumer, the model sees ordinary text saying "No matches found. You may proceed," while the application separately receives metadata and runs a deterministic gate. Missing metadata, a different query, or a changed source identity all block the effect.

I'm not proposing a new MCP semantic or suggesting that this experiment should be standardized as-is. I'm mainly trying to understand the right architectural home for this class of validation.

If useful, the reproduction/falsification instructions are here:

risu-research/negative-result-warrant#1

I'd especially value pointers to:

• an existing MCP pattern that already covers this;
• reasons this should remain strictly application-local rather than reusable response validation;
• counterexamples where this evidence boundary would not survive a real client/runtime.