LangChain invalid tool calls: what Sume returns on a bad call

A repaired tool call can still be wrong for Sume. When it is, Sume returns the failure as an MCP tool result with isError: true, not as a JSON-RPC error, so the agent can read the message and fix the next call. A paid retry should keep the same idempotency_key.

The LangChain 1.4.3 release (2026-09-28) lists the line "fix(langchain): repair invalid tool calls in create_agent (#40530)". The notes give no further detail, so this post covers only the Sume side, from MCP tools and gates and the MCP server code, read 2026-10-01.

What does the agent see when a tool name is wrong?

If the name misses the visible catalog but matches a registered tool spelled differently, the error text is Unknown remote MCP tool: <name>. Did you mean followed by the registered name, with the stable code tool_not_found. That hint is what a repair step can use. tools_list shows every tool visible in the session, and tools_schema fetches one contract by name.

Which Sume failures come back as tool results?

The server code returns tool execution failures as MCP tool results (isError: true) from the call path, and keeps JSON-RPC errors for protocol-level problems.

Should a repaired paid call get a new idempotency key?

No. idempotency_key is required on write and paid tools, and the docs call it a stable key for transport and dedup. If the first attempt may have reached Sume, a repaired retry should carry the same key so it is treated as the same request. Generate the key once per intended job in your agent state, not once per model output.

How do I keep the agent from guessing?

Put the tools_schema result in context before a paid call, and let the model use dry_run=true first when cost matters. Scope matters too: an OAuth session with only mcp:read sees read-only tools, while an API key sees the full hosted set. For approval patterns around paid tools, see LangChain MCP adapter approval for paid Sume tools.