You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proposal: Add source path and untrusted flag to read results #5151
Read tools currently return file contents as plain text, and structuredContent holds only that same text, so hosts get no provenance or untrusted field they can act on.
Solution you have in mind (optional)
Return the source path and an untrusted-content flag in structuredContent for every read tool (index.ts#L208-L211).
changed the title [-]Proposal: Add source path and untrusted flag to read results (SafetyCard review)[/-][+]Proposal: Add source path and untrusted flag to read results[/+]on Oct 14, 2026
Thank you for the suggestion, and apologies for the long wait for a response.
These servers are reference implementations: they exist to show how each part of MCP is used, not to be general-purpose products, so new features are taken selectively (CONTRIBUTING.md). An untrusted-content flag is not defined by the MCP specification, so adding an ad hoc provenance field to a reference server's results would not demonstrate a protocol feature. This is not a judgment on the idea or on you; a server in the MCP Registry may well offer it, and anyone is welcome to build on these servers to do so. This is happening as part of the backlog triage in #4875.
Activity
[-]Proposal: Add source path and untrusted flag to read results (SafetyCard review)[/-][+]Proposal: Add source path and untrusted flag to read results[/+]cliffhall commentedon Oct 19, 2026
Closing: out of scope for the reference servers.
Thank you for the suggestion, and apologies for the long wait for a response.
These servers are reference implementations: they exist to show how each part of MCP is used, not to be general-purpose products, so new features are taken selectively (
CONTRIBUTING.md). An untrusted-content flag is not defined by the MCP specification, so adding an ad hoc provenance field to a reference server's results would not demonstrate a protocol feature. This is not a judgment on the idea or on you; a server in the MCP Registry may well offer it, and anyone is welcome to build on these servers to do so. This is happening as part of the backlog triage in #4875.