协议版本: 2025-03-26
用户交互模型
MCP中的补全被设计为支持类似IDE代码补全的交互式用户体验。 例如,应用程序可以在用户输入时以下拉菜单或弹出菜单的形式显示补全建议,并提供从可用选项中筛选和选择的功能。 然而,实现者可以通过任何适合其需求的界面模式公开补全功能—协议本身不强制要求任何特定的用户交互模型。能力
支持补全的服务器必须声明completions能力:
协议消息
请求补全
要获取补全建议,客户端发送completion/complete请求,通过引用类型指定正在补全的内容:
请求:
引用类型
协议支持两种类型的补全引用:| 类型 | 描述 | 示例 |
|---|---|---|
ref/prompt | 按名称引用提示 | {"type": "ref/prompt", "name": "code_review"} |
ref/resource | 引用资源URI | {"type": "ref/resource", "uri": "file:///{path}"} |
补全结果
服务器返回按相关性排序的补全值数组,包含:- 每个响应最多100个项目
- 可选的可用匹配总数
- 表示是否存在额外结果的布尔值
消息流
数据类型
CompleteRequest
ref:PromptReference或ResourceReferenceargument:包含以下内容的对象:name:参数名称value:当前值
CompleteResult
completion:包含以下内容的对象:values:建议数组(最多100个)total:可选的匹配总数hasMore:额外结果标志
错误处理
服务器应该为常见失败情况返回标准JSON-RPC错误:- 方法未找到:
-32601(不支持的能力) - 无效的提示名称:
-32602(无效参数) - 缺少必需参数:
-32602(无效参数) - 内部错误:
-32603(内部错误)
实施考虑
-
服务器应该:
- 返回按相关性排序的建议
- 在适当的情况下实现模糊匹配
- 限制补全请求速率
- 验证所有输入
-
客户端应该:
- 防抖快速补全请求
- 在适当的情况下缓存补全结果
- 优雅地处理缺失或部分结果
安全
实现必须:- 验证所有补全输入
- 实施适当的速率限制
- 控制对敏感建议的访问
- 防止基于补全的信息泄露