Repository navigation
Scope of consequentialHint for high-risk read tools #331
Description
Activity
Intuitively, it feels like a separate hint here would be best instead of overloading
consequentialHint, but I'd like to hear from model harness implementers to be sure. @nmccormack-oai, does ChatGPT distinguish these two concepts at all, and would it benefit from this signal from developers?/cc @jpagnucco
I think I'd prefer a separate hint as well. I think the read only use case might be covered by consequential + readOnly but that seems a bit cumbersome.
I agree it would be helpful for @nmccormack-oai or other model harness or agent implementors to weigh in on whether this additional hint would be useful, or if there’s indications of explicit demand from web developers.
When we considered adding
consequentialHintafterreadOnlyHint, there were already strong recommendations from agent harnesses to usedestructiveHintandreadOnlyHintfor MCP tools, so adding it felt well motivated.My immediate intuition is that
sensitiveHintmay make more sense in the WebMCP context, where exposure to sensitive data seems much more likely. My preference would also be to keep it separate fromconsequentialHint.@victorhuangwq +1, I think separate hint, like
sensitiveHintwould be more useful than adding more to theconsequentialHint:- agent could show proper type of user-facing message asking for permission to run the tool - distinguish between "Agent will DO something consequential" from "Agent will READ something sensitive"
- after calling such tools agent harness could keep outputs of such tools from logs, long-term memory etc
sensitiveHintproposed wording:If true, indicates that the tool's output contains sensitive user data, such as credentials, financial or health records, government IDs, precise location, or private messages.
Yeah, a separate hint makes much more sense. It's definitely an interesting idea!
Adding a concrete developer use case in support of @Kulikowski's suggestion. I'm implementing WebMCP tools for a notes/tasks app, and separately working on a prototype in-page agent.
The app's
search_notesreturns note titles and short content previews;get_calendar_eventsreturns event titles and scheduling metadata. Both are annotatedreadOnlyHint: trueanduntrustedContentHint: true. Even these limited outputs can contain private information, and there's currently no annotation that says so. I would put a separate sensitivity hint on exactly these tools.In the prototype agent's default mode, a tool needs confirmation when
readOnlyHint !== true,consequentialHint === true, ordestructiveHint === true. With their current annotations, these two read tools run without that step. That's our prototype's policy, not a claim about how other harnesses readreadOnlyHint.As @jpagnucco noted,
readOnlyHint+consequentialHintcould cover the confirmation case, and our rule would already prompt for that combination. My reason for preferring a separate hint is that it expresses output sensitivity independently of mutation, so the confirmation UI can say "will read private data" rather than "will do something consequential," along the lines @Kulikowski described.This is one concrete data point on developer demand and intended harness use, not evidence of broader adoption.
The current WebMCP spec defines
consequentialHint(introduced in #217) as:This definition focuses on mutative operations (write actions) but leaves high-risk read-only operations ambiguous.
Many tools do not alter state but retrieve highly sensitive, restricted, or regulated user data. Letting an agent execute these silently without user confirmation introduces severe privacy and security risks.
readUserAddressreadBankAccountBalancereadApiKeyreadMedicalHistoryI'd be in favor of updating
consequentialHintto explicitly include high-risk data exposure with something like:OR we could also introduce a new hint (e.g.,
sensitiveDataHint) to keepconsequentialHintstrictly reserved for side-effect-producing mutations, and introduce a separate, parallel hint specifically for data access risks. This would allows agents to differentiate their consent UI (e.g., "This tool will execute an action" vs. "This tool will read sensitive information").@johannhof