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
What a 'remedy' represents or when it is populated is not stated.