Model Context Protocol Python SDK 故障排查全指南逐条解析官方错误信息与一键修复方案【免费下载链接】python-sdkThe official Python SDK for Model Context Protocol servers and clients项目地址: https://gitcode.com/gh_mirrors/pythonsd/python-sdk本文是 MCPModel Context ProtocolPython SDK 官方故障排查手册的中文深度解读。页面上的每一个标题都对应 SDK 真实会抛出的某条错误信息原文每条错误下方给出了它的成因与一步修复方案。你可以用浏览器页内查找定位自己 traceback或服务器日志的最后一行直接阅读对应条目。本文以 i18n/ru/pages/troubleshooting.md与英文原版 docs/troubleshooting.md 同源为骨架并结合仓库源码验证每条错误的真实出处与修复路径。读完你就能独立诊断客户端上下文管理器使用错误、工具执行失败、装饰器误用、工具重名、Host 校验拦截、ASGI 挂载生命周期问题、会话丢失、协议代际不匹配、elicitation 无回程通道以及 requestState 令牌失效等十余类高频故障。复现环境本文所有错误都来自这个服务器本文多条错误条目共享同一个演示服务器一个工具加一个模板化资源两者都会对不认识的天气城市抛出异常。源码见 docs_src/troubleshooting/tutorial001.pyfrom mcp.server import MCPServer from mcp.server.mcpserver.exceptions import ResourceNotFoundError, ToolError mcp MCPServer(Weather) FORECASTS {London: Rain., Cairo: Sun.} mcp.tool() def forecast(city: str) - str: Todays forecast for one city. if city not in FORECASTS: raise ToolError(fNo forecast for {city!r}.) return FORECASTS[city] mcp.resource(weather://{city}) def report(city: str) - str: The full report for one city. if city not in FORECASTS: raise ResourceNotFoundError(fNo forecast for {city!r}.) return f{city}: {FORECASTS[city]}涉及该服务器的条目都通过http://localhost:8000/mcp访问它所以请让它在 HTTP 上保持运行uv run mcp run server.py --transport streamable-http需要强调一点本文引用的每条错误都是真实存在的——SDK 自带的测试套件逐一复现过它们。也就是说你在下面看到的每一段报错文本都可以在仓库的 tests 目录与 docs_src/troubleshooting 中找到对应的复现用例。ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)这不是MCP 错误而是 anyio 的噪音你真正的错误是粘贴内容里的最后一行。Client.__aenter__会启动一个任务组task group。anyio 会把任何离开任务组的异常都包装进ExceptionGroup因此任何从async with Client(...)块里逃逸出去的异常——无论它是什么——到达外层时都会披着这样一层壳async def main() - None: async with Client(http://localhost:8000/mcp) as client: await client.read_resource(weather://Atlantis) Exception Group Traceback (most recent call last): | ... | ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception) ----------------- 1 ---------------- | Exception Group Traceback (most recent call last): | ... | ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception) ----------------- 1 ---------------- | Traceback (most recent call last): | ... | mcp.shared.exceptions.MCPError: No forecast for Atlantis. ------------------------------------面对这种输出做两件事从下往上读。MCPError: No forecast for Atlantis.才是真正的故障在本页搜索它的文本而不是ExceptionGroup这一行。在块内捕获。ExceptionGroup只在异常逃出async with时才出现。如果在块内捕获同样的故障就是一个普通的MCPError完全没有包裹层async def main() - None: async with Client(http://localhost:8000/mcp) as client: try: await client.read_resource(weather://Atlantis) except MCPError as e: print(e) # No forecast for Atlantis.[!TIP] 发生在连接阶段的故障错误的 URL、服务器没启动、下文会讲到的421会直接从async with本身逃逸根本没有块内可以捕获。对这类故障请读 ExceptionGroup 的底部。RuntimeError: Client must be used within an async context managerClient(...)只是构造了一个对象。在进入async with之前什么连接都不会建立所以每个方法都会拒绝执行async def main() - None: client Client(http://localhost:8000/mcp) tools await client.list_tools() # RuntimeError进入上下文管理器即可。__aenter__就是连接动作async def main() - None: async with Client(http://localhost:8000/mcp) as client: tools await client.list_tools()__aexit__就是断开连接这也正是为什么 SDK 没有client.close()需要你去记得调用。官方 docs/get-started/testing.md 中的测试模板正是建立在这个模式之上。Error executing tool name: message、Error executing tool name与Unknown tool: name你看到的是结果result而不是异常。call_tool对于执行失败的工具有不会抛出异常——永远不会。对服务器不认识的城市调用forecast工具抛出的ToolError会随请求一起返回而请求本身被标记为成功result.is_error # True result.content # [TextContent(textError executing tool forecast: No forecast for Atlantis.)] result.structured_content # NoneUnknown tool: get_forecast是同一形态的错误只是针对服务器从未注册过的工具名参数错误也会以同样方式被拒绝——在工具输入 schema 层面、你的函数体真正运行之前就被拦截。修复手段在客户端一侧检查result.is_error。在call_tool外面包一层try/except捕获不到任何上述错误因为根本没有异常可捕获。这是有意设计也是本页最值得内化的一句话模型发起了这次调用所以由模型收到错误消息并有机会重试。完整的故事包括真的会抛异常的MCPError路径见 docs/servers/handling-errors.md。不带消息的简写形式Error executing tool name意味着工具崩溃了它没有预料到的异常逃逸了出来或者返回值没有通过输出 schema 校验并且该异常的文本不会被放进线上数据里。traceback 在服务器日志的ERROR级别形如Tool name raised an unexpected exception。TypeError: The tool decorator was used incorrectly. Did you forget to call it? Use tool() instead of tool你写的是mcp.tool而不是mcp.tool()。tool()是一个装饰器工厂不加括号时Python 会把你的函数直接当作它的name参数传进去。mcp.tool # - missing () def forecast(city: str) - str: Todays forecast for one city. return f{city}: Rain.TypeError: The tool decorator was used incorrectly. Did you forget to call it? Use tool() instead of tool加上括号即可。mcp.resource(...)和mcp.prompt()在同样的笔误下也会给出相同的提示。[!NOTE] 这个异常在模块被导入时就会抛出早于任何客户端连接。所以如果宿主host把你的服务器显示为启动失败或已断开而不是已连接但有零个工具那多半就是这种情况自己运行python server.py读一下 traceback。类型检查器也能抓住它——函数不是name的合法值。Tool already exists: name两次注册使用了同一个工具名。先注册的生效后注册的被静默丢弃服务器日志里的这条警告是唯一的信号--8-- docs_src/troubleshooting/tutorial002.pytools/list只会报告一个forecast而且它是forecast_today。重命名其中一个即可。MCPServer(..., warn_on_duplicate_toolsFalse)只能让警告闭嘴、不改变结果所以请保持它开启。资源resource和提示词prompt遵循同样的规则、打印同样的日志行Resource already exists:、Prompt already exists:。从源码看该行为由 src/mcp/server/mcpserver/tools/tool_manager.py 的ToolManager实现构造时若warn_on_duplicate_tools为真且同名工具已存在便只记警告、不再追加warn_on_duplicate_tools默认值True定义于 src/mcp/server/mcpserver/server.py。我的宿主列出了零个工具这条没有对应的错误字符串——这正是它难搜的原因。SDK 绝不会把已注册的工具从tools/list里悄悄丢掉所以请由内向外排查服务器到底启动了没有mcp.tool不加括号会在导入期抛异常而一个崩溃的服务器在某些宿主眼里跟空服务器几乎一样。自己运行python server.py看结果。工具是否注册在宿主实际运行的那个mcp上另一个模块里的第二个MCPServer(...)是另一个空的服务器。检查宿主命令真正 import 的是哪个对象。是否有两个工具重名了那样其中一个就消失了。去服务器日志里搜Tool already exists:。宿主的列表是不是过期了启动后才添加的工具只会到达那些处理notifications/tools/list_changed通知的客户端。粗暴但有效的办法是重启宿主。是不是有东西写到了重定向窗口之外的stdout服务期间SDK 会把已 flush 的游离 stdout 输出改道到 stderr尽力而为如果运行环境替换了标准流则原样放行。但更早 flush 到 stdout 的输出包装脚本的 echo、非缓冲进程里 import 期的print()或解释器退出时排空的缓冲print()会落到协议流上一条垃圾行就可能让宿主断开连接而某些宿主把这种连接渲染成服务器里什么都没有。请改用logging模块记录日志。宿主侧的其余检查清单见 docs/get-started/real-host.md。另外明确一点非法的工具名不在上述清单里不合规的名字只会记一条警告日志工具照常注册、照常出现在列表里。MCPError: Server returned an error response服务器直接拒绝了 HTTP 请求且响应体不是 JSON-RPC所以 Python 的Client只能给你这个占位符式的提示。最常见的成因远超其他原因是刚部署的 Streamable HTTP 服务器。streamable_http_app()以及mcp.run(streamable-http)在未传transport_security时默认开启防 DNS-rebinding 保护只接受Host头为 localhost 的请求。这在笔记本本地开发时是正确的默认值但在真实主机名后面就是错误配置--8-- docs_src/troubleshooting/tutorial003.py把这段代码部署出去、让客户端指向它连接会在握手阶段失败async with Client(https://mcp.example.com/mcp) as client: ...mcp.shared.exceptions.MCPError: Server returned an error response服务器实际发送的421和Invalid Host header永远到不了你这边421 的响应体没有Content-Type: application/json客户端无法解析它。这些信息在服务器日志里下一步就该去看那里WARNING mcp.server.transport_security: Invalid Host header: mcp.example.com修复方式是transport_security。把你真正服务的那个主机名加入白名单--8-- docs_src/troubleshooting/tutorial004.py[!CHECK] 这就完成了全部改动。完全相同的客户端现在可以连上协商出2026-07-28协议并成功调用forecast。源码佐证TransportSecuritySettings定义于 src/mcp/server/transport_security.py其中enable_dns_rebinding_protection默认值为Trueallowed_hosts与allowed_origins默认空列表当配置了保护但请求 Host 不在白名单内时即拒绝请求同文件第 57 行附近的匹配逻辑。docs/run/deploy.md 解释了每个字段的含义、反向代理场景以及部署时会改变的其他一切。紧接着的421 Misdirected Request/Invalid Host header就是从另一侧看到的同一个故障。421 Misdirected Request/Invalid Host header这是从 PythonClient以外的任何视角看到的Server returned an error responsecurl、浏览器的网络面板、反向代理的访问日志或者其他语言的 SDK。curl -i https://mcp.example.com/mcp \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -d {jsonrpc:2.0,id:1,method:initialize,params:{protocolVersion:2025-06-18,capabilities:{},clientInfo:{name:curl,version:1}}}HTTP/1.1 421 Misdirected Request Invalid Host header421 Misdirected Request是 HTTP 协议为这个状态码自带的原因短语Invalid Host header是 SDK 的响应体而 PythonClient把同一事件渲染成Server returned an error response。三者是同一个拒绝。校验针对的是请求携带的Host头而不是服务器绑定的地址——因此转发公共主机名的反向代理和直连客户端一样会撞上这道检查。修复方式与Server returned an error response一节展示的相同transport_securityTransportSecuritySettings(allowed_hosts[...], allowed_origins[...])。有两个边界点值得点名allowed_hosts的每个条目都是精确字符串。mcp.example.com匹配不带端口的裸Host头mcp.example.com:*匹配任何显式携带的端口。两个都要列。响应403、体为Invalid Origin header的是针对Origin头的姊妹检查。它只对浏览器生效没有别的东西会发送Originallowed_origins就是它的白名单。完整的展开包括什么时候关掉这项检查才是诚实的配置见 docs/run/deploy.md。RuntimeError: Task group is not initialized. Make sure to use run().你的 MCP 应用被挂载到了另一个 ASGI 应用内部而没有任何东西启动它的会话管理器session manager。mcp.streamable_http_app()返回一个 Starlette 应用它自己的生命周期lifespan会启动会话管理器uvicorn server:app会替你执行这个生命周期。但 Starlette从不会运行被挂载子应用的生命周期所以一旦应用进入Mount管理器就永远不会启动第一个请求就会炸掉--8-- docs_src/troubleshooting/tutorial005.py服务器能启动。路由能解析。然后uvicorn对每个请求都打印ERROR: Exception in ASGI application Traceback (most recent call last): ... RuntimeError: Task group is not initialized. Make sure to use run().客户端看到的是 500。修复方式是在宿主应用上加一个生命周期进入mcp.session_manager.run()asynccontextmanager async def lifespan(app: Starlette) - AsyncIterator[None]: async with mcp.session_manager.run(): yield app Starlette(routes[Mount(/, appmcp.streamable_http_app())], lifespanlifespan)这一主题的完整讲解包括在一个应用里挂多个服务器、以及 FastAPI 集成见 docs/run/asgi.md。同一类别的两个相邻字符串StreamableHTTPSessionManager .run() can only be called once per instance. Create a new instance if you need to run again.—— 管理器是一次性的同一个应用的生命周期进入两次就会撞上它。mcp.session_manager只有在streamable_http_app()被调用之后才存在。所以先构建路由只在生命周期内部接触管理器。MCPError: Session not found服务器不认识客户端发送的Mcp-Session-Id。要么是服务器重启过或者请求被路由到了另一个实例要么是会话过期了——在session_idle_timeout默认 30 分钟内没有任何在途请求。参见 docs/run/legacy-clients.md#session-lifetime-and-limits。会话只存活在那一进程的内存里。不需要去服务器里找 bug。HTTP 响应是404其响应体就是JSON-RPC所以与上面的421不同PythonClient会把这条错误原样展示给你{jsonrpc: 2.0, id: null, error: {code: -32600, message: Session not found}}修复方式就是重连退出async with Client(...)块进入一个新的块协商一条全新会话。对于长生命周期客户端这意味着在调用周围捕获MCPError见到这条消息就重连而不是在一条死会话里反复重试。如果它没有伴随重启、客户端也没有沉默那么久就发生了说明你跑了不止一个 worker 且没有粘性会话sticky sessions每个 worker 持有自己的会话表被路由到错误 worker 的请求就会落在这里。docs/run/deploy.md 与 docs/run/legacy-clients.md 完整讲述了这段故事及其两个解法粘性路由或stateless_httpTrue。对服务器运维者来说对应的日志行是Rejected request with unknown or expired session ID: id。它以INFO级别记录所以在通常的WARNING阈值下是看不见的。部署后立刻看到成批出现是正常的——所有已连接客户端都在重连。若是会话过期则该行之前会先出现Session id idle timeout同样是INFO级别。MCPError: Method not found某一方发送了另一方没有处理器的 JSON-RPC 请求e.error.data会指出方法名。常见成因是代际era不匹配一个方法只在某一协议修订版中存在、另一修订版中没有却发给了处于错误代际的对端——例如2025代的resources/subscribe到达一条2026-07-28连接或者只有2026才有的subscriptions/listen被一个钉死在modelegacy的客户端发出。哪一方在说什么协议的地图见 docs/protocol-versions.md另一个诚实的成因你从未为某个可选能力注册处理器见 docs/servers/completions.md。有一件事不会产生这条错误尽管它也是一个现代协议已经移除的请求在2026-07-28连接上工具调用ctx.elicit()。服务器会拒绝发送这个请求所以你得到的会是本页下文的Cannot send elicitation/create: ...。MCPError: Client did not declare the form elicitation capability required by resolver name服务器想向用户询问某件事而这个客户端从未声明过你可以问我。这家 Bistro 在预订前通过一个 resolver 提问--8-- docs_src/troubleshooting/tutorial007.py用它替换 Weather 服务器然后从一个没有传elicitation_callback的客户端调用book_table。resolver 会提前拒绝——因为连接的客户端从未声明表单式 elicitation表单引导询问能力——e.error.data精确指出了缺失的东西{ code: -32021, message: Client did not declare the form elicitation capability required by resolver server:ask_to_confirm, data: {requiredCapabilities: {elicitation: {form: {}}}} }给Client(...)传入elicitation_callback。注册回调本身就是能力声明没有第二个开关async def main() - None: async with Client(http://localhost:8000/mcp, elicitation_callbackhandle_elicitation) as client: result await client.call_tool(book_table, {date: Friday})docs/client/callbacks.md 列出了其余回调sampling_callback、list_roots_callback每个都以同样的方式充当能力声明。[!INFO]-32021即MISSING_REQUIRED_CLIENT_CAPABILITY是 2026-07-28 规范新增的三个错误码之一。它们都不是异常类全部以MCPError形式到达需要看的是e.error.code。常量由mcp.types导出。另外两个是-32020HEADER_MISMATCHHTTP 头与它所伴随的请求体不一致和-32022UNSUPPORTED_PROTOCOL_VERSION请求指名了一个本服务器不讲的协议版本。合规的 SDK 客户端无法产生其中任何一个所以如果你见到了请去查你客户端与服务器之间重写请求的那一层。MCPError: Elicitation not supported与Client did not declare the form elicitation capability ...是同一个缺口只是由那些不做前置检查的路径报出来服务器需要一个 elicitation 的答复而连接的客户端没有注册elicitation_callback。你会从两条路径看到它老代际连接上的ctx.elicit()以及任何连接上、一个返回的多轮multi-round-trip问题见 docs/handlers/multi-round-trip.md到达了一个没有回调能应答它的客户端。修复方式相同给Client(...)传elicitation_callback。不存在用户没被问到这种让工具收到decline的版本问不了人的客户端就是一次失败的调用所以设计工具时要为此留有余地。MCPError: Cannot send elicitation/create: this transport context has no back-channel for server-initiated requests.你的处理器在请求中途试图触达客户端而这条连接上的调用没有能承载服务器→客户端请求的通道。有三种服务器配置会把调用置于这种境地。2026-07-28连接任何传输、任何时刻。现代协议压根没有服务器发起的请求所以服务器在任何东西被发送之前就拒绝了。工具内部的ctx.elicit()是与它相遇的经典方式——通常是在该工具第一个内存中的测试里因为Client(mcp)会在没人要求的情况下协商出2026-07-28。传elicitation_callback毫无改变请求根本到不了客户端它无答可回--8-- docs_src/troubleshooting/tutorial006.pyasync def test_book_table() - None: async with Client(mcp) as client: await client.call_tool(book_table, {date: Friday})mcp.shared.exceptions.MCPError: Cannot send elicitation/create: this transport context has no back-channel for server-initiated requests.老代际连接 stateless_httpTrue的服务器。无状态意味着每个请求都是独立的世界没有会话、没有服务器到客户端的流因此即使是在存在elicitation/create以及sampling/createMessage、roots/list的代际也没有地方可发--8-- docs_src/troubleshooting/tutorial008.py老代际连接 json_responseTrue的服务器。POST用一个 JSON 体应答而一个体只能承载响应所以请求中途ctx.elicit()所需的、以请求为作用域的流在这里同样不存在。会话、它的Mcp-Session-Id和它独立的流都还在消失的只是以请求为作用域的通道。消息会指名它发送失败的那个方法。服务器抛出的异常类是NoBackChannelError见 src/mcp/server/connection.py 附近文档中对该异常出处的说明但线路上只传输基类MCPError所以上面这句话才是你 traceback 的最后一行而不是类名。对2026-07-28客户端三种情况下的修复都一样不要在调用中途回触客户端。把问题移进resolver或者自己返回InputRequiredResult它就变成了响应的一部分——任何连接都能承载--8-- docs_src/troubleshooting/tutorial007.py同一个问题、客户端上同一个elicitation_callback。区别在底层resolver 让服务器把问题从调用中返回而不是向外推送所以永远不会产生服务器到客户端的数据流。这能解救处于三种配置中任何一种服务器下的所有2026-07-28客户端。而老代际客户端仅靠改写是救不了的2025-11-25没有返回问题的方式所以在老代际连接上resolver 依然会把elicitation/create沿请求作用域通道发送出去依然需要一台保留该通道的服务器——既不能是stateless_httpTrue也不能是json_responseTrue。resolver 的完整讲解见 docs/handlers/elicitation.md线路上发生了什么见 docs/handlers/multi-round-trip.md。[!CHECK] 带ctx.elicit()的工具并不是写错了它是2026 年之前的工具。用modelegacy经典initialize握手、规范2025-11-25及更早连接一台既非stateless_httpTrue也非json_responseTrue的服务器它就能正常工作——因为那里存在服务器到客户端的通道。 每个版本各有什么见 docs/protocol-versions.md。MCPError: Invalid or expired requestState服务器无法验证客户端回传的requestState令牌于是拒绝了这一轮round。requestState是多轮请求在各轮之间携带的不透明续接令牌。MCPServer在发出时为其加盖封印seal并在每次回传时验证而且它会在tools/call、prompts/get、resources/read上验证每一个入站request_state——即使某个处理器从不自己铸造令牌。所以一个不是本进程封印的令牌无论落到哪里都会被拒绝async def main() - None: async with Client(http://localhost:8000/mcp) as client: await client.call_tool(forecast, {city: London}, request_stateround-1-from-worker-a)mcp.shared.exceptions.MCPError: Invalid or expired requestState这条消息是故意冻结的线路上绝不会泄露是哪一项检查失败了。原因写进了服务器日志读日志就是全部诊断手段WARNING mcp.server.request_state: requestState rejected on tools/call: malformed你实际会看到的原因unknown key—— 这是最关键的一条。默认封印密钥在进程启动时生成所以一次重试如果落到了另一个 worker、负载均衡后面的另一个实例或者重启之后的同一台服务器就会被一个本进程从未拥有过的密钥封印。这不是攻击者这是默认值遇上了多个进程。audience令牌被一台服务器名不同的实例封印。服务器名充当封印默认的 audience 声明所以整个服务器群必须共享同一个名字或显式设置RequestStateSecurity(audience...)而不只是共享密钥。expired这一轮耗时超过了封印的ttl——600 秒按轮计算而不是按调用计算。malformed/codec error令牌在传输途中被改动过或者它从来就不是一个被封印的令牌。request binding令牌随不同的工具、不同的参数或不同的方法回来了。多进程的修复方式是一个参数每个实例上用相同的keys加一个根本不是参数的东西相同的服务器名或显式共享的audiencemcp MCPServer(Weather, request_state_securityRequestStateSecurity(keys[key]))keys[0]负责封印列表中的每个密钥都参与验证——这正是无停机轮换rotation得以实现的原因。相关类型RequestStateSecurity与错误消息Invalid or expired requestState的实现位于 src/mcp/server/request_state.py 与同文件第 266 行附近服务器侧的接入点在 src/mcp/server/mcpserver/server.pyrequest_state_security参数。封印保护了什么、轮换顺序如何见 docs/handlers/multi-round-trip.md#protecting-requeststate完整的双 worker 故障 两段式修复推演见 docs/run/deploy.md。[!TIP]keys[...]会立即拒绝弱密钥而且提示消息异常贴心ValueError: request-state keys must be at least 32 bytes of secret randomness; keys[0] is 7 bytes. Generate one with: python -c import secrets; print(secrets.token_hex(32))照它说的做。还是解决不了如果 SDK 产出的某条消息不在这页上那本身就是一个值得单独上报的文档缺陷。在仓库的 issue 跟踪器中搜索那里出现的大多数错误字符串都已经有人详细写过。找不到带上完整 traceback 开一个 issue建议使用 v2-feedback 模板或到 MCP 贡献者社区#python-sdk-dev询问。速查总结ExceptionGroup: unhandled errors in a TaskGroup—— 永远不是真正的错误。读最后一行在async with Client(...)块内部捕获MCPError可完全跳过这层包裹。call_tool不会为失败的工具体抛出异常。Error executing tool ...与Unknown tool: ...都是结果检查result.is_error。工具名后面没有消息说明它崩溃了traceback 在服务器日志里。Client must be used within an async context manager→ 使用async with。Use tool() instead of tool→ 加上括号。服务器日志里的Tool already exists:是两个同名工具合并成一个的唯一信号。一个 421三种写法Server returned an error responsePythonClient、421 Misdirected Request/Invalid Host header其他一切、Invalid Host header: host服务器日志。修复transport_securityTransportSecuritySettings(allowed_hosts[...])。Task group is not initialized→ 被挂载的应用其宿主生命周期从未进入mcp.session_manager.run()。Session not found→ 服务器重启过或会话过期session_idle_timeout重连。Cannot send elicitation/create: ... no back-channel ...→ctx.elicit()需要一条服务器到客户端的通道2026-07-28连接永远没有stateless_httpTrue会夺走老代际的通道json_responseTrue会夺走请求作用域的通道。改用 resolver老代际客户端还需要一台保留通道的服务器。它的邻居Method not found是请求了对方协议版本里不存在的方法。Client did not declare the form elicitation capability ...与Elicitation not supported→ 客户端缺少elicitation_callback。Invalid or expired requestState永远不会在线上说明原因。服务器日志会unknown key意味着需要让RequestStateSecurity(keys[...])在所有 worker 间共享。【免费下载链接】python-sdkThe official Python SDK for Model Context Protocol servers and clients项目地址: https://gitcode.com/gh_mirrors/pythonsd/python-sdk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
