modelcontextprotocol · jeffhandley · Jul 24, 2026 · Jul 23, 2026
diff --git a/docs/concepts/apps/apps.md b/docs/concepts/apps/apps.md
@@ -111,11 +111,11 @@ public static string GetWeather(McpServer server, string location)
 
 The `Visibility` property controls which principals can invoke the tool:
 
-| Value | Meaning |
-| - | - |
-| `McpUiToolVisibility.Model` | Only the LLM can call this tool |
-| `McpUiToolVisibility.App` | Only the app UI can call this tool |
-| Both (or null/empty) | Both the model and app can call the tool (default) |
+| Value                       | Meaning                                            |
+|-----------------------------|----------------------------------------------------|
+| `McpUiToolVisibility.Model` | Only the LLM can call this tool                    |
+| `McpUiToolVisibility.App`   | Only the app UI can call this tool                 |
+| Both (or null/empty)        | Both the model and app can call the tool (default) |
 
 ## UI resources
 
@@ -164,7 +164,7 @@ The MCP Apps spec defines display modes (`inline`, `fullscreen`, `pip`) that con
 
 ## Host theming
 
-Hosts pass standardized CSS custom properties (e.g., `--color-background-primary`, `--color-text-primary`) to app iframes. Your HTML can reference these variables to automatically match the host's theme without any server-side configuration.
+Hosts pass standardized CSS custom properties (for example, `--color-background-primary`, `--color-text-primary`) to app iframes. Your HTML can reference these variables to automatically match the host's theme without any server-side configuration.
 
 See the [MCP Apps specification](https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/draft/apps.mdx) for the full list of CSS variables.
 
@@ -176,10 +176,10 @@ The default Content Security Policy restricts external script and style loads. F
 
 The <xref:ModelContextProtocol.Extensions.Apps.McpApps> class provides constants for protocol values:
 
-| Constant | Value | Usage |
-| - | - | - |
-| `McpApps.HtmlMimeType` | `text/html;profile=mcp-app` | MIME type for UI resources |
-| `McpApps.ExtensionId` | `io.modelcontextprotocol/ui` | Key in `extensions` capability dictionary |
+| Constant               | Value                        | Usage                                     |
+|------------------------|------------------------------|-------------------------------------------|
+| `McpApps.HtmlMimeType` | `text/html;profile=mcp-app`  | MIME type for UI resources                |
+| `McpApps.ExtensionId`  | `io.modelcontextprotocol/ui` | Key in `extensions` capability dictionary |
 
 ## Serialization
 

diff --git a/docs/concepts/cancellation/cancellation.md b/docs/concepts/cancellation/cancellation.md
@@ -47,7 +47,7 @@ The cancellation notification includes:
 - **RequestId**: The ID of the request to cancel, allowing the receiver to correlate the cancellation with the correct in-flight request.
 - **Reason**: An optional human-readable reason for the cancellation.
 
-Cancellation notifications can be observed by registering a handler. For broader interception of notifications and other messages, <xref:ModelContextProtocol.Server.McpMessageFilter> delegates can be added to the <xref:ModelContextProtocol.Server.McpMessageFilters.IncomingFilters> collection in <xref:ModelContextProtocol.Server.McpServerOptions.Filters>.
+Cancellation notifications can be observed by registering a handler. For broader interception of notifications and other messages, you can add <xref:ModelContextProtocol.Server.McpMessageFilter> delegates to the <xref:ModelContextProtocol.Server.McpMessageFilters.IncomingFilters> collection in <xref:ModelContextProtocol.Server.McpServerOptions.Filters>.
 
 ```csharp
 mcpClient.RegisterNotificationHandler(

diff --git a/docs/concepts/capabilities/capabilities.md b/docs/concepts/capabilities/capabilities.md
@@ -42,7 +42,7 @@ var options = new McpClientOptions
 await using var client = await McpClient.CreateAsync(transport, options);
 ```
 
-Handlers for each capability (roots, sampling, elicitation) are covered in their respective documentation pages.
+Handlers for each capability (roots, sampling, and elicitation) are covered in their respective documentation pages.
 
 ### Server capabilities
 
@@ -63,7 +63,7 @@ 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);

diff --git a/docs/concepts/completions/completions.md b/docs/concepts/completions/completions.md
@@ -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, style options)
+- **Resource template argument completions**: Suggest values for URI template parameters (for example, file paths, 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.
 
@@ -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 `System.ComponentModel.DataAnnotations.AllowedValuesAttribute` on `string` parameters of prompts or resource templates. The server automatically surfaces those values as completions without needing a custom completion handler.
 
 #### Prompt parameters
 
@@ -115,11 +115,11 @@ public class MyResources
 }
 ```
 
-With these attributes in place, when a client sends a `completion/complete` request for the `language` or `section` argument, the server will automatically filter and return matching values based on what the user has typed so far. This approach can be combined with a custom completion handler registered via `WithCompleteHandler`; the handler's results are returned first, followed by any matching `AllowedValues`.
+With these attributes in place, when a client sends a `completion/complete` request for the `language` or `section` argument, the server automatically filters and returns matching values based on what the user has typed so far. This approach can be combined with a custom completion handler registered via `WithCompleteHandler`; the handler's results are returned first, followed by any matching `AllowedValues`.
 
 ### Requesting completions on the client
 
-Clients request completions using <xref:ModelContextProtocol.Client.McpClient.CompleteAsync*>. Provide a reference to the prompt or resource template, the argument name, and the current partial value:
+Clients request completions using <xref:ModelContextProtocol.Client.McpClient.CompleteAsync*>. Provide a reference to the prompt or resource template, the argument name, and the current partial value.
 
 #### Prompt argument completions
 
@@ -142,7 +142,7 @@ if (result.Completion.HasMore == true)
 }
 ```
 
-#### Resource template argument completions
+#### Resource-template argument completions
 
 ```csharp
 // Get completions for a resource template argument

diff --git a/docs/concepts/elicitation/elicitation.md b/docs/concepts/elicitation/elicitation.md
@@ -7,7 +7,7 @@ uid: elicitation
 
 ## Elicitation
 
-The **elicitation** feature allows servers to request additional information from users during interactions. This enables more dynamic and interactive AI experiences, making it easier to gather necessary context before executing tasks.
+The **elicitation** feature allows servers to request additional information from users during interactions. This feature enables more dynamic and interactive AI experiences, making it easier to gather necessary context before executing tasks.
 
 The protocol supports two modes of elicitation:
 
@@ -22,7 +22,7 @@ so tools can simply add a parameter of type <xref:ModelContextProtocol.Server.Mc
 
 #### Form Mode Elicitation (In-Band)
 
-For form-based elicitation, the MCP Server must specify the schema of each input value it is requesting from the user.
+For form-based elicitation, the MCP Server must specify the schema of each input value it's requesting from the user.
 Primitive types (string, number, Boolean) and enum types are supported for elicitation requests.
 The schema might include a description to help the user understand what's being requested.
 
@@ -158,7 +158,7 @@ var options = new McpClientOptions
 };
 ```
 
-The `ElicitationHandler` is an asynchronous method that will be called when the server requests additional information. The handler should check the `Mode` of the request:
+The `ElicitationHandler` is an asynchronous method that's called when the server requests additional information. The handler should check the `Mode` of the request:
 
 - **Form Mode**: Present the form defined by `RequestedSchema` to the user. Return the user's input in the `Content` of the result.
 - **URL Mode**: Present the `Message` and `Url` to the user. Ask for consent to open the URL. If the user consents, open the URL and return `Action="accept"`. If the user declines, return `Action="decline"`.
@@ -223,11 +223,11 @@ public static string ElicitWithMrtr(
 ```
 
 > [!TIP]
-> See [Multi Round-Trip Requests (MRTR)](xref:mrtr) for the full protocol details, including multiple round trips, concurrent input requests, and the compatibility matrix.
+> For the full protocol details, including multiple round trips, concurrent input requests, and the compatibility matrix, see [Multi Round-Trip Requests (MRTR)](xref:mrtr).
 
 ### URL Elicitation Required Error
 
-When a tool cannot proceed without first completing a URL-mode elicitation (for example, when third-party OAuth authorization is needed), and calling `ElicitAsync` is not practical (for example in [stateless](xref:stateless) mode where server-to-client requests are disabled), the server may throw a <xref:ModelContextProtocol.UrlElicitationRequiredException>. This is a specialized error (JSON-RPC error code `-32042`) that signals to the client that one or more URL-mode elicitations must be completed before the original request can be retried.
+When a tool cannot proceed without first completing a URL-mode elicitation (for example, when third-party OAuth authorization is needed), and calling `ElicitAsync` is not practical (for example, in [stateless](xref:stateless) mode where server-to-client requests are disabled), the server might throw a <xref:ModelContextProtocol.UrlElicitationRequiredException>. This is a specialized error (JSON-RPC error code `-32042`) that signals to the client that one or more URL-mode elicitations must be completed before the original request can be retried.
 
 #### Throwing UrlElicitationRequiredException on the Server
 
@@ -271,10 +271,10 @@ The exception can include multiple elicitations if the operation requires author
 
 When the client calls a tool and receives a `UrlElicitationRequiredException`, it should:
 
-1. Present each URL elicitation to the user (showing the URL and message)
-2. Get user consent before opening each URL
-3. Optionally wait for completion notifications from the server
-4. Retry the original request after the user completes the out-of-band interactions
+1. Present each URL elicitation to the user (showing the URL and message).
+2. Get user consent before opening each URL.
+3. Optionally wait for completion notifications from the server.
+4. Retry the original request after the user completes the out-of-band interactions.
 
 ```csharp
 try
@@ -339,6 +339,6 @@ await using var completionHandler = client.RegisterNotificationHandler(
 
 This pattern is particularly useful for:
 
-- **Third-party OAuth flows**: When the MCP server needs to obtain tokens from external services on behalf of the user
-- **Payment processing**: When user confirmation is required through a secure payment interface
-- **Sensitive credential collection**: When API keys or other secrets must be entered directly on a trusted server page rather than through the MCP client
+- **Third-party OAuth flows**: When the MCP server needs to obtain tokens from external services on behalf of the user.
+- **Payment processing**: When user confirmation is required through a secure payment interface.
+- **Sensitive credential collection**: When API keys or other secrets must be entered directly on a trusted server page rather than through the MCP client.
diff --git a/docs/concepts/filters.md b/docs/concepts/filters.md
@@ -10,25 +10,27 @@ uid: filters
 The MCP Server provides two levels of filters for intercepting and modifying request processing:
 
 1. **Message Filters** - Low-level filters (`AddIncomingFilter`, `AddOutgoingFilter`) configured via `WithMessageFilters(...)` that intercept all JSON-RPC messages before routing.
-2. **Request-Specific Filters** - Handler-level filters (e.g., `AddListToolsFilter`, `AddCallToolFilter`) configured via `WithRequestFilters(...)` that target specific MCP operations.
+2. **Request-Specific Filters** - Handler-level filters (for example, `AddListToolsFilter`, `AddCallToolFilter`) configured via `WithRequestFilters(...)` that target specific MCP operations.
 
 The filters are stored in `McpServerOptions.Filters`.
 
 ## Available Request-Specific Filter Methods
 
 The following request filter methods are available on `IMcpRequestFilterBuilder` inside `WithRequestFilters(...)`:
 
-- `AddListResourceTemplatesFilter` - Filter for list resource templates handlers
-- `AddListToolsFilter` - Filter for list tools handlers
-- `AddCallToolFilter` - Filter for call tool handlers
-- `AddListPromptsFilter` - Filter for list prompts handlers
-- `AddGetPromptFilter` - Filter for get prompt handlers
-- `AddListResourcesFilter` - Filter for list resources handlers
-- `AddReadResourceFilter` - Filter for read resource handlers
-- `AddCompleteFilter` - Filter for completion handlers
-- `AddSubscribeToResourcesFilter` - Filter for resource subscription handlers
-- `AddUnsubscribeFromResourcesFilter` - Filter for resource unsubscription handlers
-- `AddSetLoggingLevelFilter` - Filter for logging level handlers
+| Method                              | Filters for...                   |
+|-------------------------------------|----------------------------------|
+| `AddListResourceTemplatesFilter`    | List resource templates handlers |
+| `AddListToolsFilter`                | List tools handlers              |
+| `AddCallToolFilter`                 | Call tool handlers               |
+| `AddListPromptsFilter`              | List prompts handlers            |
+| `AddGetPromptFilter`                | Get prompt handlers              |
+| `AddListResourcesFilter`            | List resources handlers          |
+| `AddReadResourceFilter`             | Read resource handlers           |
+| `AddCompleteFilter`                 | Completion handlers              |
+| `AddSubscribeToResourcesFilter`     | Resource subscription handlers   |
+| `AddUnsubscribeFromResourcesFilter` | Resource unsubscription handlers |
+| `AddSetLoggingLevelFilter`          | Logging level handlers           |
 
 ## Message Filters
 
@@ -308,6 +310,8 @@ Execution flow: `filter1 -> filter2 -> filter3 -> baseHandler -> filter3 -> filt
 
 ## Common Use Cases
 
+Filters are commonly used for [logging](#logging), [error handling](#error-handling), [performance monitoring](#performance-monitoring), and [caching](#caching).
+
 ### Logging
 
 ```csharp
@@ -406,7 +410,7 @@ services.AddMcpServer()
     .WithTools<WeatherTools>();
 ```
 
-**Important**: You should always call `AddAuthorizationFilters()` when using ASP.NET Core integration if you want to use authorization attributes like `[Authorize]` on your MCP server tools, prompts, or resources.
+**Important**: If you want to use authorization attributes like `[Authorize]` on your MCP server tools, prompts, or resources, you should always call `AddAuthorizationFilters()` when using ASP.NET Core integration.
 
 ### Authorization Attributes Support