Skip to content

fix(examples): return isError for input validation instead of internal error#838

Merged
ezynda3 merged 1 commit into
mark3labs:mainfrom
blackwell-systems:fix/everything-error-pattern
May 3, 2026
Merged

fix(examples): return isError for input validation instead of internal error#838
ezynda3 merged 1 commit into
mark3labs:mainfrom
blackwell-systems:fix/everything-error-pattern

Conversation

@blackwell-systems

@blackwell-systems blackwell-systems commented May 2, 2026

Copy link
Copy Markdown
Contributor

Summary

The everything server's echo and add tool handlers return (nil, fmt.Errorf(...)) for input validation failures (wrong type, missing argument). In the SDK, this produces -32603 (InternalError), which agents cannot distinguish from a server crash.

Changed to mcp.NewToolResultError(...), nil which returns isError: true with a descriptive message the agent can act on.

Before / After

Input Before After
echo with {"message": 42} -32603 "invalid message argument" isError: true "invalid message argument: expected string"
echo with {} -32603 "invalid message argument" isError: true "invalid message argument: expected string"
add with {"a": "x", "b": 2} -32603 "invalid number arguments" isError: true "invalid number arguments: expected numeric values"

Why this matters

The everything server is the reference example. Developers learning from it copy the return nil, fmt.Errorf(...) pattern. The SDK's own NewTypedToolHandler (typed_tools.go:19) and NewStructuredToolHandler (typed_tools.go:32) already use NewToolResultError for argument binding failures, but the untyped example teaches the opposite.

Internal errors (notification send failures at lines 408, 446) are unchanged since those represent actual server-side failures.

Test plan

  • go build ./examples/everything/ passes
  • go test ./... -short passes (all packages)
  • Verified via raw JSON-RPC: wrong types now return isError: true instead of -32603

Fixes #837

Summary by CodeRabbit

  • Bug Fixes
    • Enhanced error handling for tool input validation to provide structured error messages instead of generic errors. When tools receive invalid inputs such as incorrect data types, users now get clear, consistent error feedback that better describes the validation issues encountered.

…l error

The echo and add tool handlers use return nil, fmt.Errorf(...) for
input validation failures (wrong type, missing argument). In the SDK,
this produces -32603 (InternalError), which agents cannot recover from.

Changed to mcp.NewToolResultError(...), nil which returns isError: true
with a descriptive message. This matches the pattern used by the SDK's
own NewTypedToolHandler and NewStructuredToolHandler, and gives agents
actionable feedback they can use to self-correct.

Internal errors (notification send failures) are unchanged since those
represent actual server-side failures, not input validation.

Fixes mark3labs#837
@mark-iii-labs-huly

Copy link
Copy Markdown

Connected to Huly®: MCP_G-403

@coderabbitai

coderabbitai Bot commented May 2, 2026

Copy link
Copy Markdown
Contributor

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: f1725bec-1059-4222-8cdd-a1b468fc8eab

📥 Commits

Reviewing files that changed from the base of the PR and between 62f00b7 and 765a6fd.

📒 Files selected for processing (1)
  • examples/everything/main.go

Walkthrough

Two tool handlers in the example server are updated to return MCP-structured tool errors via mcp.NewToolResultError() for input validation failures, instead of generic Go errors. This corrects the error pattern to properly signal validation failures in the MCP protocol.

Changes

Example Tool Error Handling

Layer / File(s) Summary
Error Pattern Correction
examples/everything/main.go
handleEchoTool and handleAddTool now return mcp.NewToolResultError() with nil Go error for input validation failures (invalid message type and non-numeric arguments) instead of fmt.Errorf(), aligning with MCP protocol semantics for recoverable tool errors.

Estimated Code Review Effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly Related PRs

Suggested Reviewers

  • fabiante
🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: updating error handling in example code to return tool result errors for input validation instead of internal errors.
Description check ✅ Passed The description provides a comprehensive explanation including summary, before/after comparison, rationale, and test plan, matching the template's required structure.
Linked Issues check ✅ Passed The PR successfully addresses issue #837 by updating echo and add tool handlers to return mcp.NewToolResultError for validation failures instead of returning (nil, error).
Out of Scope Changes check ✅ Passed All changes are limited to fixing error handling in the echo and add tool handlers in examples/everything/main.go, directly addressing the linked issue with no extraneous modifications.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with 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.

❤️ Share
Review rate limit: 7/8 reviews remaining, refill in 7 minutes and 30 seconds.

Comment @coderabbitai help to get the list of available commands and usage tips.

@ezynda3 ezynda3 merged commit f6460bf into mark3labs:main May 3, 2026
4 checks passed
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.

Everything server example teaches wrong error pattern: returns (nil, error) for input validation

2 participants