tengu_repl_mcp_error_throw Not enough to sayNothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.
This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.217: off
These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.
Read once, for one account on one subscription tier, against v2.1.217. It isn't a statement about your account. What a flag value here can and cannot tell you
What's wrong with this entry?
This is the most impactful behavioral change in this release for workflow authors.
Previously, MCP tool call failures inside workflow scripts silently resolved to {error: string} objects, making them indistinguishable from a successful tool call that returned an object with an error field. Now, MCP tool failures throw a proper McpToolError exception that crosses the VM sandbox boundary with structured fields.
The thrown error has:
.name === "McpToolError".toolName— the name of the MCP tool that failed.error— the error message string.detail— parsed JSON of the response body, if the error response was JSON
In scripts, use try/catch:
try {
const result = await mcp__server__tool({ ... })
} catch (e) {
if (e.name === "McpToolError") {
console.log(e.toolName, e.error, e.detail)
}
}The behavior is gated by tengu_repl_mcp_error_throw (default: true). The system prompt documentation for workflow scripts has been updated to reflect that MCP tools THROW on failure while built-in tools return {error: string}.
McpToolError class (search for "McpToolError") and VM sandbox bridge (search for "_throwMcpVM")
Strings lifted out of the shipped bundle, so the claim above can be checked against them.