Align error handling documentation with SEP-1303 (#967)

* Initial plan

* Update documentation to clarify error handling per SEP-1303

- Updated McpErrorCode.InvalidParams documentation to clarify it's for protocol-level errors (malformed requests, unknown primitives)
- Updated CallToolResult documentation to distinguish between tool execution errors and protocol errors
- Updated McpProtocolException documentation to emphasize it's only for protocol-level errors
- Added test to verify input validation errors are returned as tool execution errors (IsError=true)
- Implementation already correctly handles input validation as tool execution errors per SEP-1303

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
This commit is contained in:
Copilot 2025-11-17 10:01:30 -05:00 • committed by GitHub
commit 4b241e7ddc
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -8,13 +8,14 @@ namespace ModelContextProtocol.Protocol;
/// </summary>
/// <remarks>
/// <para>
/// Any errors that originate from the tool should be reported inside the result
/// object, with <see cref="IsError"/> set to true, rather than as a <see cref="JsonRpcError"/>.
/// Tool execution errors (including input validation errors, API failures, and business logic errors)
/// should be reported inside the result object with <see cref="IsError"/> set to <see langword="true"/>,
/// rather than as a <see cref="JsonRpcError"/>. This allows language models to see error details
/// and potentially self-correct in subsequent requests.
/// </para>
/// <para>
/// However, any errors in finding the tool, an error indicating that the
/// server does not support tool calls, or any other exceptional conditions,
/// should be reported as an MCP error response.
/// Protocol-level errors (such as unknown tool names, malformed requests that fail schema validation,
/// or server errors) should be reported as MCP protocol error responses using <see cref="McpErrorCode"/>.
/// </para>
/// <para>
/// See the <see href="https://github.com/modelcontextprotocol/specification/blob/main/schema/">schema</see> for details.
@ -38,10 +39,18 @@ public sealed class CallToolResult : Result
/// Gets or sets an indication of whether the tool call was unsuccessful.
/// </summary>
/// <remarks>
/// <para>
/// When set to <see langword="true"/>, it signifies that the tool execution failed.
/// Tool errors are reported with this property set to <see langword="true"/> and details in the <see cref="Content"/>
/// property, rather than as protocol-level errors. This allows LLMs to see that an error occurred
/// and potentially self-correct in subsequent requests.
/// Tool execution errors (including input validation errors, API failures, and business logic errors)
/// are reported with this property set to <see langword="true"/> and details in the <see cref="Content"/>
/// property, rather than as protocol-level errors.
/// </para>
/// <para>
/// This allows language models to receive detailed error feedback and potentially self-correct
/// in subsequent requests. For example, if a date parameter is in the wrong format or out of range,
/// the error message in <see cref="Content"/> can explain the issue, enabling the model to retry
/// with corrected parameters.
/// </para>
/// </remarks>
[JsonPropertyName("isError")]
public bool? IsError { get; set; }