Fix a few bugs in the docs

docs/concepts/filters.md

@@ -317,7 +317,7 @@ Execution flow: `filter1 -> filter2 -> filter3 -> baseHandler -> filter3 -> filt
     {
         var logger = context.Services?.GetService<ILogger<Program>>();
 
-        logger?.LogInformation($"Processing request from {context.Meta.ProgressToken}");
+        logger?.LogInformation($"Processing request from {context.Params?.ProgressToken}");
         var result = await next(context, cancellationToken);
         logger?.LogInformation($"Returning {result.Tools?.Count ?? 0} tools");
         return result;
@@ -339,11 +339,11 @@ Execution flow: `filter1 -> filter2 -> filter3 -> baseHandler -> filter3 -> filt
         catch (Exception ex)
         {
             var logger = context.Services?.GetService<ILogger<Program>>();
-            logger?.LogError(ex, "Error while processing CallTool request for {ProgressToken}", context.Meta.ProgressToken);
+            logger?.LogError(ex, "Error while processing CallTool request for {ProgressToken}", context.Params?.ProgressToken);
 
             return new CallToolResult
             {
-                Content = new[] { new TextContent { Type = "text", Text = "An unexpected error occurred while processing the tool call." } },
+                Content = [new TextContentBlock { Text = "An unexpected error occurred while processing the tool call." }],
                 IsError = true
             };
         }
@@ -576,7 +576,7 @@ You can also create custom authorization filters using the filter methods:
         {
             return new CallToolResult
             {
-                Content = [new TextContent { Text = "Custom: Authentication required" }],
+                Content = [new TextContentBlock { Text = "Custom: Authentication required" }],
                 IsError = true
             };
         }

docs/concepts/logging/logging.md

@@ -54,7 +54,7 @@ server to perform any special logic it wants to perform when a client sets the l
 SDK already takes care of setting the <xref:ModelContextProtocol.Server.McpServer.LoggingLevel> in the <xref:ModelContextProtocol.Server.McpServer>, so most servers will not need to
 implement this.
 
-MCP Servers using the MCP C# SDK can obtain an [ILoggerProvider](https://learn.microsoft.com/dotnet/api/microsoft.extensions.logging.iloggerprovider) from the IMcpServer <xref:ModelContextProtocol.Server.McpServer.AsClientLoggerProvider> extension method,
+MCP Servers using the MCP C# SDK can obtain an [ILoggerProvider](https://learn.microsoft.com/dotnet/api/microsoft.extensions.logging.iloggerprovider) from the <xref:ModelContextProtocol.Server.McpServer.AsClientLoggerProvider> method on <xref:ModelContextProtocol.Server.McpServer>,
 and from that can create an [ILogger](https://learn.microsoft.com/dotnet/api/microsoft.extensions.logging.ilogger) instance for logging messages that should be sent to the MCP client.
 
 [!code-csharp[](samples/server/Tools/LoggingTools.cs?name=snippet_LoggingConfiguration)]

docs/concepts/progress/progress.md

@@ -37,7 +37,7 @@ The client should also provide a notification handler to process "notifications/
 There are two ways to do this. The first is to register a notification handler using the <xref:ModelContextProtocol.McpSession.RegisterNotificationHandler*> method on the <xref:ModelContextProtocol.Client.McpClient> instance. A handler registered this way will receive all progress notifications sent by the server.
 
 ```csharp
-mcpClient.RegisterNotificationHandler(NotificationMethods.ProgressNotification,
+await using var handler = mcpClient.RegisterNotificationHandler(NotificationMethods.ProgressNotification,
     (notification, cancellationToken) =>
     {
         if (JsonSerializer.Deserialize<ProgressNotificationParams>(notification.Params) is { } pn &&
@@ -47,7 +47,7 @@ mcpClient.RegisterNotificationHandler(NotificationMethods.ProgressNotification,
             Console.WriteLine($"Tool progress: {pn.Progress.Progress} of {pn.Progress.Total} - {pn.Progress.Message}");
         }
         return ValueTask.CompletedTask;
-    }).ConfigureAwait(false);
+    });
 ```
 
 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.

docs/concepts/tasks/tasks.md

@@ -75,11 +75,13 @@ The `InMemoryMcpTaskStore` constructor accepts several optional parameters:
 
 ```csharp
 var taskStore = new InMemoryMcpTaskStore(
-    defaultTtl: TimeSpan.FromHours(1),      // Default task retention time
-    maxTtl: TimeSpan.FromHours(24),         // Maximum allowed TTL
-    pollInterval: TimeSpan.FromSeconds(1),  // Suggested client poll interval
+    defaultTtl: TimeSpan.FromHours(1),        // Default task retention time
+    maxTtl: TimeSpan.FromHours(24),           // Maximum allowed TTL
+    pollInterval: TimeSpan.FromSeconds(1),    // Suggested client poll interval
     cleanupInterval: TimeSpan.FromMinutes(5), // Background cleanup frequency
-    pageSize: 100                           // Tasks per page for listing
+    pageSize: 100,                            // Tasks per page for listing
+    maxTasks: 1000,                           // Maximum total tasks allowed
+    maxTasksPerSession: 100                   // Maximum tasks per session
 );
 ```
 
@@ -435,7 +437,7 @@ try
 {
     var task = await client.GetTaskAsync(taskId, cancellationToken: ct);
 }
-catch (McpException ex) when (ex.ErrorCode == McpErrorCode.InvalidParams)
+catch (McpProtocolException ex) when (ex.ErrorCode == McpErrorCode.InvalidParams)
 {
     Console.WriteLine($"Task not found: {taskId}");
 }