Group of 6 Under the hood
Failed or denied tool calls now include a structured remedy code so hosts can offer a fix without parsing error text
What
- A new internal
remedyfield can be attached to a tool result's metadata (tool_result_meta), giving a structured reason for a failure instead of free text. Its possible values includemcp_needs_auth,mcp_disabled,mcp_required_missing,auth_expired,auth_overridden,auth_missing_scope,design_needs_authorization,sandbox_violation,outside_reads_blocked,memory_paused,feature_disabled,policy_denied,spawn_arg_limit, andstaged_for_review. - This remedy is now threaded through as
toolResultRemedywhen building the tool-result message shown to Claude, and included in the transcript summary for denied or blocked tool calls alongside the existingnon_execution_kind. - Errors produced after a failed tool call now include
toolResultRemedynext to the existingtoolDenialKind, both produced by new classifier functions that turn internal permission-deny and connection/auth failures into these structured kinds.
Why
This lets tools and host applications programmatically detect why a call failed, for example missing MCP authorization versus a sandbox violation, and suggest the right fix instead of relying on parsing human-readable error text.
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt
The finding does not say what a remedy value looks like or where it is shown to the user.