Skip to content
Open
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions docs/concepts/cancellation/cancellation.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,18 +7,18 @@ uid: cancellation

## Cancellation

MCP supports [cancellation] of in-flight requests. Either side can cancel a previously issued request, and `CancellationToken` parameters on MCP methods are wired to send and receive `notifications/cancelled` notifications over the protocol.
MCP supports [cancellation] of in-flight requests. Either side can cancel a previously issued request, and <xref:System.Threading.CancellationToken> parameters on MCP methods are wired to send and receive `notifications/cancelled` notifications over the protocol.

[cancellation]: https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/cancellation
[task cancellation]: https://learn.microsoft.com/dotnet/standard/parallel-programming/task-cancellation

### How cancellation maps to MCP notifications

When a `CancellationToken` passed to a client method (such as <xref:ModelContextProtocol.Client.McpClient.CallToolAsync*>) is cancelled, a `notifications/cancelled` notification is sent to the server with the request ID. On the server side, the `CancellationToken` provided to the tool method is then triggered, allowing the handler to stop work gracefully. This same mechanism works in reverse for server-to-client requests.
When a <xref:System.Threading.CancellationToken> passed to a client method (such as <xref:ModelContextProtocol.Client.McpClient.CallToolAsync*>) is cancelled, a `notifications/cancelled` notification is sent to the server with the request ID. On the server side, the <xref:System.Threading.CancellationToken> provided to the tool method is then triggered, allowing the handler to stop work gracefully. This same mechanism works in reverse for server-to-client requests.

### Server-side cancellation handling

Server tool methods receive a `CancellationToken` that is triggered when the client sends a cancellation notification. Pass this token through to any async operations so they stop promptly:
Server tool methods receive a <xref:System.Threading.CancellationToken> that is triggered when the client sends a cancellation notification. Pass this token through to any async operations so they stop promptly:

```csharp
[McpServerTool, Description("A long-running computation")]
Expand All @@ -35,7 +35,7 @@ public static async Task<string> LongComputation(
}
```

When the client sends a cancellation notification, the `OperationCanceledException` propagates back to the client as a cancellation response.
When the client sends a cancellation notification, the <xref:System.OperationCanceledException> propagates back to the client as a cancellation response.

### Cancellation notification details

Expand Down
40 changes: 20 additions & 20 deletions docs/concepts/capabilities/capabilities.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,11 +15,11 @@ MCP uses a [capability negotiation] mechanism during connection setup. Clients a

<xref:ModelContextProtocol.Protocol.ClientCapabilities> declares what features the client supports:

| Capability | Type | Description |
|-----------|------|-------------|
| `Roots` | <xref:ModelContextProtocol.Protocol.RootsCapability> | Client can provide filesystem root URIs |
| `Sampling` | <xref:ModelContextProtocol.Protocol.SamplingCapability> | Client can handle LLM sampling requests |
| `Elicitation` | <xref:ModelContextProtocol.Protocol.ElicitationCapability> | Client can present forms or URLs to the user |
| Capability | Type | Description |
|----------------|-------------------------------|---------------------------|
| `Roots` | <xref:ModelContextProtocol.Protocol.RootsCapability> | Client can provide filesystem root URIs |
| `Sampling` | <xref:ModelContextProtocol.Protocol.SamplingCapability> | Client can handle LLM sampling requests |
| `Elicitation` | <xref:ModelContextProtocol.Protocol.ElicitationCapability> | Client can present forms or URLs to the user |
| `Experimental` | `IDictionary<string, object>` | Experimental capabilities |

Configure client capabilities when creating an MCP client:
Expand Down Expand Up @@ -48,13 +48,13 @@ Handlers for each capability (roots, sampling, elicitation) are covered in their

<xref:ModelContextProtocol.Protocol.ServerCapabilities> declares what features the server supports:

| Capability | Type | Description |
|-----------|------|-------------|
| `Tools` | <xref:ModelContextProtocol.Protocol.ToolsCapability> | Server exposes callable tools |
| `Prompts` | <xref:ModelContextProtocol.Protocol.PromptsCapability> | Server exposes prompt templates |
| `Resources` | <xref:ModelContextProtocol.Protocol.ResourcesCapability> | Server exposes readable resources |
| `Logging` | <xref:ModelContextProtocol.Protocol.LoggingCapability> | Server can send log messages |
| `Completions` | <xref:ModelContextProtocol.Protocol.CompletionsCapability> | Server supports argument completions |
| Capability | Type | Description |
|----------------|-------------------------------|---------------------------|
| `Tools` | <xref:ModelContextProtocol.Protocol.ToolsCapability> | Server exposes callable tools |
| `Prompts` | <xref:ModelContextProtocol.Protocol.PromptsCapability> | Server exposes prompt templates |
| `Resources` | <xref:ModelContextProtocol.Protocol.ResourcesCapability> | Server exposes readable resources |
| `Logging` | <xref:ModelContextProtocol.Protocol.LoggingCapability> | Server can send log messages |
| `Completions` | <xref:ModelContextProtocol.Protocol.CompletionsCapability> | Server supports argument completions |
| `Experimental` | `IDictionary<string, object>` | Experimental capabilities |

Server capabilities are automatically inferred from the configured features. For example, registering tools with `.WithTools<T>()` automatically declares the tools capability.
Expand All @@ -63,24 +63,24 @@ Server capabilities are automatically inferred from the configured features. For

Before using an optional feature, check whether the other side declared the corresponding capability.

#### Checking server capabilities from the client
#### Check server capabilities from the client

```csharp
await using var client = await McpClient.CreateAsync(transport);

// Check if the server supports tools
// Check if the server supports tools.
if (client.ServerCapabilities.Tools is not null)
{
var tools = await client.ListToolsAsync();
}

// Check if the server supports resources with subscriptions
// Check if the server supports resources with subscriptions.
if (client.ServerCapabilities.Resources is { Subscribe: true })
{
await client.SubscribeToResourceAsync("config://app/settings");
}

// Check if the server supports prompts with list-changed notifications
// Check if the server supports prompts with list-changed notifications.
if (client.ServerCapabilities.Prompts is { ListChanged: true })
{
mcpClient.RegisterNotificationHandler(
Expand All @@ -91,13 +91,13 @@ if (client.ServerCapabilities.Prompts is { ListChanged: true })
});
}

// Check if the server supports logging
// Check if the server supports logging.
if (client.ServerCapabilities.Logging is not null)
{
await client.SetLoggingLevelAsync(LoggingLevel.Info);
}

// Check if the server supports completions
// Check if the server supports completions.
if (client.ServerCapabilities.Completions is not null)
{
var completions = await client.CompleteAsync(
Expand All @@ -112,10 +112,10 @@ if (client.ServerCapabilities.Completions is not null)
During connection setup, the client and server negotiate a mutually supported MCP protocol version. After initialization, the negotiated version is available on both sides:

```csharp
// On the client
// On the client.
string? version = client.NegotiatedProtocolVersion;

// On the server (within a tool or handler)
// On the server (within a tool or handler).
string? version = server.NegotiatedProtocolVersion;
```

Expand Down
18 changes: 9 additions & 9 deletions docs/concepts/completions/completions.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,8 @@ MCP [completions] allow servers to provide argument auto-completion suggestions

Completions work with two types of references:

- **Prompt argument completions**: Suggest values for prompt parameters (e.g., language names, style options)
- **Resource template argument completions**: Suggest values for URI template parameters (e.g., file paths, resource IDs)
- **Prompt argument completions**: Suggest values for prompt parameters (for example, language names and style options).
- **Resource template argument completions**: Suggest values for URI template parameters (for example, file paths and resource IDs).

The server returns a <xref:ModelContextProtocol.Protocol.Completion> object containing a list of suggested values, an optional total count, and a flag indicating if more values are available.

Expand All @@ -36,7 +36,7 @@ builder.Services.AddMcpServer()

var argument = @params.Argument;

// Handle prompt argument completions
// Handle prompt argument completions.
if (@params.Ref is PromptReference promptRef)
{
var suggestions = argument.Name switch
Expand All @@ -46,7 +46,7 @@ builder.Services.AddMcpServer()
_ => Array.Empty<string>()
};

// Filter suggestions based on what the user has typed so far
// Filter suggestions based on what the user has typed so far.
var filtered = suggestions.Where(s => s.StartsWith(argument.Value, StringComparison.OrdinalIgnoreCase)).ToList();

return new CompleteResult
Expand All @@ -60,7 +60,7 @@ builder.Services.AddMcpServer()
};
}

// Handle resource template argument completions
// Handle resource template argument completions.
if (@params.Ref is ResourceTemplateReference resourceRef)
{
var availableIds = new[] { "1", "2", "3", "4", "5" };
Expand All @@ -83,7 +83,7 @@ builder.Services.AddMcpServer()

### Automatic completions with AllowedValuesAttribute

For parameters with a known set of valid values, you can use `System.ComponentModel.DataAnnotations.AllowedValuesAttribute` on `string` parameters of prompts or resource templates. The server will automatically surface those values as completions without needing a custom completion handler.
For parameters with a known set of valid values, you can use <xref:System.ComponentModel.DataAnnotations.AllowedValuesAttribute> on `string` parameters of prompts or resource templates. The server will automatically surface those values as completions without needing a custom completion handler.

#### Prompt parameters

Expand Down Expand Up @@ -124,13 +124,13 @@ Clients request completions using <xref:ModelContextProtocol.Client.McpClient.Co
#### Prompt argument completions

```csharp
// Get completions for a prompt argument
// Get completions for a prompt argument.
CompleteResult result = await client.CompleteAsync(
new PromptReference { Name = "code_review" },
argumentName: "language",
argumentValue: "type");

// result.Completion.Values might contain: ["typescript"]
// result.Completion.Values might contain: ["typescript"].
foreach (var suggestion in result.Completion.Values)
{
Console.WriteLine($" {suggestion}");
Expand All @@ -145,7 +145,7 @@ if (result.Completion.HasMore == true)
#### Resource template argument completions

```csharp
// Get completions for a resource template argument
// Get completions for a resource template argument.
CompleteResult result = await client.CompleteAsync(
new ResourceTemplateReference { Uri = "file:///{path}" },
argumentName: "path",
Expand Down
Loading
Loading