CS1066 warnings for MCP tool methods with optional parameters

[jongalloway]

Describe the bug
When the ModelContextProtocol C# SDK’s XML Documentation Source Generator runs against an assembly that defines MCP tools with optional parameters (defaults like bool forceReload = false, string? framework = null, etc.), the build produces many CS1066 warnings.

Example warning shape:

warning CS1066: The default value specified for parameter 'forceReload' will have no effect because it applies to a member that is used in contexts that do not allow optional arguments

This appears to be caused by how the XML documentation source generator (and/or the generated tool registration/invocation code it participates in) references the tool methods—likely in a context where optional-argument semantics do not apply (e.g., method group conversion to a delegate or other generated call sites). The result is that optional defaults, which are intentional and useful for tool ergonomics and MCP metadata/schema, are flagged as “having no effect,” and the warnings repeat across many tool methods, creating very noisy CI logs.

To Reproduce
Steps to reproduce the behavior:

1. Create a minimal .NET console app (net8.0 or net10.0).
2. Add the MCP server SDK package (observed with 0.5.0-preview.1).
3. Define an [McpServerToolType] class with [McpServerTool] methods that include optional parameters with default values.
4. Register tools using WithToolsFromAssembly() (or an equivalent SDK mechanism that triggers tool registration / source generation).
5. Build the project.

Minimal code sample:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using ModelContextProtocol.Server;
using System.ComponentModel;

var builder = Host.CreateApplicationBuilder(args);

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();

await builder.Build().RunAsync();

[McpServerToolType]
public sealed class SampleTools
{
    [McpServerTool, Description("Example tool with optional params")]
    public string Hello(
        [Description("Name to greet")] string name,
        [Description("Optional loud flag")] bool loud = false,
        [Description("Optional prefix")] string prefix = "Hello")
        => loud ? $"{prefix.ToUpperInvariant()} {name}!" : $"{prefix} {name}";
}

Expected behavior
The SDK’s normal tool registration pattern should not produce CS1066 warnings for MCP tool methods that declare optional parameters with defaults.

Optional parameters are a common ergonomic pattern for tool methods and are useful for schema/metadata and for runtime argument binding behavior. Downstream projects shouldn’t need to suppress CS1066 globally to get clean CI builds.

Logs
Representative warning (actual projects may emit hundreds of these):
warning CS1066: The default value specified for parameter 'loud' will have no effect because it applies to a member that is used in contexts that do not allow optional arguments

Observed in CI/CD during dotnet build -c Release on GitHub Actions (Ubuntu runner) and locally on Windows.

Additional context
This appears to be caused by how the SDK (likely via source generator output) binds tool methods into the runtime invocation pipeline. CS1066 is typically emitted when a method with optional parameter defaults is “used” in a context where optional arguments cannot be applied (e.g., method group conversion to a delegate with a fixed signature or a generated call site that always supplies explicit arguments).

Recommendation / likely fix direction:

• Adjust the generated tool registration/invocation code so it does not reference the original tool method in a way that disables optional-argument semantics.
• Prefer generating a wrapper invoker per tool that:
  • takes a structured argument payload (e.g., JsonElement / dictionary),
  • fills missing arguments using reflection (ParameterInfo.HasDefaultValue / DefaultValue) or equivalent logic,
  • and then invokes the tool method without producing CS1066.
• Register the wrapper invoker as the tool entrypoint, rather than binding directly to the original method group.

Workaround today: downstream projects can suppress CS1066, but that’s a blunt workaround and not ideal for libraries/templates.