简介
当前的 AI Agent，无论是和各种 Tools（各类业务服务接口）交互，还是和各类 Memory（各类存储服务接口）交互，亦或是和各类 LLMs（各类大语言模型）交互，都是通过 HTTP 协议的，除了 LLM 因为基本都遵循 OpenAI 范式以外，和其他的 Tools 和 Memory 交互都需要逐一了解它们的返回格式进行解析和适配。
MCP 的主要目的是如何让 AI 应用快速而灵活地扩展功能，这里的“扩展”可以是插件、工具或者其它资源。手段是标准化 LLM 应用如何连接到不同的系统。从本质上讲：当你想为一个你不能控制的 agent 引入工具时，MCP 就会派上用场。在 MCP 出现之前，开发者必须编写代码，并通过 API 将 AI 工具与外部系统连接，这意味着每个集成都需要预先编码。MCP 的核心价值在于：让用户为不可控的 Agent 添加工具。例如在使用 Claude Desktop、Cursor 等应用时，普通用户无法修改底层 Agent 的代码，但通过 MCP 协议就能为其扩展新工具。非开发者通过 MCP 定制个性化 Agent 将成为可能。
从LLM的角度看，它标准化了应用程序如何为 LLM 提供上下文。LLM侧是比较清爽简单的，所有“变”和“不一样”的东西都放在这个MCP Server这里，类似于一个适配于LLM的Adapter。在此之上就是各种Agent工具，随着Agent和应用不断复杂，是一定需要单独抽一层这样的Adapter出来的。相对于LLM应用直连外部资源，这里主要多了一个中间层（MCP Server），以及连接这个中间层的（MCP Client），理解了这两个，你就理解了MCP。
商业价值
- 传统的做法其实是xxx+AI，也就是各个业务系统融入一些AI能力；有了MCP，是可以构建AI+xxx，把AI作为新业务的中心，通过将业务系统的api封装后提供MCP接入能力，让各类新业务按需调用，这样就是新的重构了。
- 现在很多事情需要我们通过 APP 自己去操作 UI，比如出去玩要自己通过不同的 APP 找攻略、订机票、记花销等等，将来可能很多事情都可以通过 AI 结合 MCP 串起来，商业公司也有一种可能会演化为纯粹提供信息和数据服务的形态来提供价值，不再依赖 APP 本身了。 与 AI 对话的交互可能是将来统一甚至唯一的入口，出门有手表之类的穿戴设备就可以了，不再强依赖一个像手机一样移动的屏幕。 PS: 不过这些商业价值，主要靠remote mcp server 来推动。
mcp 协议
MCP（Model Context Protocol，模型上下文协议）旨在实现大型语言模型（LLM）与外部数据源和工具的无缝集成，目标是成为 AI 领域的“HTTP 协议”，推动 LLM 应用的标准化和去中心化。
- MCP 遵循 CS 架构（client-server），具体包含的组件如下：
- Host 主机：发起连接 LLM 的应用程序，例如 Claude for Desktop 或其他的 AI 应用。
- MCP Client 客户端：运行在主机里的客户端，与 MCP Server 服务器保持 1:1 连接，负责协议通信。
- MCP Server 服务器：负责向客户端提供 资源、提示 和 工具 的服务器。
- Base Protocol: Core JSON-RPC message types
- Lifecycle Management: Connection initialization, capability negotiation, and session control
-
Server Features: Resources, prompts, and tools exposed by servers
- 资源，表示 MCP 服务器想要向客户端提供的任何类型的数据。包括：文件内容、数据库记录、API 响应、实时系统数据、截图和图片、日志文件等更多内容。每个资源由唯一的 URI 标识，并且可以包含文本或二进制数据。应用可以在交互过程中让模型选择要不要用这些数据，也可以让用户从“资源列表”里手动挑选注入对话。
{ uri: string; // Unique identifier for the resource name: string; // Human-readable name description?: string; // Optional description mimeType?: string; // Optional MIME type } - 提示，是预定义的模板。这是人为触发的提示文本，在编辑器里，可能以
/ 命令或模板形式出现。当用户想使用这个提示时，可以直接注入给模型。{ name: string; // Unique identifier for the prompt description?: string; // Human-readable description arguments?: [ // Optional list of arguments { name: string; // Argument identifier description?: string; // Argument description required?: boolean; // Whether argument is required } ] } - 工具，允许服务器公开可由客户端调用并由 LLM 用来执行操作的可执行函数。工具的关键方面包括：
- 发现 tools/list：客户端可以通过端点列出可用的工具
- 调用：使用端点调用工具 tools/call，服务器执行请求的操作并返回结果
{ name: string; // Unique identifier for the tool description?: string; // Human-readable description inputSchema: { // JSON Schema for the tool's parameters type: "object", properties: { ... } // Tool-specific parameters } }作者：这些原语背后都有各自适用场景。工具是“模型自己想用时随时可调”，资源更像“额外可选上下文”，提示则是“用户显式想插入的预设文本”。我们希望把这些都抽象出来，给应用开发者提供更多可控的用户体验，而不是所有事情都丢给模型自由调用。
- 资源，表示 MCP 服务器想要向客户端提供的任何类型的数据。包括：文件内容、数据库记录、API 响应、实时系统数据、截图和图片、日志文件等更多内容。每个资源由唯一的 URI 标识，并且可以包含文本或二进制数据。应用可以在交互过程中让模型选择要不要用这些数据，也可以让用户从“资源列表”里手动挑选注入对话。
- Client Features: Sampling and root directory lists provided by clients
- Utilities: Cross-cutting concerns like logging and argument completion
作者：很多人会问，MCP 和 OpenAPI 对比如何？或者说它们会不会冲突？OpenAPI 在传统 RESTful 领域很成熟，但如果你想针对 AI 场景，构建那种可多轮调用、可调取不同数据上下文的扩展，OpenAPI 可能太细粒度了。它并没有“提示”“资源”“工具”的高级抽象。我们更希望为 AI 应用提供专门的协议能力。
协议层/消息格式
MCP 协议使用 JSON-RPC 2.0 作为消息传输格式，JSON-RPC 2.0是一种轻量级的、用于远程过程调用（RPC）的消息交换协议，使用JSON作为数据格式。注意：它不是一个底层通信协议，只是一个应用层的消息格式标准。形象的说，就像两个人需要交换包裹，它规定了包裹应该如何打包、内部如何分区、如何贴标签等，但它不规定包裹如何运送。包含以下三种类型的 JSON-RPC 消息：
- Request 请求：
{ "jsonrpc": "2.0", "id": 1, // 请求 ID（数字或字符串） "method": "string", // 方法名 "params": {} // 可选，参数对象 } 比如 { "jsonrpc": "2.0", // 协议版本，固定为 "2.0" "method": "calculate", // 要调用的方法名 "params": { // 方法参数，可以是对象或数组 "expression": "5+3" }, "id": 1 // 请求标识符，用于匹配响应 } - Response 响应：
{ "jsonrpc": "2.0", "id": 1, // 对应请求的 ID "result": {}, // 可选，成功结果 "error": { // 可选，错误信息 "code": 123, "message": "错误描述", "data": {} // 可选，附加数据 } } 比如 { "jsonrpc": "2.0", // 协议版本 "result": 8, // 调用结果 "id": 1 // 对应请求的标识符 } - Notification通知（单向，无需响应）：
{ "jsonrpc": "2.0", "method": "string", // 通知方法名 "params": {} // 可选，参数对象 }
传输层/传输方式
深入MCP Remote模式：两大基础协议及工作原理，一步步教你弄懂规定了消息的标准，再选择一种传输方式。MCP 协议内置了两种标准传输方式：标准输入/输出（stdio) 和 Server-Sent Events(SSE) 。所有传输均采用JSON-RPC 2.0进行消息交换。
- stdio 传输通过 标准输入输出流 实现客户端与服务器之间的通信，适用于本地集成与命令行工具。
- 客户端 (Cline) 将 MCP 服务器作为子进程启动
- 通信通过进程流进行：客户端写入服务器的 STDIN，服务器通过 STDOUT 响应
- 每条消息以换行符分隔
-
SSE，通过 HTTP 协议实现服务器到客户端的实时单向数据推送，结合 HTTP POST 用于客户端到服务器的消息发送。client 与server 运行在不同的node上。
- 建立连接：客户端首先请求建立 SSE 连接（
/sse），服务端“同意”，然后生成并推送唯一的Session ID。 - 请求发送：客户端通过 HTTP POST (
/messages) 发送 JSON-RPC2.0 请求（请求中会带有Session ID 和Request ID信息）。 - 请求接收确认：服务端接收请求后立即返回 202 (Accepted) 状态码，表示已接受请求。
- 异步处理：服务端应用框架会自动处理请求，根据请求中的参数，决定调用某个工具或资源。
- 结果推送：处理完成后，服务端通过 SSE 通道推送 JSON-RPC2.0 响应，其中带有对应的Request ID。
- 结果匹配：客户端的SSE连接侦听接收到数据流后，会根据Request ID 将接收到的响应与之前的请求匹配。
- 重复处理：循环2-6这个过程。这里面包含一个MCP的初始化过程。
- 连接断开：在客户端完成所有请求后，可以选择断开SSE连接，会话结束。
- 建立连接：客户端首先请求建立 SSE 连接（
- Streamble HTTP：通过 HTTP 进行通信，支持流式传输。（协议版本 2025-03-26 开始支持，用于替代 SSE）
其它
- 连接管理：SSE 连接是单向的（服务器到客户端），通常通过定期发送心跳消息（keep-alive）保持活跃。如果连接断开，客户端可以重新发起 SSE 请求重建连接。
- 数据格式。SSE 消息遵循
event:\ndata:\n\n的格式。 MCP 使用 JSON-RPC 2.0 协议封装消息，确保请求和响应的结构化处理
现在，你应该可以理解，如果使用官方的低层SDK来开发MCP Server，为什么Server启动代码大概长这样：
mcp = FastMCP("example")
mcp_server = mcp._mcp_server # noqa: WPS437
app = SseServerTransport("/messages/")
async def handle_sse(request: Request) -> None:
async with app.connect_sse(request.scope,request.receive, request._send, ) as (read_stream, write_stream):
await mcp_server.run(
read_stream,
write_stream,
mcp_server.create_initialization_options(),
)
starlette_app = Starlette(
debug=True,
routes=[
Route("/sse", endpoint=handle_sse),
Mount("/messages/", app=sse.handle_post_message),
],
)
为什么需要SSE？单一的HTTP Post方式存在的不足
- 单一的请求/响应模式下，客户端必须等待服务端处理完成，这适合快速响应的API，但不擅长应对长时间运行的任务。
- 无法服务端推送：缺乏双向通信的能力。正如上面的场景，如果你的MCP Server运行一个长时间的任务，你可能需要定期的向客户端报告处理进度或者中间结果，而简单HTTP Post无法做到。
- 短连接：无法应对对话式会话的需求。在实际应用场景中，你的客户端AI应用可能会在一次会话中多次频繁地与MCP Server对话，来访问其中的资源或工具。这种对话式的交互需要保持会话状态和连接，这需要建立长连接的会话。
- 流式输出的需求。AI Agent的应用场景中，有时候也需要工具调用做流式的输出，这也需要MCP Server的支持。
由于SSE是一种单向通信的模式，所以它需要配合HTTP Post来实现客户端与服务端的双向通信。严格的说，这是一种HTTP Post（客户端->服务端） + HTTP SSE（服务端->客户端）的伪双工通信模式。一个HTTP Post通道， 一个HTTP SSE通道，两个通道通过session_id来关联，而请求与响应则通过消息中的id来对应。
详解 MCP 传输机制 未细读。
持续演进中
尽管HTTP with SSE的模式带来了很多优点，但也缺点
- 不支持可恢复性（Resumability），连接断开后，客户端必须重新开始整个会话。
- 服务器需要维持长期连接（High Availability Requirement）：服务器必须保持高可用性，以支持持续的 SSE 连接。
- SSE 仅支持服务器 → 客户端消息，无法灵活进行双向通信。
所以在最新的MCP标准（2025-03-26版）中，对目前的传输方式做了调整，改名为Streamable HTTP。其主要变动在于允许在MCP Server端根据自身需要来选择：你可以选择简单的无状态模式，也可以按需选择支持目前的HTTP with SSE模式。这给予了开发者更大的选择权，具体包括：
- 移除了专门的
/sse端点，所有通信都通过单一/message端点进行。 - 任何 HTTP POST 请求都可被服务器按需升级为 SSE 流（不再强制）；客户端也可通过GET 请求初始化 SSE 流（目前模式）。简单来说，原来的 MCP 传输方式就像是你和客服通话时必须一直保持在线（SSE 需要长连接），而新的方式更像是你随时可以发消息，然后等回复（普通 HTTP 请求，但可以流式传输）。
- 服务器支持完全无状态部署。 Streamable HTTP 意味着任何请求方（甚至就是一段简单的 HTTP Request 代码），都可以像请求标准 HTTP API 的方式一样和 MCP Server 交互。换句话说，当可以使用标准 HTTP API 的方式和 MCP Server 交互后，是不是就不存在所谓的 MCP Client了？
mcp server
MCP 也是一种 API。MCP 服务器本质是通过 MCP 协议提供标准化接口的服务端（PS：将其它所有api封装为mcp对外提供）。会将其功能公开为具有语义描述的“工具”。每个工具都是自我描述的，并包含有关工具功能、每个参数的含义、预期输出以及约束和限制的信息。假设你更改了服务器中某个工具所需的参数数量。使用 MCP，你不会破坏使用服务器的任何客户端。PS: 与api区别是多了一个 description 字段。这个字段是用来描述这个 API 的功能，以及如何使用的。以让其它 AI Agent 能够更好地调用。
MCP Server有哪些“服务”？
- Tools：提供给LLM应用特别是Agent使用的工具。
- Resoures：提供给LLM应用一些额外的结构化数据。资源通常提供数据，而不是执行动作，与工具不同。
- Prompts：提供给LLM应用的一些Prompt模板。比如你的应用是一个Chatbot，可以从MCP Server中取出这些模板，让使用者选择使用。
MCP Server如何启动？
- 本地模式下，在LLM应用中配置启动命令后，会自动启动MCP Server
- 不同的MCP Server可能有不同的启动命令，注意查看MCP Server说明书
- 有的MCP Server需要先安装依赖；有的通过npx/uvx运行的MCP server，则会自动下载缓存并临时运行。
本地模式
本地模式下MCP Server可以部署在LLM应用本机，Client与Server是一对一的关系。如果需要连接多个MCP Server，需要自行维护多个Session。client 在本地运行 server 服务作为子进程，通过标准输入/输出建立通信，使用 JSON-RPC 2.0 消息格式。PS： 都启动subprocess 不一对一也不行了。
- 在LLM应用中配置启动命令后，会自动启动MCP Server，MCP Server启动后的物理形式是一个独立的进程。
- MCP Server与客户端应用间通过stdio/stdout（标准输入输出）的进程间通信进行消息交换。这种方式你肯定见过，比如：
cat file.txt | grep "error" | sort > result.txt，还有类似k8s的cni 插件 - 服务器再连接到互联网上的各种API和服务。
Local MCP Server虽然简单易用，但在企业级应用中面临诸多挑战：
- 本地环境依赖，对用户本地环境有依赖，比如需要安装 python或docker 等执行环境来运行MCP Server，对非技术用户不友好
- 安全风险，企业不可能将敏感数据库凭证、API密钥或其他关键访问令牌配置给每个员工的本地环境。这不仅违反最小权限原则，还大大增加了凭证泄露的风险。
- 一致性问题，当多个用户需要访问相同的企业资源时，难以保证配置和权限的一致性，容易导致数据不一致或权限混乱。
- 维护成本，为每个用户设备部署和维护MCP Server需要大量IT资源，版本更新、安全补丁和配置变更都需要在每台设备上单独执行。
remote模式
Remote MCP Server则是部署在云端的MCP服务器，供多个 client 调用，用户可以通过互联网访问。在这种模式下，MCP客户端可以是更广泛的网页应用或移动应用，它们通过HTTP协议与远程MCP服务器通信。Remote MCP Server通常集成了认证授权、状态管理、数据库访问等企业级功能，能够为多用户提供服务。
mcp网关（未完成）
- 现存的传统业务能快速转成 MCP Server 吗？能 0 代码改动的转换吗？前文说的mcp server 都是基于各语言的 MCP SDK 开发的程序或服务。有没有更自动化一点的？
- MCP Server 会很多，如何统一管理？有自己开发的 MCP Server，有三方的 MCP Server，还有大量通过某种神秘机制将传统业务转换而来的 MCP Server。这些都应该有一个类似 MCP Hub 或 MCP 市场的东西统一管理起来，方便 MCP Client 去使用。
- 企业级 AI 应用中，身份认证、数据权限、安全这些如何做？在企业级的应用中，无论哪种协议，哪种架构，哪种业务。身份认证、数据权限、安全防护这些问题都是永远绕不开的。那么在 MCP 这种协同方式下如何实现。这里有两个层面的权限管控：
- Client 有权使用哪些 MCP Server。有权使用某 MCP Server 里的哪些 MCP Tool。
- Client 通过 MCP Tool 有权获取到哪些数据。
对客户端的影响
- mcp tool的描述会加入到 选择tool的llm 的system prompt中，这个system prompt安全性如何保证？针对MCP的常见攻击手法
- 系统提示词写的不好，如何方便的快速调试？能不能实时生效？
- 如果 MCP Server 很多，那么系统提示词会非常长，岂不是很消耗 Token？如何缩小或精确 MCP Server 和 MCP Tool 的范围？
网关最擅长做的事情就是协议转换，在 API Registry 中新增[Server Name]-mcp-tools.json 命名规范的配置文件，在配置文件中使用 MCP 规范对现存业务的接口进行描述。通过云原生 API 网关（MCP 网关），MCP Client 侧自动发现由传统服务转换来的 MCP Server。云原生 API 网关作为 MCP 网关，可以通过插件机制，改写或增加 Request Header 的值，将 Header 的值透传下去，然后在服务内部进一步做数据权限管控。
mcp client
当一段代码，一个 Agent，一个客户端，基于 MCP 的规范去使用、去调用 MCP Server 里的 MCP Tool 时，它就是 MCP Client。
从代码上讲，MCP Client是由客户端LLM app使用Client SDK创建并维护的一个Server会话，就像你在程序中维护一个数据库的Connection一样。一般长这样：
server_params = StdioServerParameters(
command="python",
args=["./test_mcp_server.py"],
env=None
)
async with stdio_client(server_params) as (read, write):
async with ClientSession(read, write, sampling_callback=None) as session:
await session.initialize()
# 查看Server的Tools
tools = await session.list_tools()
# 接下来拿着tools 构造openai chat api
...
# 根据llm的结果调用工具
result = await session.call_tool("calculate", {"expression": "188*23-34"})
print(result.content)
langchain 或llamaindex 稍微包了一下，输入 StdioServerParameters 输出client，client 与自家的Tool定义无法集成。此外，还提供 MultiServerMCPClient来封装多个 mcp server。
mcp_client = MultiServerMCPClient(
{
"tavily": {
"command": "npx",
"args": ["-y", "@mcptools/mcp-tavily"],
"env": {**os.environ} # 传递环境变量给MCP工具
}
}
)
async with mcp_client ) as client:
# 创建ReAct风格的agent
agent = create_react_agent(model, client.get_tools())
对于openai-python-agent 来说，直接支持mcp概念，所以跟更自然一点。
async def main():
# 1. 创建MCP Server实例
search_server = MCPServerStdio(
params={
"command": "npx",
"args": ["-y", "@mcptools/mcp-tavily"],
"env": {**os.environ}
}
)
await search_server.connect()
# 2. 创建Agent并集成MCP Server
agent = Agent(
name="助手Agent",
instructions="你是一个具有网页搜索能力的助手，必要时使用搜索工具获取信息。",
mcp_servers=[search_server], # 将MCP Server列表传入Agent
)
源码分析
FastMCP是在低层MCP SDK上封装的简易框架，隐藏了细节。这块等有需求时得进一步深入源码学习。
mcp server示例
from mcp.server.fastmcp import FastMCP
# 初始化了一个 MCP 服务器对象，后续的功能将基于这个对象注册和运行
mcp = FastMCP("演示")
# 将 add 函数注册为 MCP 服务器的一个“工具”（Tool）
@mcp.tool()
def add(a:int, b:int)-> int:
"""
Adds two numbers.
"""
return a + b
# 定义一个资源函数 get_greeting
@mcp.resource("greeting://{name}")
def get_greeting(name:str)-> str:
"""
Returns a greeting message.
"""
return f"Hello, {name}!"
if __name__ == "__main__":
# transport='stdio': 指定通信方式为标准输入输出（stdio）。这意味着服务器通过命令行（终端）的输入和输出与客户端通信，而不是通过网络（如 HTTP 或 WebSocket）。
mcp.run(transport='stdio') # 调用 FastMCP 实例的 run 方法，开始运行服务器mcp server自身实现
100行代码讲透MCP原理python 原生简单实现
from fastapi import FastAPI, Request
import uuid
from sse_starlette.sse import EventSourceResponse
from pydantic import BaseModel
import json
app = FastAPI()
mcpHub = {}
class McpRequest(BaseModel):
id: Optional[int] = None
jsonrpc: str
method: str
params: Optional[dict] = None
class MCPServer:
def __init__(self):
self.queue = asyncio.Queue()
async def reader(self):
while True:
event = await self.queue.get()
yield event
async def request(self, payload: McpRequest):
if payload.method == "initialize":
await self.queue.put({"event": "message", "data": ..})
elif payload.method == "tools/list": # 对应client_session.list_tools？
...
@app.get("/sse")
async def sse():
client_id = str(uuid.uuid4())
mcp = MCPServer()
mcpHub[client_id] = mcp
await mcp.queue.put({"event": "endpoint", "data": f"/message?client_id={client_id}"})
return EventSourceResponse(mcp.reader())
@app.post("/message")
async def message(request: Request, payload: McpRequest):
client_id = request.query_params.get("client_id")
if client_id not in mcpHub:
return "no client"
await mcpHub[client_id].request(payload)
return "ok"
完整实现 PS： 实现mcp gateway 可以参考。
from fastapi import FastAPI, Request
from sse_starlette.sse import EventSourceResponse
import asyncio
import json
import uuid
from pydantic import BaseModel
from typing import Optional
import uvicorn
import inspect
app = FastAPI()
mcpHub = {}
class McpRequest(BaseModel):
id: Optional[int] = None
jsonrpc: str
method: str
params: Optional[dict] = None
class MCPServer:
def __init__(self, name, message_path, tools):
self.queue = asyncio.Queue()
self.client_id = str(uuid.uuid4())
self.message_path = message_path
self.info = {
"protocolVersion": "2024-11-05",
"capabilities": {
"experimental": {},
"tools": {
"listChanged": False
}
},
"serverInfo": {
"name": name,
"version": "1.6.0"
}
}
self.tools = tools
def list_tool(self):
result = []
for tool in self.tools:
toolInfo = {
"name": tool.__name__,
"description": tool.__doc__,
"inputSchema": {"type": "object","properties":{}},
}
for name, param in inspect.signature(tool).parameters.items():
toolInfo["inputSchema"]["properties"][name] = {
"title": name,
"type": "string",
}
result.append(toolInfo)
return result
async def reader(self):
while True:
event = await self.queue.get()
yield event
@staticmethod
def response(result, id):
message = {
"jsonrpc": "2.0",
"result": result,
}
if id is not None:
message["id"] = id
return json.dumps(message)
async def request(self, req: McpRequest):
if req.method == "initialize":
await self.queue.put({"event": "message", "data": self.response(self.info, req.id)})
elif req.method == "tools/list":
await self.queue.put({"event": "message", "data": self.response({"tools": self.list_tool()}, req.id)})
elif req.method == "tools/call":
for tool in self.tools:
if tool.__name__ == req.params.get("name"):
result = await tool(**req.params["arguments"])
await self.queue.put({"event": "message", "data": self.response({"content": result, "isError": False}, req.id)})
break
async def test(state=None):
"""
description
"""
result = f"hi {state}"
await asyncio.sleep(1)
result += "!"
return result
@app.get("/receive_test")
async def receive_test():
mcp = MCPServer(name="mcp-test",message_path="/send_test", tools=[test])
mcpHub[mcp.client_id] = mcp
await mcp.queue.put({"event": "endpoint", "data": f"{mcp.message_path}?client_id={mcp.client_id}"})
return EventSourceResponse(mcp.reader())
@app.post("/send_test")
async def send_test(request: Request, payload: McpRequest):
client_id = request.query_params.get("client_id")
if client_id not in mcpHub:
return "no client"
await mcpHub[client_id].request(payload)
return "ok"
if __name__ == "__main__":
uvicorn.run(app, host="0.0.0.0", port=8001)
其它
8种主流Agent框架与MCP的集成 思路两种
- 原生支持mcp，当然底层还是tool
- 将mcp 视为tool
一些比较有意思的mcp 在 Kubernetes 和 AI 之间搭一座桥：MCP-K8s
Related Issues not found
Please contact @qiankunli to initialize the comment