Proposal: Give receiving middleware access to tool errors.

[jba]

Is your feature request related to a problem? Please describe.
Middleware for tool calls won't see the actual error (value of type error) that the ToolHandler returns, because it is turned into text with IsError: true by the ToolHandler. (At least, when the ToolHandler is created with NewServerTool.) Therefore, middleware can't make decisions based on the error value.

Describe the solution you'd like
Middleware can see the error value.

Ideas:

1. Use an interface:

type CallToolResult interface {
	ToResult() *CallToolResult
}

See https://github.com/orgs/modelcontextprotocol/discussions/364#discussioncomment-13574919.

2. Add a method or field to CallToolResult holding the error. The field wouldn't serialize, but could be inspected by middleware.

// SetError sets the Content and IsError fields to reflect err. It also stores err itself for retrieval by GetError.
// SetError is a no-op if err == nil.
func (c *CallToolResult[In, Out]) SetError(err error) 

// GetError returns the error set by SetError, or nil if none.
func (c *CallToolResult[In, Out]) GetError() error

[SamMorrowDrums]

Im our work with mcp-go we did initially wish for option 2. It would certainly suffice.

I think either approach works. 2 is simpler and likely sufficient, 1 enables the original type to be upcast should that be useful, and allows for the ability to wrap a handler in another handler so you can compose 2nd order handler stuff or use another server as a library etc.

[jba]

Can you give examples of "enables the original type to be upcast" and "ability to wrap and handler in another handler" using 1?

[SamMorrowDrums]

So, as an example if a server exported the following:

	ServerTool := mcp.NewServerTool[*HiArgs, *HiResult]("greet", "say hi", SayHi, mcp.Input(
		mcp.Property("name", mcp.Description("the name to say hi to")),
	))

I was imagining something like:

originalHandler := ServerTool.Handler
ServerTool.Handler := func(ctx context.Context, ss *mcp.ServerSession, params *mcp.CallToolParamsFor[json.RawMessage]) (ToolOutput, error) {
	result, err := originalHantdler(ctx, ss, params)
	if err != nil {
		return nil, err
	}

	typedResult, ok := result.(*HiResult)
	if !ok {
		return nil, fmt.Errorf("unexpected result type: %T", result)
	}

	// do something with the result, before returning it
	typedResult.Message = "Modified: " + typedResult.Message

	return typedResult, nil
}

I suppose as long as you have access to the original handler function you can just wrap it directly and define a new tool yourself, but this would also be able to work with an anonymous definition, and while you could only upcast if you have access to the type, but you could always at least call Result() and then manipulate the result before returning it.

Anyway, just wanted to throw this out there. An example of top of head is if I have 5 different search tools in one server, I might build a new server with a simple search tool, that is capable of deffering to each of those and using sampling and things to combine multiple handlers into a singluar handler, and then I could return the results of any of them from my tool as it works with an interface, and so I don't have to define the output type to be flexible to all possible return values.

[findleyr]

I don't think this needs to be a release blocker, since we can add option #2 at any time. Using and interface (#1) would be inconsistent with the rest of the API (and it's too late now).

On that note: should we just do #2?

@jba please correct me if I'm wrong and this should be a release blocker.