Primarily for the remote server, this is the minimal approach @omgitsads and I could find to enable us to store API errors on the context, so that we can use the error types and http status codes etc. to derive the nature of failures, so that we can understand if failed tool calls occur due to:

• rate limiting
• authentication issues
• 404
• 500s from API etc.

Without this knowledge it's hard for us to validate if changes break things or not.

This is additionally frustrated by the fact mcp-go currently doesn't propagate context through each next step, and so we have concluded that if we create a value pointer on the context, we can edit the values without needing to propagate the context, and we are using this to be able to implement the aforementioned middleware, which can then extract the errors and inspect them without logging them directly (as that would expose PII sometimes), and so it's best to be able to use Errors.Is checks. The middleware is not present in this repo (although we could also provide debug logs on the STDIO server using the server log message protocol, which would be a nice addition and likely a follow-up to this work).

Developer facing changes

Instead of directly returning mcp tool error responses, tool authors will call functions that will both return the tool error response, but will also add the actual errors to the context for later inspection.

return ghErrors.NewGitHubAPIErrorResponse(ctx, "failed to rerun workflow run", resp, err), nil

return ghErrors.NewGitHubGraphQLErrorResponse(ctx,
	"failed to get latest review for current user",
	err,
), nil

Additional change

Errors that are ones the user should be able to do something about need to be returned as failed tool calls and not as the error value, so I have fixed a few of those in this PR.

I have left things like failures to marhsall response json, as I would consider that a real error and likely something that requires developers to fix.