Sanitize 1.x documentation

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(

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);

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

docs/concepts/elicitation/elicitation.md

@@ -7,22 +7,22 @@ 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:
 
 - **Form (In-Band)**: The server requests structured data (strings, numbers, Booleans, enums) which the client collects via a form interface and returns to the server.
 - **URL Mode**: The server provides a URL for the user to visit (for example, for OAuth, payments, or sensitive data entry). The interaction happens outside the MCP client.
 
-### Server Support for Elicitation
+### Server support for elicitation
 
 Servers request information from users with the <xref:ModelContextProtocol.Server.McpServer.ElicitAsync*> extension method on <xref:ModelContextProtocol.Server.McpServer>.
 The C# SDK registers an instance of <xref:ModelContextProtocol.Server.McpServer> with the dependency injection container,
 so tools can simply add a parameter of type <xref:ModelContextProtocol.Server.McpServer> to their method signature to access it.
 
-#### Form Mode Elicitation (In-Band)
+#### 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.
 
@@ -115,7 +115,7 @@ The following example demonstrates how a server could request a Boolean response
 
 [!code-csharp[](samples/server/Tools/InteractiveTools.cs?name=snippet_GuessTheNumber)]
 
-#### URL Mode Elicitation (Out-of-Band)
+#### URL mode elicitation (out-of-band)
 
 For URL mode elicitation, the server provides a URL that the user must visit to complete an action. This is useful for scenarios like OAuth flows, payment processing, or collecting sensitive credentials that should not be exposed to the MCP client.
 
@@ -134,7 +134,7 @@ var result = await server.ElicitAsync(
     cancellationToken);
 ```
 
-### Client Support for Elicitation
+### Client support for elicitation
 
 Clients declare their support for elicitation in their capabilities as part of the `initialize` request. Clients can support `Form` (in-band), `Url` (out-of-band), or both.
 
@@ -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"`.
@@ -170,11 +170,11 @@ Here's an example implementation of how a console application might handle elici
 
 [!code-csharp[](samples/client/Program.cs?name=snippet_ElicitationHandler)]
 
-### URL Elicitation Required Error
+### 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
+#### Throwing UrlElicitationRequiredException on the server
 
 A server tool can throw `UrlElicitationRequiredException` when it detects that authorization or other out-of-band interaction is required:
 
@@ -212,14 +212,14 @@ public async Task<string> AccessThirdPartyResource(McpServer server, Cancellatio
 
 The exception can include multiple elicitations if the operation requires authorization from multiple services.
 
-#### Catching UrlElicitationRequiredException on the Client
+#### Catching UrlElicitationRequiredException on the client
 
 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
@@ -262,7 +262,7 @@ catch (UrlElicitationRequiredException ex)
 }
 ```
 
-#### Listening for Elicitation Completion Notifications
+#### Listening for elicitation completion notifications
 
 Servers can optionally send a `notifications/elicitation/complete` notification when the out-of-band interaction is complete. Clients can register a handler to receive these notifications:
 
@@ -284,6 +284,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.