-
Notifications
You must be signed in to change notification settings - Fork 694
fix CallToolResult json marshaling and unmarshaling: need structuredC… #523
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
WalkthroughUpdated CallToolResult JSON marshal/unmarshal and parsing to include the StructuredContent field; added unit tests for marshaling, unmarshaling, round-trip and edge cases; and added a server test validating tool responses with structured content. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~15 minutes Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
📜 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. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
@sunfuze thanks. Can you check the CI tests? |
I'm looking forward to using this when it's ready. |
I'm looking forward to it too |
Done. When marshal to json string, the int type will change to float for json use float to store number type. |
anything else we could help to push this forward? maybe add structured response implementations to the root |
I am looking forward to it if you want to know😉 |
@sunfuze There seems to be issues still. You can run these tests locally before you push. |
I'm sorry for the delay. We should have implemented this the first time when we added support for it on the server side. But I overlooked it and I was also using the SDK mostly for MCP servers. Once the tests are fixed, we will merge it and make a new release. |
Only need pull latest main branch, repository is quite active, and the modified branch has not been merged.
Yes, we can add a case to test tool handler response structured content. |
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.
Actionable comments posted: 0
🧹 Nitpick comments (1)
mcptest/mcptest_test.go (1)
191-275
: Good end-to-end coverage for structured content; add error-state assertion and negative-path test
- Add a quick assertion that the tool result is not an error.
- Consider a companion test for the missing user_id case to validate NewToolResultError path.
Suggested inline tweak:
@@ result, err := client.CallTool(ctx, req) if err != nil { t.Fatal("CallTool:", err) } + if result.IsError { + t.Fatalf("unexpected error result: %+v", result) + } + if len(result.Content) != 1 { t.Fatalf("Expected 1 content item, got %d", len(result.Content)) }Optional additional test outside this block:
func TestServerWithToolStructuredContent_MissingUserID(t *testing.T) { ctx := context.Background() srv, err := mcptest.NewServer(t, server.ServerTool{ Tool: mcp.NewTool("get_user", mcp.WithDescription("Gets user information with structured data."), mcp.WithString("user_id", mcp.Description("The user ID to look up.")), ), Handler: structuredContentHandler, }) if err != nil { t.Fatal(err) } defer srv.Close() client := srv.Client() var req mcp.CallToolRequest req.Params.Name = "get_user" // no user_id argument result, err := client.CallTool(ctx, req) if err != nil { t.Fatal("CallTool:", err) } if !result.IsError { t.Fatalf("expected error result when user_id is missing, got: %+v", result) } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
mcp/utils.go
(1 hunks)mcptest/mcptest_test.go
(1 hunks)
🧰 Additional context used
🧠 Learnings (7)
📓 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: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.
Learnt from: ezynda3
PR: mark3labs/mcp-go#461
File: server/sampling.go:22-26
Timestamp: 2025-06-30T07:13:17.052Z
Learning: In the mark3labs/mcp-go project, the MCPServer.capabilities field is a struct value (serverCapabilities), not a pointer, so it cannot be nil and doesn't require nil checking. Only pointer fields within the capabilities struct should be checked for nil.
📚 Learning: 2025-03-04T06:59:43.882Z
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.
Applied to files:
mcp/utils.go
mcptest/mcptest_test.go
📚 Learning: 2025-03-04T07:00:57.111Z
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.
Applied to files:
mcp/utils.go
mcptest/mcptest_test.go
📚 Learning: 2025-03-04T07:00:57.111Z
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.
Applied to files:
mcp/utils.go
mcptest/mcptest_test.go
📚 Learning: 2025-06-23T11:10:42.948Z
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.
Applied to files:
mcp/utils.go
mcptest/mcptest_test.go
📚 Learning: 2025-06-30T07:13:17.052Z
Learnt from: ezynda3
PR: mark3labs/mcp-go#461
File: server/sampling.go:22-26
Timestamp: 2025-06-30T07:13:17.052Z
Learning: In the mark3labs/mcp-go project, the MCPServer.capabilities field is a struct value (serverCapabilities), not a pointer, so it cannot be nil and doesn't require nil checking. Only pointer fields within the capabilities struct should be checked for nil.
Applied to files:
mcp/utils.go
mcptest/mcptest_test.go
📚 Learning: 2025-04-21T21:26:32.945Z
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.
Applied to files:
mcptest/mcptest_test.go
🔇 Additional comments (2)
mcp/utils.go (2)
673-678
: StructuredContent parsing added — LGTMThis fixes the loss of structuredContent during parsing. Placement and behavior are correct, and it’s non-breaking.
673-678
: structuredContent key is consistent across struct tags, custom JSON methods, and testsNo inconsistencies found—
json:"structuredContent"
in CallToolResult, its MarshalJSON/UnmarshalJSON implementations, and all related tests use the same key. No changes required.
CallToolRequest lost the value of StructuredContent when do json marshal and unmarshal
Description
CallToolRequest defines the MarshalerJSON and UnmarshalJSON methods, which are used by json.Marshal and json.Unmarshal. When structuredContent exists, it needs to be added to the target return.
Fixes #522
Type of Change
Checklist
Summary by CodeRabbit
New Features
Bug Fixes
Tests