{"version":"2.1.275","anchor":"tool-results-can-now-carry-a-remedy","canonical_anchor":"tool-results-can-now-carry-a-remedy","heading":"Tool results and denials can now carry a structured 'remedy'","tier":"internal","area":"Tool Results","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.275\/e\/tool-results-can-now-carry-a-remedy","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.275","markdown":"### Tool results and denials can now carry a structured 'remedy'\n\nFailed or denied tool calls now include a structured `remedy` code so hosts can offer a fix without parsing error text\n\n**Unclear.** What a 'remedy' represents or when it is populated is not stated.\n\n**What**\n\n- A new internal `remedy` field 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 include `mcp_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`, and `staged_for_review`.\n\n- This remedy is now threaded through as `toolResultRemedy` when building the tool-result message shown to Claude, and included in the transcript summary for denied or blocked tool calls alongside the existing `non_execution_kind`.\n\n- Errors produced after a failed tool call now include `toolResultRemedy` next to the existing `toolDenialKind`, both produced by new classifier functions that turn internal permission-deny and connection\/auth failures into these structured kinds.\n\n**Why**\n\nThis 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.\n\n- Area: Tool Results\n- Tier: Under the hood\n- Useful: 3\/5\n- Signal: 3\/5"}