协议版本: draft
用户交互模型
MCP中的补全功能旨在支持类似IDE代码补全的交互式用户体验。 例如,应用程序可以在用户输入时以下拉或弹出菜单的形式显示完成建议,并提供从可用选项中筛选和选择的功能。 不过,各实现方案可以根据自身需求通过任意接口模式提供完成功能——该协议本身并不强制规定任何特定的用户交互模式。能力
支持完成的服务器 必须 声明completions 能力:
协议消息
请求补全功能
要获取补全建议,客户端发送一个completion/complete请求,并通过引用类型明确正在补全的内容:
请求:
context.arguments对象中,以为后续请求提供语境。
请求:
引用类型
该协议支持两种类型的完成引用:| 类型 | 描述 | 示例 |
|---|---|---|
参考/提示 | 通过名称引用提示 | {"type": "ref/prompt", "name": "code_review"} |
ref/resource | 引用一个资源URI | {"type": "ref/resource", "uri": "file:///{path}"} |
完成结果
服务器返回按相关性排序的完成值数组,其中包含:- 单次响应最大条目数为 100
- 可选的可用匹配总数
- 布尔值,指示是否存在更多结果
消息流
数据类型
完成请求
ref: 一个PromptReference或ResourceReferenceargument: 包含以下内容的对象:name: 参数名称value: 当前值
context: 包含以下内容的对象:arguments: 已解析参数名称与其值的映射关系。
最终结果
completion: 包含对象:values: 建议数组(最多100个)total: 可选的总匹配数hasMore: 附加结果标志
错误处理
Servers 应当 return standard JSON-RPC errors for common failure cases:- Method not found:
-32601(功能不支持) - 无效的提示名称:
-32602(无效参数) - 缺少必需的参数:
-32602(无效参数) - 内部错误:
-32603(内部错误)
实施注意事项
-
Servers 应当:
- 按相关性排序返回建议
- 在适当场景中实现模糊匹配
- 对完成请求进行速率限制
- 验证所有输入
-
Clients 应当:
- 抑制快速完成请求
- 适当地缓存补全结果
- 优雅地处理缺失或部分结果
安全性
实现 必须:- 验证所有完成输入项
- 实施适当的速率限制
- 控制对敏感建议的访问
- 防止基于完成度的信息泄露