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:
parent
54576033eb
commit
4b241e7ddc
1 changed files with 81 additions and 16 deletions
|
|
@ -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; }
|
||||
|
|
|
|||
Loading…
Reference in a new issue