Semantic Kernel 与 Model Context Protocol 集成指南MCP 概念到内核插件体系的双向映射与实践落地【免费下载链接】semantic-kernelIntegrate cutting-edge LLM technology quickly and easily into your apps项目地址: https://gitcode.com/GitHub_Trending/se/semantic-kernel导读本文以 Semantic Kernel 仓库中的架构决策记录 docs/decisions/0069-mcp.md 为核心脉络系统讲解 Model Context ProtocolMCP与 Semantic Kernel 的双向集成方案一方面阐述 Semantic Kernel 如何作为MCP Host消费外部服务器的 Tools 与 Prompts另一方面说明如何将 Kernel/Agent 作为MCP Server对外暴露能力。文中将完整保留 ADR 中的概念映射表并结合仓库内 Python 与 .NET 的源码实现、示例代码与配置细节进行纵深验证。读完本文你将掌握 MCP 六大核心概念Server、Resources、Prompts、Tools、Sampling、Roots在 Semantic Kernel 中的落点能够独立完成把 MCP 服务器接入内核插件与把内核能力发布为 MCP 服务器两种方向的工程实践。一、背景与问题陈述为什么 Semantic Kernel 需要集成 MCPMCPModel Context Protocol正快速成为 AI 模型交互的事实标准。Semantic Kernel 将 MCP 集成视为增强平台互操作性的关键手段通过接入 MCP开发者可以更容易地构建同时利用多个模型与多种服务的应用。本 ADR 的目标是定义 MCP 概念到 Semantic Kernel 概念的映射关系为 MCP 在 Semantic Kernel 中的实现提供路线图。由于 MCP 协议本身仍在积极演进该文档日期为 2024-04-08deciders 为 eavanvalkenburg、markwallace、sergeymenshykh、sphenry文档明确指出随着新概念被加入或实现方式发生变化本文档需要持续更新。从仓库现状看这一路线图已经落地为可运行的实现与示例Python 侧核心实现集中在 python/semantic_kernel/connectors/mcp.py约 1239 行示例位于 python/samples/concepts/mcp 与 python/samples/demos/mcp_server.NET 侧示例位于 dotnet/samples/Demos/ModelContextProtocolClientServer基于官方 MCP C# SDK 构建。二、顶层设计Server 与 Host 的角色二分MCP 架构的第一个高层概念是Server与Host的区分Server向任意 Host 提供一个或多个能力capabilitiesHost通过Client连接 Server使应用程序能够消费 Server 的能力。两者是多对多关系一个 Host 可以是多个 Server 的客户端一个 Server 也可以被多个 Host 承载。Semantic Kernel 的集成战略据此分为两个方向分别对应 ADR 的Design - Semantic Kernel as a Host与Design - Semantic Kernel as a Server两节下文逐一展开。三、方向一Semantic Kernel 作为 MCP Host作为 HostSemantic Kernel 通过创建一个使用 MCP SDK Client 连接 Server 的插件来消费服务器能力。这一设计在 Python 侧直接体现为MCPPluginBase及其四个传输实现子类全部位于 python/semantic_kernel/connectors/mcp.py。3.1 概念映射表Host 视角MCP 概念Semantic Kernel 概念说明ServerPlugin服务器被暴露为一组相关函数因此映射为插件。Resources不明确UnclearResource 是非常通用的概念可能适配某个 SK 概念但并不适配全部需要进一步调研。Prompts外部 Prompt 渲染 / 函数调用Prompt 是服务器开发者创建的便捷入口可以是填入参数的单句提示也可以是一来一回模拟聊天的消息序列用于引导某个结果。它映射到 PromptTemplate 的渲染步骤但渲染由服务器完成SK 负责消费输出是一组 PromptMessages大致等价于一组 ChatMessageContents可发送给 LLM 完成生成具体工作方式待明确。ToolsFunctionTool 是服务器提供的某项功能映射为 Semantic Kernel 的 Function。最常见的用法是通过 function calling 调用映射关系非常自然并应包含对listChanged事件的处理。Samplingget_chat_message_contentSampling 是 MCP 的强力特性服务器通过客户端请求 LLM 补全从而在保证安全与隐私的同时实现复杂的 Agent 行为。即服务器向 SK Host 发送消息由 SK Host 调用 LLM 完成。这要求在 MCP 的ModelPreferences与消息细节、SK 的PromptExecutionSettings与服务选择器service selectors之间建立映射。Roots取决于当前上下文Roots 定义服务器可操作的边界客户端需告知服务器相关资源及其位置。SK 应向所用服务器发送当前上下文的roots具体取决于场景例如 .NET 的 FileIOPlugin 可能用到Python 当前没有此能力。Transports不同的插件实现SK 应支持所有传输方式并抽象其差异插件与 Host 都只需通过配置切换即可使用任意传输。Completion不映射UnmappedMCP 的 Completion 用于输入时的字符级自动补全如输入 Resource URL 时SK 无需支持基于 SK 构建的客户端可自行实现。Progress不映射UnmappedMCP 的 Progress 用于展示长任务的进度SK 无需支持客户端可自行实现。3.2 源码级验证插件如何消费服务器能力Python 侧的MCPPluginBasepython/semantic_kernel/connectors/mcp.py完整承载了上表中的 Host 侧职责插件生命周期与连接管理构造函数接受name、description、load_tools、load_prompts、session、kernel、request_timeout、sampling_consent_callback、sampling_auto_approve等参数connect()/close()通过AsyncExitStack管理底层连接_inner_connect()依次完成建立传输 → 创建ClientSession→session.initialize()初始化握手初始化完成后按load_tools/load_prompts开关分别调用load_tools()与load_prompts()。Tools → KernelFunction 的动态装载load_tools()遍历session.list_tools()返回的每个 tool解析其inputSchema的properties与required字段生成参数元数据见_get_parameter_dicts_from_mcp_tool然后用kernel_function装饰器将call_tool(tool.name, ...)包装成内核函数并挂载为插件属性。调用时call_tool()经session.call_tool()执行远端工具返回结果由_mcp_call_tool_result_to_kernel_contents转换为 SK 内容类型。Prompts → KernelFunction 的动态装载load_prompts()遍历session.list_prompts()将每个 prompt 包装为调用get_prompt(prompt.name, ...)的内核函数。get_prompt()返回list[ChatMessageContent]——这与映射表中输出是一组 PromptMessages大致等价于一组 ChatMessageContents的描述完全一致。listChanged 事件处理message_handler()针对notifications/tools/list_changed与notifications/prompts/list_changed两种服务器通知分别触发load_tools()与load_prompts()的重载——正是映射表中应包含 listChanged 事件处理的实现。Sampling 回调Host 侧sampling_callback()是映射表中 Sampling 映射为get_chat_message_content的直接实现先经过授权检查若配置了sampling_consent_callback则回调征求同意返回False即拒绝若未配置回调则sampling_auto_approveTrue时自动放行并记录警告日志否则默认拒绝授权通过后根据params.modelPreferences.hints中的模型名缺省为default从kernel中挑选ChatCompletionClientBase服务将 MCP 的temperature、maxTokens映射到PromptExecutionSettings对应字段max_completion_tokens/max_tokens/max_output_tokens视服务能力而定把 MCP 消息经_mcp_prompt_message_to_kernel_content转为ChatHistory调用service.get_chat_message_content()获得结果再经_kernel_content_to_mcp_content_types转回 MCP 内容类型最终返回CreateMessageResult。四种传输实现Transports 抽象映射表中Transports → 不同插件实现的落地就是四个子类均只需改换构造参数即可切换传输MCPStdioPlugincommandargsenvencoding适用于本地进程型服务器如 npx、uvx、docker 启动的服务MCPSsePluginurlheaderstimeoutsse_read_timeout适用于 SSE 传输的远程服务器MCPStreamableHttpPluginurl 可选terminate_on_close等适用于 Streamable HTTP 传输MCPWebsocketPluginurl适用于 WebSocket 传输。此外_normalize_mcp_name()会把远端 tool/prompt 名称规范化非[A-Za-z0-9_.-]字符替换为-并内置名称冲突防护_has_mcp_function_name_conflict避免与插件自带属性冲突_is_mcp_local_name_taken避免规范化后重名导致的静默覆盖。3.3 实战示例把 GitHub MCP 服务器接入内核仓库示例 python/samples/concepts/mcp/mcp_as_plugin.py 演示了完整的 Host 消费链路from semantic_kernel import Kernel from semantic_kernel.connectors.ai import FunctionChoiceBehavior from semantic_kernel.connectors.mcp import MCPStdioPlugin kernel Kernel() chat_service, settings get_chat_completion_service_and_request_settings(Services.OPENAI) settings.function_choice_behavior FunctionChoiceBehavior.Auto() # 自动函数调用 kernel.add_service(chat_service) async with MCPStdioPlugin( nameGithub, descriptionGithub Plugin, commanddocker, args[run, -i, --rm, -e, GITHUB_PERSONAL_ACCESS_TOKEN, ghcr.io/github/github-mcp-server], env{GITHUB_PERSONAL_ACCESS_TOKEN: os.getenv(GITHUB_PERSONAL_ACCESS_TOKEN)}, ) as github_plugin: kernel.add_plugin(github_plugin) # ... 进入聊天循环模型按需调用 MCP 工具运行前提见 python/samples/concepts/mcp/README.md安装带 mcp 扩展的包pip install semantic-kernel[mcp]依据所用服务器准备运行器GitHub MCP Server 需要 Docker 与 GitHub PAT本地服务器通常用uvx或docker确保npx/uvx/docker在 PATH 中执行示例cd python/samples/concepts/mcp python mcp_as_plugin.py。同一个文件夹下还提供了agent_with_mcp_plugin.pyMCP 插件接入 Agent、agent_with_mcp_sampling.pyMCP 采样场景、azure_ai_agent_with_mcp_plugin.pyAzure AI Agent 消费 MCP 工具等衍生示例读者可按注释中的环境变量要求逐个运行。四、方向二Semantic Kernel 作为 MCP Server另一个方向是让 Semantic Kernel 扮演服务器把Kernel 和/或 Agent的能力暴露给任意兼容 Host如 Claude Desktop、MCP Inspector。4.1 概念映射表Server 视角MCP 概念Semantic Kernel 概念说明ServerKernel / Agent服务器被暴露为一组相关函数因此可以把单个 Kernel 或 Agent 作为 MCP Server 暴露供任意兼容 Host 消费。Resources不明确Unclear同 Host 侧Resource 概念过于通用需要进一步调研。PromptsPromptTemplatePrompt 是 SK 服务器开发者创建的便捷入口可以是填入参数的单句提示也可以是一组模拟聊天的消息序列。映射到 PromptTemplate但输出需为一组 PromptMessages大致等价于一组 ChatMessageContents需要做一些通用化工作。此场景下客户端请求 prompt 并附带参数SK 渲染后转为list[ChatMessageContent]再转为list[types.PromptMessage]。ToolsFunction同 Host 侧映射为内核 Function最常见的用法是 function calling同时应向外发出listChanged事件。Sampling不明确UnclearSampling 允许服务器请求客户端用其 LLM 完成补全。对 SK 而言此能力与自身核心功能重叠大概率无需映射——该特性主要对自身不直接交互 LLM的 MCP 服务器有用。Roots不明确UnclearSK 应向客户端发送roots定义操作边界当前如何映射尚不明确。Transports语言相关Python 侧由 MCP SDK 统一交互并托管到各传输类型SK 本身无需指定。Completion不映射Unmapped输入时的字符级自动补全如 Resource URL 或 Prompt 引用。若 SK 支持 Prompt 与 Resources则应顺带为其提供 OOTB 的补全支持。Logging内置日志器MCP Logging 记录客户端与服务器的交互SK 应默认添加可由客户端/Host 设置与切换的日志处理器。Progress不映射Unmapped长任务的进度展示。对执行复杂长任务的 Agents 或 Processes 可能很有价值实现方式待明确。4.2 源码级验证内核能力如何发布为 MCP 服务器Python 侧的 Server 方向由两个工厂函数实现python/semantic_kernel/connectors/mcp.pycreate_mcp_server_from_functions接受单个或混合的KernelFunction/KernelPlugin/ 可解析为插件的对象统一挂到plugin_name默认mcp下再转调create_mcp_server_from_kernel。create_mcp_server_from_kernel接受一个 Kernel 实例可选参数包括server_name默认SK、version、instructions、lifespan、excluded_functions。核心行为默认把 Kernel 的全部函数暴露为 Tools可用excluded_functions需传函数名不含 plugin 名排除server.list_tools()遍历函数元数据将参数名、schema_data、是否必填映射为 MCPinputSchemapropertiesrequiredserver.call_tool()按函数名在exposed_names中校验后调用_call_kernel_function把返回值TextContent/ImageContent/BinaryContent/AudioContent/ChatMessageContent或普通对象统一转换为 MCP 内容类型传入prompts列表list[PromptTemplateBase]时server.list_prompts()依据prompt_template_config的 name/description/input_variables 生成types.Promptserver.get_prompt()调用prompt.render(kernel, KernelArguments(...))渲染模板再经ChatHistory.from_rendered_prompt拆分为list[types.PromptMessage]——与映射表描述的转换链路一一对应server.set_logging_level()与_log()实现映射表中的 Logging 职责既写入本地 logger也通过server.request_context.session.send_log_message把日志发给客户端。Agent 即服务器示例 python/samples/concepts/mcp/servers/restaurant_booking_agent_server.py 展示了一条极简路径——agent.as_mcp_server()直接把ChatCompletionAgent含BookingPlugin等插件变成 MCP 服务器再配合 stdio 或 SSE 传输运行agent ChatCompletionAgent( serviceAzureChatCompletion(credentialAzureCliCredential()), nameBooker, instructionsCreate a booking for the user, ..., plugins[BookingPlugin()], ) server agent.as_mcp_server()该脚本支持--transport stdio|sse与--port参数stdio 模式走mcp.server.stdio.stdio_serverSSE 模式用 Starlette SseServerTransport挂载/sse与/messages/路由后由 uvicorn 托管。4.3 .NET 侧落地MCP Client/Server 完整示例.NET 侧的端到端示例位于 dotnet/samples/Demos/ModelContextProtocolClientServer由MCPClient与MCPServer两个项目组成。MCPServer 的装配方式dotnet/samples/Demos/ModelContextProtocolClientServer/MCPServer/Program.cs清晰展示了Kernel/Agent 作为 Server的四种能力暴露// 注册 SK 插件与 SK Agent作为插件 kernelBuilder.Plugins.AddFromTypeDateTimeUtils(); kernelBuilder.Plugins.AddFromTypeWeatherUtils(); kernelBuilder.Plugins.AddFromTypeMailboxUtils(); kernelBuilder.Plugins.AddFromFunctions(Agents, [AgentKernelFunctionFactory.CreateFromAgent(CreateSalesAssistantAgent(chatModelId, apiKey))]); // 注册 MCP 服务器 builder.Services .AddMcpServer() .WithStdioServerTransport() .WithTools() // SK 插件函数 → MCP tools .WithPrompt(PromptDefinition.Create(...)) // SK prompt 模板 → MCP prompts .WithResourceTemplate(CreateVectorStoreSearchResourceTemplate()) // 内核函数 → Resource 模板 .WithResource(ResourceDefinition.CreateBlobResource(...)); // 静态资源 → MCP resources即SK 插件作为 MCP 工具、SK 提示词模板作为 MCP prompts、Kernel Function 作为 MCPReadresource 处理器、Kernel Function 作为 resource template 处理器——四种暴露路径一应俱全。MCPClient 的消费方式MCPClient项目中的Samples目录覆盖了 Host 侧全部场景——MCPToolsSample导入 MCP 工具为 SK 函数并经 Chat Completion 调用、MCPPromptSample用 MCP prompts 作为附加上下文、MCPResourcesSample/MCPResourceTemplatesSample资源与资源模板作为附加上下文、MCPSamplingSample在 human-in-the-loop 场景拦截并处理服务器的采样请求、ChatCompletionAgentWithMCPToolsSample/AzureAIAgentWithMCPToolsSample经 Chat Completion 与 Azure AI Agent 消费 MCP 工具。配置与运行见 dotnet/samples/Demos/ModelContextProtocolClientServer/README.md密钥可用 Secret Manager 或环境变量配置OpenAI:ChatModelId、OpenAI:ApiKey、AzureAI:ConnectionString、AzureAI:ChatModelId在 Visual Studio 中把MCPClient设为启动项目并按 F5 运行所有示例按顺序执行也可在Program.cs的Main中注释掉其余示例单独运行可用npx modelcontextprotocol/inspector dotnet run启动MCP Inspector在 MCPServer 项目目录下随后在浏览器中打开终端输出的 URL 并点击 Connect即可看到工具、提示词与资源清单也可配置 Claude Desktop 的claude_desktop_config.json将command指向MCPServer.exe来接入该服务器。五、边界与未决项ADR 留下的开放问题从两张映射表可以看出集成设计并非全盘映射而是有意识地保留了边界Resources两侧均为 UnclearMCP 的资源概念太通用SK 侧尚未确定统一落点但 .NET 示例已经通过Kernel Function 作为Read处理器 / resource template 处理器的方式给出了实践雏形。RootsHost 侧依赖上下文Server 侧 UnclearHost 侧原则上是把当前上下文的 roots 发给服务器但实际取决于具体插件如 .NET FileIOPluginPython 侧当前未实现。SamplingHost 侧已实现Server 侧 UnclearHost 侧已由sampling_callback完整落地并配套sampling_consent_callback/sampling_auto_approve的安全策略Server 侧因与 SK 自身能力重叠而大概率不需要映射。Completion 与 Progress两侧均 Unmapped字符级自动补全与长任务进度条不属于 SK 必须支持的能力留给基于 SK 构建的客户端自行实现但 Server 侧文档提示若未来支持 Prompt 与 Resources应为其提供 OOTB 的 completion 支持。Logging仅 Server 侧映射为 Built-in loggersPython 服务端已通过set_logging_levelsend_log_message实现Python 客户端插件也内置了logging_callback可将 MCP 服务器的日志消息按LOG_LEVEL_MAPPING转发到本端 loggerdebug→DEBUG、info/notice→INFO、warning→WARNING、error→ERROR、critical/alert/emergency→CRITICAL。这些未决项印证了 ADR 的自我定位——由于 MCP 正在积极开发中本文档需要随新概念的加入与实现变化持续更新。六、总结与实践路线图围绕 docs/decisions/0069-mcp.md 的映射设计Semantic Kernel 仓库已形成两条相互独立又互补的实践路径作为 Host 消费 MCPpip install semantic-kernel[mcp]后用MCPStdioPlugin/MCPSsePlugin/MCPStreamableHttpPlugin/MCPWebsocketPlugin之一连接服务器tools 与 prompts 会被自动装载为内核函数配合FunctionChoiceBehavior.Auto()即可在聊天或 Agent 中通过 function calling 直接调用采样请求则通过sampling_consent_callback/sampling_auto_approve进行安全控制。参考 python/samples/concepts/mcp/mcp_as_plugin.py 与 dotnet/samples/Demos/ModelContextProtocolClientServer/MCPClient。作为 Server 暴露能力create_mcp_server_from_functions/create_mcp_server_from_kernel/agent.as_mcp_server()把 Kernel 或 Agent 的插件函数与 PromptTemplate 发布为 MCP 服务器再经 stdio / SSE 传输托管即可被 MCP Inspector、Claude Desktop 等任意兼容 Host 消费。参考 python/samples/demos/mcp_server 与 dotnet/samples/Demos/ModelContextProtocolClientServer/MCPServer。核心实现均在 python/semantic_kernel/connectors/mcp.py 中且整体标记为experimental实验性 API接口细节可能随 MCP 协议演进而调整——这正是 ADR 强调持续更新的原因。开发者接入时建议同时关注 MCP 协议规范的最新变更与本仓库对应模块的版本更新。【免费下载链接】semantic-kernelIntegrate cutting-edge LLM technology quickly and easily into your apps项目地址: https://gitcode.com/GitHub_Trending/se/semantic-kernel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Semantic Kernel 与 Model Context Protocol 集成指南：MCP 概念到内核插件体系的双向映射与实践落地
Semantic Kernel 与 Model Context Protocol 集成指南MCP 概念到内核插件体系的双向映射与实践落地【免费下载链接】semantic-kernelIntegrate cutting-edge LLM technology quickly and easily into your apps项目地址: https://gitcode.com/GitHub_Trending/se/semantic-kernel导读本文以 Semantic Kernel 仓库中的架构决策记录 docs/decisions/0069-mcp.md 为核心脉络系统讲解 Model Context ProtocolMCP与 Semantic Kernel 的双向集成方案一方面阐述 Semantic Kernel 如何作为MCP Host消费外部服务器的 Tools 与 Prompts另一方面说明如何将 Kernel/Agent 作为MCP Server对外暴露能力。文中将完整保留 ADR 中的概念映射表并结合仓库内 Python 与 .NET 的源码实现、示例代码与配置细节进行纵深验证。读完本文你将掌握 MCP 六大核心概念Server、Resources、Prompts、Tools、Sampling、Roots在 Semantic Kernel 中的落点能够独立完成把 MCP 服务器接入内核插件与把内核能力发布为 MCP 服务器两种方向的工程实践。一、背景与问题陈述为什么 Semantic Kernel 需要集成 MCPMCPModel Context Protocol正快速成为 AI 模型交互的事实标准。Semantic Kernel 将 MCP 集成视为增强平台互操作性的关键手段通过接入 MCP开发者可以更容易地构建同时利用多个模型与多种服务的应用。本 ADR 的目标是定义 MCP 概念到 Semantic Kernel 概念的映射关系为 MCP 在 Semantic Kernel 中的实现提供路线图。由于 MCP 协议本身仍在积极演进该文档日期为 2024-04-08deciders 为 eavanvalkenburg、markwallace、sergeymenshykh、sphenry文档明确指出随着新概念被加入或实现方式发生变化本文档需要持续更新。从仓库现状看这一路线图已经落地为可运行的实现与示例Python 侧核心实现集中在 python/semantic_kernel/connectors/mcp.py约 1239 行示例位于 python/samples/concepts/mcp 与 python/samples/demos/mcp_server.NET 侧示例位于 dotnet/samples/Demos/ModelContextProtocolClientServer基于官方 MCP C# SDK 构建。二、顶层设计Server 与 Host 的角色二分MCP 架构的第一个高层概念是Server与Host的区分Server向任意 Host 提供一个或多个能力capabilitiesHost通过Client连接 Server使应用程序能够消费 Server 的能力。两者是多对多关系一个 Host 可以是多个 Server 的客户端一个 Server 也可以被多个 Host 承载。Semantic Kernel 的集成战略据此分为两个方向分别对应 ADR 的Design - Semantic Kernel as a Host与Design - Semantic Kernel as a Server两节下文逐一展开。三、方向一Semantic Kernel 作为 MCP Host作为 HostSemantic Kernel 通过创建一个使用 MCP SDK Client 连接 Server 的插件来消费服务器能力。这一设计在 Python 侧直接体现为MCPPluginBase及其四个传输实现子类全部位于 python/semantic_kernel/connectors/mcp.py。3.1 概念映射表Host 视角MCP 概念Semantic Kernel 概念说明ServerPlugin服务器被暴露为一组相关函数因此映射为插件。Resources不明确UnclearResource 是非常通用的概念可能适配某个 SK 概念但并不适配全部需要进一步调研。Prompts外部 Prompt 渲染 / 函数调用Prompt 是服务器开发者创建的便捷入口可以是填入参数的单句提示也可以是一来一回模拟聊天的消息序列用于引导某个结果。它映射到 PromptTemplate 的渲染步骤但渲染由服务器完成SK 负责消费输出是一组 PromptMessages大致等价于一组 ChatMessageContents可发送给 LLM 完成生成具体工作方式待明确。ToolsFunctionTool 是服务器提供的某项功能映射为 Semantic Kernel 的 Function。最常见的用法是通过 function calling 调用映射关系非常自然并应包含对listChanged事件的处理。Samplingget_chat_message_contentSampling 是 MCP 的强力特性服务器通过客户端请求 LLM 补全从而在保证安全与隐私的同时实现复杂的 Agent 行为。即服务器向 SK Host 发送消息由 SK Host 调用 LLM 完成。这要求在 MCP 的ModelPreferences与消息细节、SK 的PromptExecutionSettings与服务选择器service selectors之间建立映射。Roots取决于当前上下文Roots 定义服务器可操作的边界客户端需告知服务器相关资源及其位置。SK 应向所用服务器发送当前上下文的roots具体取决于场景例如 .NET 的 FileIOPlugin 可能用到Python 当前没有此能力。Transports不同的插件实现SK 应支持所有传输方式并抽象其差异插件与 Host 都只需通过配置切换即可使用任意传输。Completion不映射UnmappedMCP 的 Completion 用于输入时的字符级自动补全如输入 Resource URL 时SK 无需支持基于 SK 构建的客户端可自行实现。Progress不映射UnmappedMCP 的 Progress 用于展示长任务的进度SK 无需支持客户端可自行实现。3.2 源码级验证插件如何消费服务器能力Python 侧的MCPPluginBasepython/semantic_kernel/connectors/mcp.py完整承载了上表中的 Host 侧职责插件生命周期与连接管理构造函数接受name、description、load_tools、load_prompts、session、kernel、request_timeout、sampling_consent_callback、sampling_auto_approve等参数connect()/close()通过AsyncExitStack管理底层连接_inner_connect()依次完成建立传输 → 创建ClientSession→session.initialize()初始化握手初始化完成后按load_tools/load_prompts开关分别调用load_tools()与load_prompts()。Tools → KernelFunction 的动态装载load_tools()遍历session.list_tools()返回的每个 tool解析其inputSchema的properties与required字段生成参数元数据见_get_parameter_dicts_from_mcp_tool然后用kernel_function装饰器将call_tool(tool.name, ...)包装成内核函数并挂载为插件属性。调用时call_tool()经session.call_tool()执行远端工具返回结果由_mcp_call_tool_result_to_kernel_contents转换为 SK 内容类型。Prompts → KernelFunction 的动态装载load_prompts()遍历session.list_prompts()将每个 prompt 包装为调用get_prompt(prompt.name, ...)的内核函数。get_prompt()返回list[ChatMessageContent]——这与映射表中输出是一组 PromptMessages大致等价于一组 ChatMessageContents的描述完全一致。listChanged 事件处理message_handler()针对notifications/tools/list_changed与notifications/prompts/list_changed两种服务器通知分别触发load_tools()与load_prompts()的重载——正是映射表中应包含 listChanged 事件处理的实现。Sampling 回调Host 侧sampling_callback()是映射表中 Sampling 映射为get_chat_message_content的直接实现先经过授权检查若配置了sampling_consent_callback则回调征求同意返回False即拒绝若未配置回调则sampling_auto_approveTrue时自动放行并记录警告日志否则默认拒绝授权通过后根据params.modelPreferences.hints中的模型名缺省为default从kernel中挑选ChatCompletionClientBase服务将 MCP 的temperature、maxTokens映射到PromptExecutionSettings对应字段max_completion_tokens/max_tokens/max_output_tokens视服务能力而定把 MCP 消息经_mcp_prompt_message_to_kernel_content转为ChatHistory调用service.get_chat_message_content()获得结果再经_kernel_content_to_mcp_content_types转回 MCP 内容类型最终返回CreateMessageResult。四种传输实现Transports 抽象映射表中Transports → 不同插件实现的落地就是四个子类均只需改换构造参数即可切换传输MCPStdioPlugincommandargsenvencoding适用于本地进程型服务器如 npx、uvx、docker 启动的服务MCPSsePluginurlheaderstimeoutsse_read_timeout适用于 SSE 传输的远程服务器MCPStreamableHttpPluginurl 可选terminate_on_close等适用于 Streamable HTTP 传输MCPWebsocketPluginurl适用于 WebSocket 传输。此外_normalize_mcp_name()会把远端 tool/prompt 名称规范化非[A-Za-z0-9_.-]字符替换为-并内置名称冲突防护_has_mcp_function_name_conflict避免与插件自带属性冲突_is_mcp_local_name_taken避免规范化后重名导致的静默覆盖。3.3 实战示例把 GitHub MCP 服务器接入内核仓库示例 python/samples/concepts/mcp/mcp_as_plugin.py 演示了完整的 Host 消费链路from semantic_kernel import Kernel from semantic_kernel.connectors.ai import FunctionChoiceBehavior from semantic_kernel.connectors.mcp import MCPStdioPlugin kernel Kernel() chat_service, settings get_chat_completion_service_and_request_settings(Services.OPENAI) settings.function_choice_behavior FunctionChoiceBehavior.Auto() # 自动函数调用 kernel.add_service(chat_service) async with MCPStdioPlugin( nameGithub, descriptionGithub Plugin, commanddocker, args[run, -i, --rm, -e, GITHUB_PERSONAL_ACCESS_TOKEN, ghcr.io/github/github-mcp-server], env{GITHUB_PERSONAL_ACCESS_TOKEN: os.getenv(GITHUB_PERSONAL_ACCESS_TOKEN)}, ) as github_plugin: kernel.add_plugin(github_plugin) # ... 进入聊天循环模型按需调用 MCP 工具运行前提见 python/samples/concepts/mcp/README.md安装带 mcp 扩展的包pip install semantic-kernel[mcp]依据所用服务器准备运行器GitHub MCP Server 需要 Docker 与 GitHub PAT本地服务器通常用uvx或docker确保npx/uvx/docker在 PATH 中执行示例cd python/samples/concepts/mcp python mcp_as_plugin.py。同一个文件夹下还提供了agent_with_mcp_plugin.pyMCP 插件接入 Agent、agent_with_mcp_sampling.pyMCP 采样场景、azure_ai_agent_with_mcp_plugin.pyAzure AI Agent 消费 MCP 工具等衍生示例读者可按注释中的环境变量要求逐个运行。四、方向二Semantic Kernel 作为 MCP Server另一个方向是让 Semantic Kernel 扮演服务器把Kernel 和/或 Agent的能力暴露给任意兼容 Host如 Claude Desktop、MCP Inspector。4.1 概念映射表Server 视角MCP 概念Semantic Kernel 概念说明ServerKernel / Agent服务器被暴露为一组相关函数因此可以把单个 Kernel 或 Agent 作为 MCP Server 暴露供任意兼容 Host 消费。Resources不明确Unclear同 Host 侧Resource 概念过于通用需要进一步调研。PromptsPromptTemplatePrompt 是 SK 服务器开发者创建的便捷入口可以是填入参数的单句提示也可以是一组模拟聊天的消息序列。映射到 PromptTemplate但输出需为一组 PromptMessages大致等价于一组 ChatMessageContents需要做一些通用化工作。此场景下客户端请求 prompt 并附带参数SK 渲染后转为list[ChatMessageContent]再转为list[types.PromptMessage]。ToolsFunction同 Host 侧映射为内核 Function最常见的用法是 function calling同时应向外发出listChanged事件。Sampling不明确UnclearSampling 允许服务器请求客户端用其 LLM 完成补全。对 SK 而言此能力与自身核心功能重叠大概率无需映射——该特性主要对自身不直接交互 LLM的 MCP 服务器有用。Roots不明确UnclearSK 应向客户端发送roots定义操作边界当前如何映射尚不明确。Transports语言相关Python 侧由 MCP SDK 统一交互并托管到各传输类型SK 本身无需指定。Completion不映射Unmapped输入时的字符级自动补全如 Resource URL 或 Prompt 引用。若 SK 支持 Prompt 与 Resources则应顺带为其提供 OOTB 的补全支持。Logging内置日志器MCP Logging 记录客户端与服务器的交互SK 应默认添加可由客户端/Host 设置与切换的日志处理器。Progress不映射Unmapped长任务的进度展示。对执行复杂长任务的 Agents 或 Processes 可能很有价值实现方式待明确。4.2 源码级验证内核能力如何发布为 MCP 服务器Python 侧的 Server 方向由两个工厂函数实现python/semantic_kernel/connectors/mcp.pycreate_mcp_server_from_functions接受单个或混合的KernelFunction/KernelPlugin/ 可解析为插件的对象统一挂到plugin_name默认mcp下再转调create_mcp_server_from_kernel。create_mcp_server_from_kernel接受一个 Kernel 实例可选参数包括server_name默认SK、version、instructions、lifespan、excluded_functions。核心行为默认把 Kernel 的全部函数暴露为 Tools可用excluded_functions需传函数名不含 plugin 名排除server.list_tools()遍历函数元数据将参数名、schema_data、是否必填映射为 MCPinputSchemapropertiesrequiredserver.call_tool()按函数名在exposed_names中校验后调用_call_kernel_function把返回值TextContent/ImageContent/BinaryContent/AudioContent/ChatMessageContent或普通对象统一转换为 MCP 内容类型传入prompts列表list[PromptTemplateBase]时server.list_prompts()依据prompt_template_config的 name/description/input_variables 生成types.Promptserver.get_prompt()调用prompt.render(kernel, KernelArguments(...))渲染模板再经ChatHistory.from_rendered_prompt拆分为list[types.PromptMessage]——与映射表描述的转换链路一一对应server.set_logging_level()与_log()实现映射表中的 Logging 职责既写入本地 logger也通过server.request_context.session.send_log_message把日志发给客户端。Agent 即服务器示例 python/samples/concepts/mcp/servers/restaurant_booking_agent_server.py 展示了一条极简路径——agent.as_mcp_server()直接把ChatCompletionAgent含BookingPlugin等插件变成 MCP 服务器再配合 stdio 或 SSE 传输运行agent ChatCompletionAgent( serviceAzureChatCompletion(credentialAzureCliCredential()), nameBooker, instructionsCreate a booking for the user, ..., plugins[BookingPlugin()], ) server agent.as_mcp_server()该脚本支持--transport stdio|sse与--port参数stdio 模式走mcp.server.stdio.stdio_serverSSE 模式用 Starlette SseServerTransport挂载/sse与/messages/路由后由 uvicorn 托管。4.3 .NET 侧落地MCP Client/Server 完整示例.NET 侧的端到端示例位于 dotnet/samples/Demos/ModelContextProtocolClientServer由MCPClient与MCPServer两个项目组成。MCPServer 的装配方式dotnet/samples/Demos/ModelContextProtocolClientServer/MCPServer/Program.cs清晰展示了Kernel/Agent 作为 Server的四种能力暴露// 注册 SK 插件与 SK Agent作为插件 kernelBuilder.Plugins.AddFromTypeDateTimeUtils(); kernelBuilder.Plugins.AddFromTypeWeatherUtils(); kernelBuilder.Plugins.AddFromTypeMailboxUtils(); kernelBuilder.Plugins.AddFromFunctions(Agents, [AgentKernelFunctionFactory.CreateFromAgent(CreateSalesAssistantAgent(chatModelId, apiKey))]); // 注册 MCP 服务器 builder.Services .AddMcpServer() .WithStdioServerTransport() .WithTools() // SK 插件函数 → MCP tools .WithPrompt(PromptDefinition.Create(...)) // SK prompt 模板 → MCP prompts .WithResourceTemplate(CreateVectorStoreSearchResourceTemplate()) // 内核函数 → Resource 模板 .WithResource(ResourceDefinition.CreateBlobResource(...)); // 静态资源 → MCP resources即SK 插件作为 MCP 工具、SK 提示词模板作为 MCP prompts、Kernel Function 作为 MCPReadresource 处理器、Kernel Function 作为 resource template 处理器——四种暴露路径一应俱全。MCPClient 的消费方式MCPClient项目中的Samples目录覆盖了 Host 侧全部场景——MCPToolsSample导入 MCP 工具为 SK 函数并经 Chat Completion 调用、MCPPromptSample用 MCP prompts 作为附加上下文、MCPResourcesSample/MCPResourceTemplatesSample资源与资源模板作为附加上下文、MCPSamplingSample在 human-in-the-loop 场景拦截并处理服务器的采样请求、ChatCompletionAgentWithMCPToolsSample/AzureAIAgentWithMCPToolsSample经 Chat Completion 与 Azure AI Agent 消费 MCP 工具。配置与运行见 dotnet/samples/Demos/ModelContextProtocolClientServer/README.md密钥可用 Secret Manager 或环境变量配置OpenAI:ChatModelId、OpenAI:ApiKey、AzureAI:ConnectionString、AzureAI:ChatModelId在 Visual Studio 中把MCPClient设为启动项目并按 F5 运行所有示例按顺序执行也可在Program.cs的Main中注释掉其余示例单独运行可用npx modelcontextprotocol/inspector dotnet run启动MCP Inspector在 MCPServer 项目目录下随后在浏览器中打开终端输出的 URL 并点击 Connect即可看到工具、提示词与资源清单也可配置 Claude Desktop 的claude_desktop_config.json将command指向MCPServer.exe来接入该服务器。五、边界与未决项ADR 留下的开放问题从两张映射表可以看出集成设计并非全盘映射而是有意识地保留了边界Resources两侧均为 UnclearMCP 的资源概念太通用SK 侧尚未确定统一落点但 .NET 示例已经通过Kernel Function 作为Read处理器 / resource template 处理器的方式给出了实践雏形。RootsHost 侧依赖上下文Server 侧 UnclearHost 侧原则上是把当前上下文的 roots 发给服务器但实际取决于具体插件如 .NET FileIOPluginPython 侧当前未实现。SamplingHost 侧已实现Server 侧 UnclearHost 侧已由sampling_callback完整落地并配套sampling_consent_callback/sampling_auto_approve的安全策略Server 侧因与 SK 自身能力重叠而大概率不需要映射。Completion 与 Progress两侧均 Unmapped字符级自动补全与长任务进度条不属于 SK 必须支持的能力留给基于 SK 构建的客户端自行实现但 Server 侧文档提示若未来支持 Prompt 与 Resources应为其提供 OOTB 的 completion 支持。Logging仅 Server 侧映射为 Built-in loggersPython 服务端已通过set_logging_levelsend_log_message实现Python 客户端插件也内置了logging_callback可将 MCP 服务器的日志消息按LOG_LEVEL_MAPPING转发到本端 loggerdebug→DEBUG、info/notice→INFO、warning→WARNING、error→ERROR、critical/alert/emergency→CRITICAL。这些未决项印证了 ADR 的自我定位——由于 MCP 正在积极开发中本文档需要随新概念的加入与实现变化持续更新。六、总结与实践路线图围绕 docs/decisions/0069-mcp.md 的映射设计Semantic Kernel 仓库已形成两条相互独立又互补的实践路径作为 Host 消费 MCPpip install semantic-kernel[mcp]后用MCPStdioPlugin/MCPSsePlugin/MCPStreamableHttpPlugin/MCPWebsocketPlugin之一连接服务器tools 与 prompts 会被自动装载为内核函数配合FunctionChoiceBehavior.Auto()即可在聊天或 Agent 中通过 function calling 直接调用采样请求则通过sampling_consent_callback/sampling_auto_approve进行安全控制。参考 python/samples/concepts/mcp/mcp_as_plugin.py 与 dotnet/samples/Demos/ModelContextProtocolClientServer/MCPClient。作为 Server 暴露能力create_mcp_server_from_functions/create_mcp_server_from_kernel/agent.as_mcp_server()把 Kernel 或 Agent 的插件函数与 PromptTemplate 发布为 MCP 服务器再经 stdio / SSE 传输托管即可被 MCP Inspector、Claude Desktop 等任意兼容 Host 消费。参考 python/samples/demos/mcp_server 与 dotnet/samples/Demos/ModelContextProtocolClientServer/MCPServer。核心实现均在 python/semantic_kernel/connectors/mcp.py 中且整体标记为experimental实验性 API接口细节可能随 MCP 协议演进而调整——这正是 ADR 强调持续更新的原因。开发者接入时建议同时关注 MCP 协议规范的最新变更与本仓库对应模块的版本更新。【免费下载链接】semantic-kernelIntegrate cutting-edge LLM technology quickly and easily into your apps项目地址: https://gitcode.com/GitHub_Trending/se/semantic-kernel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考