Add validation and error signaling guidance to MCP tool XML docs (#1275)
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
841e810167
commit
ec4c732632
2 changed files with 61 additions and 1 deletions
|
|
@ -90,6 +90,26 @@ namespace ModelContextProtocol.Server;
|
|||
/// to provide data to the method.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// The tool method is responsible for validating its own input arguments (e.g., checking required fields, value ranges, string lengths, or
|
||||
/// any other business rules). Data annotations such as <c>RequiredAttribute</c> and
|
||||
/// <c>MaxLengthAttribute</c> on parameter types influence the generated JSON schema exposed
|
||||
/// to clients, but they are not enforced at runtime by the SDK. Validation should be performed explicitly within the tool method.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// To signal an error (including validation failures) back to the client, either throw an <see cref="McpException"/>
|
||||
/// or return a <see cref="CallToolResult"/> with <see cref="CallToolResult.IsError"/> set to <see langword="true"/>.
|
||||
/// When a tool throws an <see cref="McpException"/>, its <see cref="Exception.Message"/> is included in the error result
|
||||
/// sent to the client. Throwing any other exception type also results in an error <see cref="CallToolResult"/>, but with
|
||||
/// a generic error message (to avoid leaking sensitive information). Alternatively, a tool can declare a return type of
|
||||
/// <see cref="CallToolResult"/> to have full control over both success and error responses.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// It is important to provide clear <see cref="System.ComponentModel.DescriptionAttribute"/> values on tool methods and their parameters.
|
||||
/// These descriptions are surfaced to AI models and help them determine when and how to use the tool, what values to pass for each parameter,
|
||||
/// and what constraints the parameters have. Well-written descriptions reduce incorrect tool invocations and improve the quality of
|
||||
/// model interactions.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// Return values from a method are used to create the <see cref="CallToolResult"/> that is sent back to the client:
|
||||
/// </para>
|
||||
/// <list type="table">
|
||||
|
|
|
|||
|
|
@ -82,6 +82,26 @@ namespace ModelContextProtocol.Server;
|
|||
/// to provide data to the method.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// The tool method is responsible for validating its own input arguments (e.g., checking required fields, value ranges, string lengths, or
|
||||
/// any other business rules). Data annotations such as <c>RequiredAttribute</c> and
|
||||
/// <c>MaxLengthAttribute</c> on parameter types influence the generated JSON schema exposed
|
||||
/// to clients, but they are not enforced at runtime by the SDK. Validation should be performed explicitly within the tool method.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// To signal an error (including validation failures) back to the client, either throw an <see cref="McpException"/>
|
||||
/// or return a <see cref="CallToolResult"/> with <see cref="CallToolResult.IsError"/> set to <see langword="true"/>.
|
||||
/// When a tool throws an <see cref="McpException"/>, its <see cref="Exception.Message"/> is included in the error result
|
||||
/// sent to the client. Throwing any other exception type also results in an error <see cref="CallToolResult"/>, but with
|
||||
/// a generic error message (to avoid leaking sensitive information). Alternatively, a tool can declare a return type of
|
||||
/// <see cref="CallToolResult"/> to have full control over both success and error responses.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// It is important to provide clear <see cref="System.ComponentModel.DescriptionAttribute"/> values on tool methods and their parameters.
|
||||
/// These descriptions are surfaced to AI models and help them determine when and how to use the tool, what values to pass for each parameter,
|
||||
/// and what constraints the parameters have. Well-written descriptions reduce incorrect tool invocations and improve the quality of
|
||||
/// model interactions.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// Return values from a method are used to create the <see cref="CallToolResult"/> that is sent back to the client:
|
||||
/// </para>
|
||||
/// <list type="table">
|
||||
|
|
|
|||
Loading…
Reference in a new issue