-
Notifications
You must be signed in to change notification settings - Fork 1.2k
SEP-1577 - Sampling With Tools #1796
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Implement SEP-1577 to enable tool calling in sampling requests. Major changes: - Add tools and toolChoice parameters to sampling/createMessage - Introduce ToolUseContent and ToolResultContent message types - Support parallel tool calls via content arrays - Add sampling.tools and sampling.context capabilities to ClientCapabilities - Soft-deprecate includeContext values thisServer/allServers Breaking changes: - Content fields can now be arrays (for parallel tool calls) - Wire-level backward compatible - Tool result messages cannot contain mixed content types Updates: - schema/draft/schema.ts: New types and updated interfaces - schema/draft/schema.json: Auto-generated from TypeScript - docs/specification/draft/schema.mdx: Auto-generated from TypeScript - docs/specification/draft/client/sampling.mdx: Tool calling docs with examples - docs/specification/draft/changelog.mdx: SEP-1577 entry Cross-API compatibility: - Compatible with Claude, OpenAI, and Gemini APIs - Message content constraints ensure clean role mapping - Tool IDs support APIs without native ID support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
… message balance requirement - Make ToolResultContent.content required (not optional) to align with CallToolResult per SEP Oct 27 update that states "aligned on CallToolResult" - Add documentation for message balance requirement in sampling.mdx (tool use messages must be followed by corresponding tool results) - Regenerate schema.json and schema.mdx from updated types 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Aligns terminology with existing naming: - type: "tool_use" - ToolUseContent - stopReason: "toolUse" Updated all documentation and comments to use "tool use" instead of "tool calling" for feature name consistency. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Keep original 5 security considerations unchanged and add tool-specific items (6-12) as new additions rather than rewriting all items. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
- Remove redundant items (user approval already covered in item 1) - Remove off-topic items (validation, sanitization, timeouts) - Consolidate into key requirement: servers MUST respond to all tool uses and ensure tool result messages contain only tool results 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
bhosmer-ant
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for turning this around so quickly! Lots of comments, mostly minor editing tweaks. Let's chat offline about the others, nothing major but easier to get through with more bandwidth
ochafik
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed some comments (not all yet)
…num improvements) Conflicts resolved: - docs/specification/draft/changelog.mdx: Renumbered SEP-1577 to item #6 - schema/draft/schema.ts: Fixed @category annotations (added backticks) - schema/draft/schema.json: Auto-regenerated from schema.ts - docs/specification/draft/schema.mdx: Auto-regenerated with new structure Changes: - SEP-1577: Adds tool calling support to sampling/createMessage - New types: ToolChoice, ToolUseContent, ToolResultContent, UserMessage, AssistantMessage - Enhanced ClientCapabilities.sampling with tools field - SEP-1330: Adds JSON Schema 2020-12 compliant enum types - New types: TitledSingleSelectEnumSchema, TitledMultiSelectEnumSchema, etc. - Structural: schema.mdx template now includes @category tags for organization All schema validations passed: - TypeScript compilation: ✓ - JSON schema generation: ✓ - MDX documentation generation: ✓ 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Co-authored-by: bhosmer-ant <[email protected]>
…and tool_result content
Improved line breaks and spacing for clarity in the 'includeContext' note and tool choice modes section of the sampling client specification draft.
….com/modelcontextprotocol/modelcontextprotocol into ochafik/sep-1577-sampling-with-tools
Updated the example sequences in the sampling specification to use inline code formatting for ToolUseContent and ToolResultContent, improving clarity and consistency in documentation.
|
@ochafik @bhosmer-ant I just pushed a few changes to fix the linting errors. Looks like there are a few more comments left to address? |
ochafik
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much @localden & @bhosmer-ant !!
bhosmer-ant
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
|
|
||
| ## Tools in Sampling | ||
|
|
||
| Servers can request that the client's LLM use tools during sampling by providing a `tools` array and optional `toolChoice` configuration in their sampling requests. This enables servers to implement agentic behaviors where the LLM can call tools, receive results, and continue the conversation—all within a single sampling request flow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Servers can request that the client's LLM use tools during sampling by providing a `tools` array and optional `toolChoice` configuration in their sampling requests. This enables servers to implement agentic behaviors where the LLM can call tools, receive results, and continue the conversation—all within a single sampling request flow. | |
| Servers can request that the client's LLM use tools during sampling by providing a `tools` array and optional `toolChoice` configuration in their sampling requests. This enables servers to implement agentic behaviors where the LLM can call tools, receive results, and continue the conversation - all within a single sampling request flow. |
| - Multiple tools can be used in parallel | ||
| - Tool results are provided back to the LLM to inform subsequent responses | ||
|
|
||
| Clients **MUST** declare support for tool use via the `sampling.tools` capability to receive tool-enabled sampling requests. Servers **SHOULD NOT** send tool-enabled sampling requests to Clients that have not declared support for tool use via the `sampling.tools` capability. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Clients **MUST** declare support for tool use via the `sampling.tools` capability to receive tool-enabled sampling requests. Servers **SHOULD NOT** send tool-enabled sampling requests to Clients that have not declared support for tool use via the `sampling.tools` capability. | |
| Clients **MUST** declare support for tool use via the `sampling.tools` capability to receive tool-enabled sampling requests. Servers **MUST NOT** send tool-enabled sampling requests to Clients that have not declared support for tool use via the `sampling.tools` capability. |
| Clients **MUST** declare support for tool use via the `sampling.tools` capability to receive tool-enabled sampling requests. Servers **SHOULD NOT** send tool-enabled sampling requests to Clients that have not declared support for tool use via the `sampling.tools` capability. | ||
|
|
||
| <Info> | ||
| Tool use in sampling uses the same `Tool` type as regular MCP tool calls, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we link to that? I am also not really sure waht this section means. We usually refer to things in the spec as primitives, if that's what's meant here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can remove it without losing anything critical - more of a design note than anything else
| **Key capabilities:** | ||
|
|
||
| - Servers define tools with JSON schemas for inputs and outputs | ||
| - The LLM decides when and how to use tools (subject to `toolChoice` constraints) | ||
| - Multiple tools can be used in parallel | ||
| - Tool results are provided back to the LLM to inform subsequent responses |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure this is needed
| **With context inclusion support (soft-deprecated):** | ||
|
|
||
| ```json | ||
| { | ||
| "capabilities": { | ||
| "sampling": { | ||
| "context": {} | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am confused about this. There is no section about how this is deprecation is handled. Can we talk in separate section about handling the context inclusion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See note immediately below - what do you think is missing from there?
|
|
||
| ### Tool Use and Result Balance | ||
|
|
||
| When using tool use in sampling, messages **MUST** be properly balanced: every assistant message containing `ToolUseContent` blocks must be followed by a user message that consists entirely of `ToolResultContent` blocks, with each tool use (e.g. with `id: $id`) matched by a corresponding tool result (with `toolUseId: $id`), before any other message. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The word "balanced" feels off here. I think we can say:
When using tool use messages MUST ensure that an assistant message containing ToolUseContent is followed by a user message consisting of ToolResultContent blocks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having trouble parsing your suggestion, but if you want to avoid balanced how about just
When using tool use in sampling, every assistant message containing ToolUseContent blocks MUST be followed by a user message that consists entirely of ToolResultContent blocks, with each tool use (e.g. with id: $id) matched by a corresponding tool result (with toolUseId: $id), before any other message.
| Clients **SHOULD** return errors for common failure cases: | ||
|
|
||
| Example error: | ||
| - User rejected sampling request: `-1` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does JSON RPC have a specific error integer range for custom errors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
json rpc spec says anything outside the reserved range (-32768 to -32000). @ochafik found that we specify -1 elsewhere in the spec, that's where this came from
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The -1 is what is used a couple of lines below in the existing example for User rejected sampling request, and looks like it's actually fine as an application error.
The json rpc spec's Custom Error Codes section says:
For application-specific errors, the JSON-RPC 2.0 specification allows using any error code outside the reserved range (-32768 to -32000). Custom error codes are typically chosen based on the specific needs of your application.
Recommended Ranges
Range Usage
...
-31999 to -1 Recommended for general application errors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(next best thing would be -32601 / Method not found / The method does not exist / is not available, if we want to avoid an application error here - slight stretch of meaning to consider that declining sampling is a form of making it not available)
Motivation and Context
Spec change for #1577
Related: Python SDK change, TypeScript SDK change
cc/ @bhosmer-ant
How Has This Been Tested?
Breaking Changes
SDK users will need to update any code that uses sampling to test the type of the
CreateMessageResult.content, which can now be an array of content objects.Wire format will be unchanged if the spec version is < 2025-11-25 (i.e. the
contentfield will not be an array).Types of changes
Checklist
Additional context