[RFC] Purpose Assertions and Provenance-Aware Tool Semantics

[mmethodz]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Hi I am Mika, developer of DreamGraph,

This is an exploratory RFC/discussion proposal based on real-world multi-agent orchestration and graph-grounded tooling experience.

MCP currently standardizes tool capability exposure well, but it does not currently provide a standard way for tools to express:

• contextual authority,
• provenance-backed relevance,
• evidence scope/freshness,
• or confidence grounded in inspectable evidence.

As a result, planners often treat all tools as capability peers even when omission of certain context-authoritative tools materially increases architectural drift risk.

This proposal explores whether MCP could support optional purpose assertions and provenance-aware tool semantics while preserving full host/model autonomy.

The intent is NOT to force tool invocation.

The intent is to standardize a way for tools to expose evidence-backed relevance claims so planners can make more informed decisions.

Draft proposal attached below for discussion and feedback.
mcp_purpose_assertions_proposal_draft.md

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[armorer-labs]

I like the provenance-aware direction a lot because many agent failures are not really about whether a string is dangerous in the abstract; they are about where that string came from and what authority it should have.\n\nUser input, retrieved pages, issue comments, tool results, generated tool arguments, and system policy are all text, but they should not all carry the same semantic weight. Flattening them into one undifferentiated context window is where a lot of trouble starts.\n\nPurpose assertions and provenance labels feel useful when they do two things well:\n1. preserve the source / role of a piece of text across hops\n2. make it possible to enforce different downstream policy based on that source\n\nFor example: retrieved text may inform an answer, but should not silently become authority for a destructive tool call; tool results may be summarized, but not promoted into new goals without another check. If the RFC keeps that boundary-sensitive view, I think it could be very powerful.

[mmethodz]

Exactly — the core issue is that most current agent stacks flatten fundamentally different authority domains into one undifferentiated prompt stream.

A retrieved document, a user instruction, a tool result, a generated argument proposal, and a system policy may all be represented as text, but they are not semantically equivalent and should not inherit the same execution authority.

My concern is that once provenance is lost, downstream components can no longer distinguish:

• “context that may inform reasoning”
• from “context authorized to mutate goals or trigger side effects.”

The RFC is trying to make those boundaries explicit and machine-visible rather than implicit prompt-engineering conventions.

I think this becomes increasingly important as agents become more multi-hop and tool-compositional.

[mmethodz]

Even when graph-grounded retrieval is available, agent systems often regress toward flat-text recency heuristics unless tool authority and provenance are continuously reasserted. In practice this can produce weaker answers than the underlying retrieval substrate could support.