Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@ochafik
Copy link
Contributor

@ochafik ochafik commented Nov 11, 2025

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 content field will not be an array).

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

ochafik and others added 6 commits November 7, 2025 19:45
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]>
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]>
Copy link
Contributor

@bhosmer-ant bhosmer-ant left a 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

Copy link
Contributor Author

@ochafik ochafik left a 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]>
@localden localden linked an issue Nov 12, 2025 that may be closed by this pull request
Improved line breaks and spacing for clarity in the 'includeContext' note and tool choice modes section of the sampling client specification draft.
Updated the example sequences in the sampling specification to use inline code formatting for ToolUseContent and ToolResultContent, improving clarity and consistency in documentation.
@localden
Copy link
Contributor

@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?

Copy link
Contributor Author

@ochafik ochafik left a 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 !!

Copy link
Contributor

@bhosmer-ant bhosmer-ant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@bhosmer-ant bhosmer-ant merged commit 35dde44 into main Nov 14, 2025
6 checks passed
@bhosmer-ant bhosmer-ant deleted the ochafik/sep-1577-sampling-with-tools branch November 14, 2025 16:29

## 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&mdash;all within a single sampling request flow.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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&mdash;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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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,
Copy link
Member

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.

Copy link
Contributor

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

Comment on lines +42 to +47
**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
Copy link
Member

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

Comment on lines +83 to +94
**With context inclusion support (soft-deprecated):**

```json
{
"capabilities": {
"sampling": {
"context": {}
}
}
}
```

Copy link
Member

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?

Copy link
Contributor

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.
Copy link
Member

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

Copy link
Contributor

@bhosmer-ant bhosmer-ant Nov 14, 2025

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`
Copy link
Member

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?

Copy link
Contributor

@bhosmer-ant bhosmer-ant Nov 14, 2025

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

Copy link
Contributor Author

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

Copy link
Contributor Author

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SEP-1577 - Sampling With Tools

5 participants