ModelContextProtocol C SDK 中 IMcpServer 服务解析问题解析

在 ModelContextProtocol 的 C# SDK 开发过程中，开发者可能会遇到一个常见的依赖注入问题："Unable to resolve service for type 'ModelContextProtocol.Server.IMcpServer'"。这个问题通常出现在尝试使用 IMcpServer 接口作为构造函数参数时。

问题本质

该问题的核心在于 ModelContextProtocol SDK 的特殊设计模式。与常规的 ASP.NET Core 依赖注入不同，IMcpServer 接口并不是通过标准的 DI 容器注册和解析的。SDK 内部使用了 ActivatorUtilities.CreateInstance 来创建工具类实例，这种方式对构造函数参数的处理与标准 DI 容器有所不同。

正确使用方法

开发者需要注意以下几点：

1. 构造函数限制：IMcpServer 不能作为工具类的构造函数参数。这是 SDK 的当前设计限制。

2. 方法参数支持：IMcpServer 可以作为工具方法的参数直接使用。SDK 会特殊处理这种情况，自动提供正确的服务器实例。

3. 替代方案：如果需要获取会话ID等服务器相关信息，应该通过方法参数而非构造函数来获取 IMcpServer 实例。

最佳实践示例

以下是正确使用 IMcpServer 的代码示例：

[McpServerTool(Name = "SampleTool")]
public static async Task<string> ExampleToolMethod(
    IMcpServer serverInstance, // 正确：作为方法参数
    CancellationToken cancellationToken)
{
    // 使用 serverInstance 进行操作
    return await serverInstance.DoSomethingAsync();
}

技术背景

这种设计选择反映了 SDK 的特定架构考虑：

1. 轻量级激活：使用 ActivatorUtilities 而非完整 DI 容器，可能是为了性能和简化。

2. 上下文感知：方法调用时能获取当前会话上下文，而构造函数调用时上下文可能尚未建立。

3. 明确边界：强制开发者区分工具初始化逻辑和实际执行逻辑。

开发者建议

1. 避免在构造函数中依赖 IMcpServer 或其他上下文相关服务。

2. 将服务器相关的操作逻辑放在工具方法中而非构造函数中。

3. 如果需要初始化逻辑，考虑使用无参构造函数配合延迟初始化模式。

理解这些设计决策有助于开发者更有效地使用 ModelContextProtocol SDK，并避免常见的依赖注入陷阱。