Prototype support for outputSchema/structuredContent
#454
Conversation
- Add outputSchema field to Tool type and RegisteredTool interface - Make content field optional in CallToolResult - Update ListToolsRequestSchema handler to include outputSchema in tool list responses - Add support for structuredContent in tool results - Update examples to handle optional content field - Add tests for new outputSchema and structuredContent functionality - Update ToolCallback documentation to clarify when to use structuredContent vs content This change enables tools to define structured output schemas and return structured JSON content, providing better type safety and validation for tool outputs. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Cache tool output schemas when listing tools - Validate structuredContent against outputSchema during callTool - Enforce that tools with outputSchema must return structuredContent - Add json-schema-to-zod dependency for schema conversion - Add comprehensive tests for validation scenarios 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
…tured tool output - Add outputSchema support to Tool interface with proper documentation - Split CallToolResult into structured and unstructured variants - Change structuredContent from string to object type - Add validation that tools without outputSchema cannot return structuredContent - Add validation that tools with outputSchema must return structuredContent - Update client to validate structured content as object (no JSON parsing) - Update tests to use object format for structuredContent - Add tests for new validation constraints - Update LATEST_PROTOCOL_VERSION to DRAFT-2025-v2 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
ae82638 to
2ab965e
Compare
…patibility - Update McpServer to support registering tools with outputSchema - Add automatic content generation from structuredContent for backward compatibility - Add validation to ensure proper usage of structuredContent vs content - Add comprehensive tests for outputSchema functionality - Add example servers demonstrating structured output usage - Update existing test to match new backward compatibility behavior 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
2ab965e to
3a83e40
Compare
| @@ -39,7 +39,7 @@ describe("OAuth Authorization", () => { | |||
| const [url, options] = calls[0]; | |||
| expect(url.toString()).toBe("https://auth.example.com/.well-known/oauth-authorization-server"); | |||
| expect(options.headers).toEqual({ | |||
| "MCP-Protocol-Version": "2025-03-26" | |||
| "MCP-Protocol-Version": "DRAFT-2025-v2" | |||
There was a problem hiding this comment.
this is an official version that SDK support, I think it's better to keep it as is until:
- draft is release
- SDK implements most of the features in the new spec
| @@ -0,0 +1,171 @@ | |||
| # OutputSchema Support Implementation | |||
There was a problem hiding this comment.
Do we need this file? Should this be just release notes and updated README?
| { method: "tools/list", params }, | ||
| ListToolsResultSchema, | ||
| options, | ||
| ); | ||
|
|
||
| // Cache the tools and their output schemas for future validation |
There was a problem hiding this comment.
I'm a bit worried about this part related to caching tools
there are some efforts to refresh tool list on client like this one. Which will work fine as listTools is used there
I think my question here is, do we need to have cached output types - how expensive it is to convert it on the fly?
There was a problem hiding this comment.
I think _cachedTools is not used, right?
There was a problem hiding this comment.
[edited] the problem is that the client isn't actually storing tool definitions anywhere - so unless we grab and stash on an organic listTools call, we'd need to do one prior to the tool call itself (with no filter, and maybe multiple pages of results).
So yeah, this would be the first real connective state between tool definitions and tool calls in the client, I think. (And thus the first state that could go out of sync.)
But I'm not sure it's different in kind from, say, calling a tool based on a stale param schema... though ofc in that case the error would be on the server rather than the client.
Prototype support for schema validation additions proposed in modelcontextprotocol/modelcontextprotocol#371
Motivation and Context
How Has This Been Tested?
Breaking Changes
Types of changes
Checklist
Additional context