Expose MCP freshness and provenance evidence for client trust decisions

[vvenegasv]

What problem does this solve?

MCP clients currently receive code intelligence results without enough machine-readable evidence to decide whether those results are fresh, stale, partial, directly resolved, or inferred. This makes it hard for clients to know when to trust a response, when to prompt for re-indexing, or when to verify an answer directly against source code.

This is especially important for responses such as index_status, trace_path, and trace_call_path, where clients need compatibility-safe metadata about index freshness, repository state, coverage, and relationship provenance without breaking existing consumers.

Proposed solution

Add backward-compatible, additive response fields that expose freshness and provenance evidence:

• Extend index_status with an evidence object containing index snapshot metadata, current Git HEAD comparison, tracked working-tree state, freshness status, coverage counters, and known limitations.
• Extend trace_path and trace_call_path with optional edge_evidence for traversed relationships, including resolution strategy, confidence, candidate count, and evidence status where available.
• Preserve existing response fields so current clients can ignore the new metadata safely.
• Document the added fields clearly for client compatibility.
• Add focused tests covering freshness/provenance behavior and safe handling of repository paths used in shell-backed Git checks.

Alternatives considered

No response

Confirmations

• I searched existing issues and this is not a duplicate.