feat: support structured content and output schema #460
Conversation
WalkthroughThis change introduces structured tool output support by extending the MCP framework. It adds output schema and structured content fields to core types, provides helper functions for structured results, updates tool registration, and includes new examples and tests demonstrating structured output. The update is backward compatible and additive. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Possibly related PRs
Suggested labels
Suggested reviewers
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
examples/structured_output/README.md (1)
5-5: Fix the bare URL formatting.The markdown linter flagged this bare URL. Wrap it in angle brackets for better compliance.
-Defined in the MCP spec here: https://modelcontextprotocol.io/specification/2025-06-18/server/tools#structured-content +Defined in the MCP spec here: <https://modelcontextprotocol.io/specification/2025-06-18/server/tools#structured-content>mcp/utils.go (1)
482-535: Consider simplifying the schema extraction logic.The function handles complex $ref resolution but has several potential edge cases that could cause issues. Consider the following improvements:
- The $ref parsing assumes a specific format but doesn't validate it
- Deep nested references aren't handled
- Complex schema structures might not be properly cleaned
Consider adding validation and error handling for edge cases:
// Extract the reference name refParts := strings.Split(ref, "/") -if len(refParts) > 0 { +if len(refParts) > 0 && strings.HasPrefix(ref, "#/$defs/") { defName := refParts[len(refParts)-1] + if defName == "" { + return nil, fmt.Errorf("invalid $ref format: %s", ref) + } if defSchema, found := defs[defName].(map[string]any); found {Additionally, consider adding support for other common JSON Schema fields like
items,additionalProperties, etc., if they're commonly used in your MCP schemas.examples/structured_output/main.go (1)
99-112: Consider adding error handling for the manual approach.While the current implementation works, consider demonstrating error handling in the manual approach to show best practices.
You could enhance the example by showing error handling:
func manualWeatherHandler(ctx context.Context, request mcp.CallToolRequest, args WeatherRequest) (*mcp.CallToolResult, error) { + if args.Location == "" { + return mcp.NewToolResultError("Location is required"), nil + } + response := WeatherResponse{ Location: args.Location, Temperature: 25.0, Units: "celsius", Conditions: "Sunny, yesterday my life was filled with rain", Timestamp: time.Now(), }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (7)
examples/structured_output/README.md(1 hunks)examples/structured_output/main.go(1 hunks)go.mod(1 hunks)mcp/tools.go(6 hunks)mcp/tools_test.go(1 hunks)mcp/typed_tools.go(2 hunks)mcp/utils.go(3 hunks)
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in the mark3labs/mcp-go project should handle both InputSchema and RawInputSchema consistently between MarshalJSON and UnmarshalJSON methods, even though the tools response from MCP server typically doesn't contain rawInputSchema.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in mark3labs/mcp-go handles both InputSchema and RawInputSchema formats. When unmarshaling JSON, it first tries to parse into a structured ToolInputSchema format, and if that fails, it falls back to using the raw schema format, providing symmetry with the MarshalJSON method.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:107-137
Timestamp: 2025-03-04T06:59:43.882Z
Learning: Tool responses from the MCP server shouldn't contain RawInputSchema, which is why the UnmarshalJSON method for the Tool struct is implemented to handle only the structured InputSchema format.
examples/structured_output/README.md (5)
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in mark3labs/mcp-go handles both InputSchema and RawInputSchema formats. When unmarshaling JSON, it first tries to parse into a structured ToolInputSchema format, and if that fails, it falls back to using the raw schema format, providing symmetry with the MarshalJSON method.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in the mark3labs/mcp-go project should handle both InputSchema and RawInputSchema consistently between MarshalJSON and UnmarshalJSON methods, even though the tools response from MCP server typically doesn't contain rawInputSchema.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:107-137
Timestamp: 2025-03-04T06:59:43.882Z
Learning: Tool responses from the MCP server shouldn't contain RawInputSchema, which is why the UnmarshalJSON method for the Tool struct is implemented to handle only the structured InputSchema format.
Learnt from: davidleitw
PR: mark3labs/mcp-go#451
File: mcp/tools.go:1192-1217
Timestamp: 2025-06-26T09:38:18.629Z
Learning: In mcp-go project, the maintainer prefers keeping builder pattern APIs simple without excessive validation for edge cases. The WithOutput* functions are designed to assume correct usage rather than defensive programming, following the principle of API simplicity over comprehensive validation.
Learnt from: floatingIce91
PR: mark3labs/mcp-go#401
File: server/server.go:1082-1092
Timestamp: 2025-06-23T11:10:42.948Z
Learning: In Go MCP server, ServerTool.Tool field is only used for tool listing and indexing, not for tool execution or middleware. During handleToolCall, only the Handler field is used, so dynamic tools don't need the Tool field populated.
go.mod (3)
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in mark3labs/mcp-go handles both InputSchema and RawInputSchema formats. When unmarshaling JSON, it first tries to parse into a structured ToolInputSchema format, and if that fails, it falls back to using the raw schema format, providing symmetry with the MarshalJSON method.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in the mark3labs/mcp-go project should handle both InputSchema and RawInputSchema consistently between MarshalJSON and UnmarshalJSON methods, even though the tools response from MCP server typically doesn't contain rawInputSchema.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:107-137
Timestamp: 2025-03-04T06:59:43.882Z
Learning: Tool responses from the MCP server shouldn't contain RawInputSchema, which is why the UnmarshalJSON method for the Tool struct is implemented to handle only the structured InputSchema format.
mcp/typed_tools.go (7)
Learnt from: floatingIce91
PR: mark3labs/mcp-go#401
File: server/server.go:1082-1092
Timestamp: 2025-06-23T11:10:42.948Z
Learning: In Go MCP server, ServerTool.Tool field is only used for tool listing and indexing, not for tool execution or middleware. During handleToolCall, only the Handler field is used, so dynamic tools don't need the Tool field populated.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:107-137
Timestamp: 2025-03-04T06:59:43.882Z
Learning: Tool responses from the MCP server shouldn't contain RawInputSchema, which is why the UnmarshalJSON method for the Tool struct is implemented to handle only the structured InputSchema format.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in the mark3labs/mcp-go project should handle both InputSchema and RawInputSchema consistently between MarshalJSON and UnmarshalJSON methods, even though the tools response from MCP server typically doesn't contain rawInputSchema.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in mark3labs/mcp-go handles both InputSchema and RawInputSchema formats. When unmarshaling JSON, it first tries to parse into a structured ToolInputSchema format, and if that fails, it falls back to using the raw schema format, providing symmetry with the MarshalJSON method.
Learnt from: lariel-fernandes
PR: mark3labs/mcp-go#428
File: www/docs/pages/servers/prompts.mdx:218-234
Timestamp: 2025-06-20T20:39:51.870Z
Learning: In the mcp-go library, the GetPromptParams.Arguments field is of type map[string]string, not map[string]interface{}, so direct string access without type assertions is safe and correct.
Learnt from: octo
PR: mark3labs/mcp-go#149
File: mcptest/mcptest.go:0-0
Timestamp: 2025-04-21T21:26:32.945Z
Learning: In the mcptest package, prefer returning errors from helper functions rather than calling t.Fatalf() directly, giving callers flexibility in how to handle errors.
Learnt from: davidleitw
PR: mark3labs/mcp-go#451
File: mcp/tools.go:1192-1217
Timestamp: 2025-06-26T09:38:18.629Z
Learning: In mcp-go project, the maintainer prefers keeping builder pattern APIs simple without excessive validation for edge cases. The WithOutput* functions are designed to assume correct usage rather than defensive programming, following the principle of API simplicity over comprehensive validation.
mcp/tools_test.go (6)
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:107-137
Timestamp: 2025-03-04T06:59:43.882Z
Learning: Tool responses from the MCP server shouldn't contain RawInputSchema, which is why the UnmarshalJSON method for the Tool struct is implemented to handle only the structured InputSchema format.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in the mark3labs/mcp-go project should handle both InputSchema and RawInputSchema consistently between MarshalJSON and UnmarshalJSON methods, even though the tools response from MCP server typically doesn't contain rawInputSchema.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in mark3labs/mcp-go handles both InputSchema and RawInputSchema formats. When unmarshaling JSON, it first tries to parse into a structured ToolInputSchema format, and if that fails, it falls back to using the raw schema format, providing symmetry with the MarshalJSON method.
Learnt from: octo
PR: mark3labs/mcp-go#149
File: mcptest/mcptest.go:0-0
Timestamp: 2025-04-21T21:26:32.945Z
Learning: In the mcptest package, prefer returning errors from helper functions rather than calling t.Fatalf() directly, giving callers flexibility in how to handle errors.
Learnt from: davidleitw
PR: mark3labs/mcp-go#451
File: mcp/tools.go:1192-1217
Timestamp: 2025-06-26T09:38:18.629Z
Learning: In mcp-go project, the maintainer prefers keeping builder pattern APIs simple without excessive validation for edge cases. The WithOutput* functions are designed to assume correct usage rather than defensive programming, following the principle of API simplicity over comprehensive validation.
Learnt from: floatingIce91
PR: mark3labs/mcp-go#401
File: server/server.go:1082-1092
Timestamp: 2025-06-23T11:10:42.948Z
Learning: In Go MCP server, ServerTool.Tool field is only used for tool listing and indexing, not for tool execution or middleware. During handleToolCall, only the Handler field is used, so dynamic tools don't need the Tool field populated.
mcp/utils.go (6)
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:107-137
Timestamp: 2025-03-04T06:59:43.882Z
Learning: Tool responses from the MCP server shouldn't contain RawInputSchema, which is why the UnmarshalJSON method for the Tool struct is implemented to handle only the structured InputSchema format.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in the mark3labs/mcp-go project should handle both InputSchema and RawInputSchema consistently between MarshalJSON and UnmarshalJSON methods, even though the tools response from MCP server typically doesn't contain rawInputSchema.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in mark3labs/mcp-go handles both InputSchema and RawInputSchema formats. When unmarshaling JSON, it first tries to parse into a structured ToolInputSchema format, and if that fails, it falls back to using the raw schema format, providing symmetry with the MarshalJSON method.
Learnt from: floatingIce91
PR: mark3labs/mcp-go#401
File: server/server.go:1082-1092
Timestamp: 2025-06-23T11:10:42.948Z
Learning: In Go MCP server, ServerTool.Tool field is only used for tool listing and indexing, not for tool execution or middleware. During handleToolCall, only the Handler field is used, so dynamic tools don't need the Tool field populated.
Learnt from: octo
PR: mark3labs/mcp-go#149
File: mcptest/mcptest.go:0-0
Timestamp: 2025-04-21T21:26:32.945Z
Learning: In the mcptest package, prefer returning errors from helper functions rather than calling t.Fatalf() directly, giving callers flexibility in how to handle errors.
Learnt from: davidleitw
PR: mark3labs/mcp-go#451
File: mcp/tools.go:1192-1217
Timestamp: 2025-06-26T09:38:18.629Z
Learning: In mcp-go project, the maintainer prefers keeping builder pattern APIs simple without excessive validation for edge cases. The WithOutput* functions are designed to assume correct usage rather than defensive programming, following the principle of API simplicity over comprehensive validation.
examples/structured_output/main.go (6)
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in the mark3labs/mcp-go project should handle both InputSchema and RawInputSchema consistently between MarshalJSON and UnmarshalJSON methods, even though the tools response from MCP server typically doesn't contain rawInputSchema.
Learnt from: davidleitw
PR: mark3labs/mcp-go#451
File: mcp/tools.go:1192-1217
Timestamp: 2025-06-26T09:38:18.629Z
Learning: In mcp-go project, the maintainer prefers keeping builder pattern APIs simple without excessive validation for edge cases. The WithOutput* functions are designed to assume correct usage rather than defensive programming, following the principle of API simplicity over comprehensive validation.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:107-137
Timestamp: 2025-03-04T06:59:43.882Z
Learning: Tool responses from the MCP server shouldn't contain RawInputSchema, which is why the UnmarshalJSON method for the Tool struct is implemented to handle only the structured InputSchema format.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in mark3labs/mcp-go handles both InputSchema and RawInputSchema formats. When unmarshaling JSON, it first tries to parse into a structured ToolInputSchema format, and if that fails, it falls back to using the raw schema format, providing symmetry with the MarshalJSON method.
Learnt from: floatingIce91
PR: mark3labs/mcp-go#401
File: server/server.go:1082-1092
Timestamp: 2025-06-23T11:10:42.948Z
Learning: In Go MCP server, ServerTool.Tool field is only used for tool listing and indexing, not for tool execution or middleware. During handleToolCall, only the Handler field is used, so dynamic tools don't need the Tool field populated.
Learnt from: octo
PR: mark3labs/mcp-go#149
File: mcptest/mcptest.go:0-0
Timestamp: 2025-04-21T21:26:32.945Z
Learning: In the mcptest package, prefer returning errors from helper functions rather than calling t.Fatalf() directly, giving callers flexibility in how to handle errors.
mcp/tools.go (5)
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in mark3labs/mcp-go handles both InputSchema and RawInputSchema formats. When unmarshaling JSON, it first tries to parse into a structured ToolInputSchema format, and if that fails, it falls back to using the raw schema format, providing symmetry with the MarshalJSON method.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in the mark3labs/mcp-go project should handle both InputSchema and RawInputSchema consistently between MarshalJSON and UnmarshalJSON methods, even though the tools response from MCP server typically doesn't contain rawInputSchema.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:107-137
Timestamp: 2025-03-04T06:59:43.882Z
Learning: Tool responses from the MCP server shouldn't contain RawInputSchema, which is why the UnmarshalJSON method for the Tool struct is implemented to handle only the structured InputSchema format.
Learnt from: davidleitw
PR: mark3labs/mcp-go#451
File: mcp/tools.go:1192-1217
Timestamp: 2025-06-26T09:38:18.629Z
Learning: In mcp-go project, the maintainer prefers keeping builder pattern APIs simple without excessive validation for edge cases. The WithOutput* functions are designed to assume correct usage rather than defensive programming, following the principle of API simplicity over comprehensive validation.
Learnt from: floatingIce91
PR: mark3labs/mcp-go#401
File: server/server.go:1082-1092
Timestamp: 2025-06-23T11:10:42.948Z
Learning: In Go MCP server, ServerTool.Tool field is only used for tool listing and indexing, not for tool execution or middleware. During handleToolCall, only the Handler field is used, so dynamic tools don't need the Tool field populated.
🧬 Code Graph Analysis (4)
mcp/typed_tools.go (2)
mcp/tools.go (2)
CallToolRequest(52-55)CallToolResult(38-49)mcp/utils.go (2)
NewToolResultError(345-355)NewToolResultStructuredOnly(274-288)
mcp/tools_test.go (3)
mcp/tools.go (5)
NewTool(582-604)WithDescription(625-629)WithOutputSchema(633-651)WithString(893-911)Required(725-729)mcp/utils.go (1)
NewToolResultStructured(260-270)mcp/types.go (3)
Content(827-829)TextContent(833-838)TextContent(840-840)
mcp/utils.go (2)
mcp/tools.go (1)
CallToolResult(38-49)mcp/types.go (3)
Content(827-829)TextContent(833-838)TextContent(840-840)
mcp/tools.go (1)
mcp/utils.go (1)
ExtractMCPSchema(483-535)
🪛 markdownlint-cli2 (0.17.2)
examples/structured_output/README.md
5-5: Bare URL used
null
(MD034, no-bare-urls)
🔇 Additional comments (18)
go.mod (2)
7-7: LGTM! Dependency addition supports structured output feature.The addition of
github.com/invopop/jsonschemaaligns perfectly with the PR objective to support automatic output schema generation for structured content.
14-19: Indirect dependencies look appropriate.The new indirect dependencies (
bahlo/generic-list-go,buger/jsonparser,mailru/easyjson,wk8/go-ordered-map/v2) are expected transitive dependencies of the jsonschema library and support JSON processing utilities.examples/structured_output/README.md (1)
11-44: Excellent documentation with clear examples.The code examples clearly demonstrate the new structured output functionality:
- Struct definition with JSON schema tags
- Tool creation with output schema
- Handler implementation returning structured data
This provides great guidance for SDK users implementing the new feature.
mcp/typed_tools.go (2)
11-12: Well-designed generic handler function type.The
StructuredToolHandlerFuncprovides excellent type safety by parameterizing both input arguments and output result types, enabling strongly-typed structured output handling.
25-42: Robust implementation with proper error handling.The
NewStructuredToolHandlerfunction correctly:
- Binds arguments with error handling
- Executes the handler with error propagation
- Creates structured-only results for backward compatibility
- Follows the established pattern from
NewTypedToolHandlerThe use of
NewToolResultStructuredOnlyensures both structured content and fallback text are provided as required by the MCP specification.mcp/tools_test.go (2)
532-562: Comprehensive test for output schema generation.The test effectively validates:
- Schema generation from Go structs with JSON schema tags
- Proper setting of
RawOutputSchemafield- JSON marshaling includes
outputSchemafield- Integration with the tool builder pattern
The test struct with various JSON schema tags provides good coverage of the schema generation functionality.
564-581: Good test coverage for structured tool results.The test properly verifies that
NewToolResultStructuredcreates results with:
- Correct fallback text content
- Non-nil structured content field
- Proper content array structure
This ensures the structured output feature works as expected for both structured and fallback content.
mcp/tools.go (6)
10-10: Appropriate dependency addition for schema generation.The
github.com/invopop/jsonschemaimport enables automatic JSON schema generation from Go types, which is essential for the new output schema functionality.
41-44: Well-documented structured content field.The
StructuredContentfield addition properly follows the MCP specification for structured content support. The documentation clearly explains the backward compatibility requirement to provide functionally equivalent unstructured content.
487-488: Correct implementation of output schema field.The
RawOutputSchemafield is properly:
- Hidden from JSON marshaling with
json:"-"tag- Well-documented as optional
- Positioned logically after input schema fields
This follows the same pattern as
RawInputSchemaand maintains consistency.
502-502: Proper map sizing and output schema handling.The map capacity increase to 5 accounts for the new output schema field. The output schema is correctly added to the JSON only when present, maintaining backward compatibility.
Also applies to: 521-524
631-651: Excellent generic output schema function.The
WithOutputSchema[T any]()function provides an elegant API for automatic schema generation:
- Uses reflection to generate schema from Go types
- Extracts MCP-compatible schema via
ExtractMCPSchema- Silently ignores errors for backward compatibility
- Follows the maintainer's preference for simple APIs without excessive validation
The approach aligns with the retrieved learning about keeping builder pattern APIs simple.
653-662: Good raw schema option for advanced use cases.The
WithRawOutputSchemafunction provides necessary flexibility for complex schemas that can't be auto-generated from Go types, complementing the genericWithOutputSchemafunction nicely.mcp/utils.go (2)
6-6: LGTM - Necessary imports for new functionality.The additional imports support the new structured content features:
stringsfor string manipulation in schema processing andjsonschemafor schema generation.Also applies to: 8-8
258-270: LGTM - Clean helper function for structured results.This function provides a clear API for creating structured tool results with explicit fallback text, which aligns well with the MCP specification's recommendation for backward compatibility.
examples/structured_output/main.go (3)
12-17: Good use of schema description tags.The
jsonschema_descriptiontags will help generate meaningful API documentation for the tools. This is a good pattern for developers to follow.
38-73: Excellent demonstration of structured output patterns.The example effectively showcases three different approaches:
- Auto-generated schema with structured handler
- Nested struct schema
- Manual result creation
This provides developers with multiple implementation options based on their needs.
75-88: Clean handler implementation with temperature conversion.The handler properly processes the input arguments and includes business logic (temperature unit conversion). Good example of a realistic tool implementation.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
examples/structured_output/main.go (1)
94-137: Handler implementations are well-structured with one typo to fix.The handler functions properly demonstrate structured output patterns with appropriate validation and bounds checking. However, there's a typo in the asset data.
Fix the asset name typo:
- {ID: "dot", Name: "Pottedot", Value: 18.45, Currency: "USD"}, + {ID: "dot", Name: "Polkadot", Value: 18.45, Currency: "USD"},
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
examples/structured_output/main.go(1 hunks)mcp/tools.go(6 hunks)mcp/utils.go(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- mcp/utils.go
- mcp/tools.go
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in the mark3labs/mcp-go project should handle both InputSchema and RawInputSchema consistently between MarshalJSON and UnmarshalJSON methods, even though the tools response from MCP server typically doesn't contain rawInputSchema.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in mark3labs/mcp-go handles both InputSchema and RawInputSchema formats. When unmarshaling JSON, it first tries to parse into a structured ToolInputSchema format, and if that fails, it falls back to using the raw schema format, providing symmetry with the MarshalJSON method.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:107-137
Timestamp: 2025-03-04T06:59:43.882Z
Learning: Tool responses from the MCP server shouldn't contain RawInputSchema, which is why the UnmarshalJSON method for the Tool struct is implemented to handle only the structured InputSchema format.
examples/structured_output/main.go (6)
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in the mark3labs/mcp-go project should handle both InputSchema and RawInputSchema consistently between MarshalJSON and UnmarshalJSON methods, even though the tools response from MCP server typically doesn't contain rawInputSchema.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:0-0
Timestamp: 2025-03-04T07:00:57.111Z
Learning: The Tool struct in mark3labs/mcp-go handles both InputSchema and RawInputSchema formats. When unmarshaling JSON, it first tries to parse into a structured ToolInputSchema format, and if that fails, it falls back to using the raw schema format, providing symmetry with the MarshalJSON method.
Learnt from: davidleitw
PR: mark3labs/mcp-go#451
File: mcp/tools.go:1192-1217
Timestamp: 2025-06-26T09:38:18.629Z
Learning: In mcp-go project, the maintainer prefers keeping builder pattern APIs simple without excessive validation for edge cases. The WithOutput* functions are designed to assume correct usage rather than defensive programming, following the principle of API simplicity over comprehensive validation.
Learnt from: xinwo
PR: mark3labs/mcp-go#35
File: mcp/tools.go:107-137
Timestamp: 2025-03-04T06:59:43.882Z
Learning: Tool responses from the MCP server shouldn't contain RawInputSchema, which is why the UnmarshalJSON method for the Tool struct is implemented to handle only the structured InputSchema format.
Learnt from: floatingIce91
PR: mark3labs/mcp-go#401
File: server/server.go:1082-1092
Timestamp: 2025-06-23T11:10:42.948Z
Learning: In Go MCP server, ServerTool.Tool field is only used for tool listing and indexing, not for tool execution or middleware. During handleToolCall, only the Handler field is used, so dynamic tools don't need the Tool field populated.
Learnt from: octo
PR: mark3labs/mcp-go#149
File: mcptest/mcptest.go:0-0
Timestamp: 2025-04-21T21:26:32.945Z
Learning: In the mcptest package, prefer returning errors from helper functions rather than calling t.Fatalf() directly, giving callers flexibility in how to handle errors.
🔇 Additional comments (3)
examples/structured_output/main.go (3)
1-47: Well-structured type definitions for schema generation.The import statements and struct definitions properly demonstrate the new structured output features. The
jsonschema_descriptiontags will enable automatic schema generation as intended by this PR.
49-92: Excellent demonstration of structured output capabilities.The main function effectively showcases all the new structured output features introduced in this PR:
- Auto-generated output schemas with
WithOutputSchema[T]()- Different handler types (
NewStructuredToolHandler,NewTypedToolHandler)- Various output types (structs, arrays, manual creation)
This provides a comprehensive example for SDK users.
139-152: Excellent demonstration of manual structured result creation.This handler effectively showcases the
NewToolResultStructuredutility function, demonstrating how to create structured output with fallback text. This pattern provides SDK users with fine-grained control over tool results while maintaining backward compatibility.
|
|
||
| return &CallToolResult{ | ||
| Content: []Content{ | ||
| TextContent{ |
There was a problem hiding this comment.
This still returns fallback text so naming doesn't really match with behavior...
There was a problem hiding this comment.
I will update the documentation to be more clear. As per the spec, there should always be a fallback.
| mcpSchema, err := json.Marshal(schema) | ||
| if err != nil { | ||
| // Skip and maintain backward compatibility | ||
| return |
There was a problem hiding this comment.
Maybe we can add a tool validation logic later?
|
Can we converge on one of these PRs? Would love to see this feature in the SDK. @ezynda3 @pottekkat this one or #451? |
|
@David-Kreiner, others, sorry for the delay in getting this merged. It will be merged and released today. |
Description
Adds support for providing
structuredContentin tool result. Also adds anoutputSchemaautomatically from the "structure" of thestructuredContentoutput.See the examples added in this PR for more info.
Fixes #410
Type of Change
Checklist
MCP Spec Compliance
Additional Information
This can be treated as an initial draft implementation to try and sense the direction of how this feature must be implemented. Helper functions can be added if this direction is ok for the SDK users OR if this is undesired, it can be scraped and a new one can be implemented.
It is important that we get this right as it is a new non-breaking feature. Once implemented and adopted, it would be difficult to change this.
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Tests