- pre_parse_json leaves a string alone when json.loads refuses it with
something other than JSONDecodeError (over-long integer, deep nesting),
so validation rejects it as a bad argument instead of it surfacing as a
crash with a traceback per request.
- convert_result skips output-schema validation for a returned
CallToolResult(is_error=True); an error result has no structured content
to check, and the author's message now reaches the client as written.
- read_resource checks that Resource.read() returned str or bytes, so a
mistyped custom resource is logged as a crash and answered with -32603
rather than "Invalid request parameters" with no log record.
- Docs and examples that still said "raise any exception and the model
reads it" now say ToolError; deprecated.md lists the deprecated
FuncMetadata helper; docstrings spell out the MCPError carve-out and the
nested-crash __cause__.
- Two tests tightened: the prompt argument-validation test proves the body
never ran, and the invalid-types check asserts on validate_arguments.
- Log rejected tool arguments with %r: pydantic's error locations can
include caller-supplied dict keys, which must not break onto new log
lines.
- Build CompleteResult inside the completion adapter's try, so a handler
returning the wrong type is logged as a crash and answered with the
generic -32603 rather than "Invalid request parameters".
- On the legacy resolver path, a malformed ElicitResult from a
non-conformant client no longer has its pydantic text repeated back.
- Add FuncMetadata.call_fn() for calling with already-validated
arguments and use it from Tool.run; call_fn_with_arg_validation()
becomes a deprecated wrapper (MCPDeprecationWarning, removal in 3.0).
- Docstring and docs wording: MCPError carve-outs, nested crash message,
ResourceError in the imports and resource paragraph, the exact
MCPDeprecationWarning path a traceback prints.
A tool that crashed used to send the exception's own text to the client
as "Error executing tool <name>: <str(exc)>". That text can describe
server internals (or, for an output-schema failure, echo the tool's
return value), so a crash now reads just "Error executing tool <name>".
ToolError, ResourceError, and argument-validation messages still reach
the model unchanged, since those are the anticipated failures it can act
on. Closes the tool half of the leak that resources already avoided and
that prompts stopped doing earlier in this branch.
Related tidy-ups in the same direction:
- a crashing @mcp.completion() handler is logged once and answered with
-32603 "Error completing argument <name>" instead of str(exc)
- the legacy resolver path reports a malformed elicitation answer as a
ToolError, matching what the input_required path already did
- the INFO line for rejected arguments names the fields, not the values
Docs now teach ToolError as the way to talk to the model and describe a
plain exception as a crash the model sees generically; examples that
relied on ValueError text reaching the client raise ToolError instead.
Max Isbey