Skip to content

feat: log tool-call failures - #73

Open
timcharper wants to merge 1 commit into
tbxark:masterfrom
timcharper:feat/log-tool-call-failures
Open

feat: log tool-call failures#73
timcharper wants to merge 1 commit into
tbxark:masterfrom
timcharper:feat/log-tool-call-failures

Conversation

@timcharper

Copy link
Copy Markdown
Contributor

Problem

Only the initial connect path (addToMCPServer) logs errors. Once a client is up, tools/call failures are returned to the calling client but never appear in the proxy's own logs — so when a downstream server starts erroring, there's nothing on the proxy side to see it in.

Change

Wrap each registered tool's handler so failures are logged server-side with the client and tool name, using the existing slog conventions. The result and error are passed through unchanged, so behaviour toward the caller is identical.

level=ERROR msg="Tool call failed" client=slack tool=search_messages error="..."

Two lines of behaviour change; no config surface.

@gemini-code-assist

Copy link
Copy Markdown
Contributor

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

@tbxark tbxark left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for addressing the missing proxy-side visibility. There is one important gap before merging: MCP tool-originated failures are normally returned as a successful protocol response with CallToolResult.IsError == true and err == nil. The current wrapper only logs non-nil Go errors, so it still misses the common tool execution failure path described by this PR. Please log both cases while continuing to return the original result/error unchanged, and add coverage for protocol/transport errors, IsError results, and successful calls. Also, the repository consistently uses the structured log key err rather than error.

Comment thread client.go
toolName := tool.Name
mcpServer.AddTool(tool, func(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) {
result, err := c.client.CallTool(ctx, request)
if err != nil {

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also handle result != nil && result.IsError. MCP specifies that errors originating from a tool should be returned inside CallToolResult with isError: true, usually leaving err == nil; checking only err therefore misses the primary failure case this PR aims to expose.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gentle nudge, I addressed the feedback here.

@timcharper
timcharper force-pushed the feat/log-tool-call-failures branch 2 times, most recently from 6936196 to f122611 Compare August 5, 2026 00:08
Wrap proxied CallTool to log transport errors and MCP tool failures
(CallToolResult.IsError) at the proxy without changing returned results.

Co-authored-by: Cursor <cursoragent@cursor.com>
@timcharper
timcharper force-pushed the feat/log-tool-call-failures branch from f122611 to b4f1370 Compare August 5, 2026 00:09
@timcharper
timcharper requested a review from tbxark August 10, 2026 21:19
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.

2 participants