remove invalid xrefs

Author: gewarren

docs/concepts/cancellation/cancellation.md

@@ -35,7 +35,7 @@ public static async Task<string> LongComputation(
 }
 ```
 
-When the client sends a cancellation notification, the <xref:System.OperationCanceledException> propagates back to the client as a cancellation response.
+When the client sends a cancellation notification, the `OperationCanceledException` propagates back to the client as a cancellation response.
 
 ### Cancellation notification details
 

docs/concepts/completions/completions.md

@@ -83,7 +83,7 @@ builder.Services.AddMcpServer()
 
 ### Automatic completions with AllowedValuesAttribute
 
-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.
+For parameters with a known set of valid values, you can use `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
 

docs/concepts/httpcontext/httpcontext.md

@@ -10,18 +10,18 @@ uid: httpcontext
 When using the Streamable HTTP transport, an MCP server might need to access the underlying <xref:Microsoft.AspNetCore.Http.HttpContext> for a request.
 The <xref:Microsoft.AspNetCore.Http.HttpContext> object contains request metadata such as the HTTP headers, authorization context, and the actual path and query string for the request.
 
-To access the <xref:Microsoft.AspNetCore.Http.HttpContext>, the MCP server should add the <xref:Microsoft.AspNetCore.Http.IHttpContextAccessor> service to the application service collection (typically in Program.cs).
-Then any classes, for example, a class containing MCP tools, should accept an <xref:Microsoft.AspNetCore.Http.IHttpContextAccessor> in their constructor and store this for use by its methods.
-Methods then use the <xref:Microsoft.AspNetCore.Http.IHttpContextAccessor.HttpContext> property of the accessor to get the current context.
+To access the <xref:Microsoft.AspNetCore.Http.HttpContext>, the MCP server should add the `IHttpContextAccessor` service to the application service collection (typically in Program.cs).
+Then any classes, for example, a class containing MCP tools, should accept an `IHttpContextAccessor` in their constructor and store this for use by its methods.
+Methods then use the `HttpContext` property of the accessor to get the current context.
 
-The following code snippet illustrates how to add the <xref:Microsoft.AspNetCore.Http.IHttpContextAccessor> service to the application service collection:
+The following code snippet illustrates how to add the `IHttpContextAccessor` service to the application service collection:
 
 [!code-csharp[](samples/Program.cs?name=snippet_AddHttpContextAccessor)]
 
-Any class that needs access to the <xref:Microsoft.AspNetCore.Http.HttpContext> can accept an <xref:Microsoft.AspNetCore.Http.IHttpContextAccessor> in its constructor and store it for later use.
+Any class that needs access to the <xref:Microsoft.AspNetCore.Http.HttpContext> can accept an `IHttpContextAccessor` in its constructor and store it for later use.
 Methods of the class can then access the current <xref:Microsoft.AspNetCore.Http.HttpContext> using the stored accessor.
 
-The following code snippet shows the `ContextTools` class accepting an <xref:Microsoft.AspNetCore.Http.IHttpContextAccessor> in its primary constructor
+The following code snippet shows the `ContextTools` class accepting an `IHttpContextAccessor` in its primary constructor
 and the `GetHttpHeaders` method accessing the current <xref:Microsoft.AspNetCore.Http.HttpContext> to retrieve the HTTP headers from the current request.
 
 [!code-csharp[](samples/Tools/ContextTools.cs?name=snippet_AccessHttpContext)]

docs/concepts/progress/progress.md

@@ -50,9 +50,9 @@ await using var handler = mcpClient.RegisterNotificationHandler(NotificationMeth
     });
 ```
 
-The second way is to pass a [`Progress<T>`](https://learn.microsoft.com/dotnet/api/system.progress-1) instance to the tool method. <xref:System.Progress%601> is a standard .NET type that provides a way to receive progress updates.
+The second way is to pass a [`Progress<T>`](https://learn.microsoft.com/dotnet/api/system.progress-1) instance to the tool method. `Progress\<T>` is a standard .NET type that provides a way to receive progress updates.
 For the purposes of MCP progress notifications, `T` should be <xref:ModelContextProtocol.ProgressNotificationValue>.
-The MCP C# SDK will automatically handle progress notifications and report them through the <xref:System.Progress%601> instance.
+The MCP C# SDK will automatically handle progress notifications and report them through the `Progress\<T>` instance.
 This notification handler will only receive progress updates for the specific request that was made,
 rather than all progress notifications from the server.
 

docs/concepts/tools/tools.md

@@ -208,7 +208,7 @@ Tool errors in MCP are distinct from protocol errors. When a tool encounters an
 When a tool method throws an exception, the server catches it and returns a <xref:ModelContextProtocol.Protocol.CallToolResult> with `IsError = true`, with the following exceptions:
 
 - <xref:ModelContextProtocol.McpProtocolException> is rethrown as a JSON-RPC error response (not a tool error result).
-- <xref:System.OperationCanceledException> is rethrown when the cancellation token was triggered.
+- `OperationCanceledException` is rethrown when the cancellation token was triggered.
 
 For all other exceptions, the error is returned as a tool result. If the exception derives from <xref:ModelContextProtocol.McpException> (excluding <xref:ModelContextProtocol.McpProtocolException>, which is rethrown above), its message is included in the error text; otherwise, a generic message is returned to avoid leaking internal details.
 

docs/experimental.md

@@ -39,14 +39,14 @@ Experimental properties on protocol types are fully serialized and deserialized
 
 The behavior of experimental properties differs depending on whether you use [reflection-based or source-generated](https://learn.microsoft.com/dotnet/standard/serialization/system-text-json/source-generation) serialization:
 
-- **Reflection-based serialization** (the default when no <xref:System.Text.Json.Serialization.JsonSerializerContext> is used): Experimental properties are included. No special configuration is needed.
-- **Source-generated serialization** (using a custom <xref:System.Text.Json.Serialization.JsonSerializerContext>): Experimental properties are **not** included in your context's serialization contract. This is by design, as it protects your compiled code against binary breaking changes to experimental APIs.
+- **Reflection-based serialization** (the default when no `JsonSerializerContext` is used): Experimental properties are included. No special configuration is needed.
+- **Source-generated serialization** (using a custom `JsonSerializerContext`): Experimental properties are **not** included in your context's serialization contract. This is by design, as it protects your compiled code against binary breaking changes to experimental APIs.
 
 This means that switching between reflection-based and source-generated serialization can silently change which properties are serialized. To avoid this, source-generation users should configure a `TypeInfoResolverChain` as described below.
 
-### Custom `JsonSerializerContext`
+### Custom JsonSerializerContext
 
-If you define your own <xref:System.Text.Json.Serialization.JsonSerializerContext> that includes MCP protocol types, configure a `TypeInfoResolverChain` so the SDK's resolver handles MCP types:
+If you define your own `JsonSerializerContext` that includes MCP protocol types, configure a `TypeInfoResolverChain` so the SDK's resolver handles MCP types:
 
 ```csharp
 using ModelContextProtocol;