v0.26.0+ stdio mode panics: ToolDependencies not found in context

[JayRMorris]

Bug Description

After PR #1640 (inject deps via context instead of closures), the stdio server panics on any tool call:

panic: ToolDependencies not found in context; use ContextWithDeps to inject

Root Cause

In internal/ghmcp/server.go, NewMCPServer() creates deps at line ~196-204 and passes them to inventory.RegisterAll(), but the new context-based tool handlers created by NewServerToolWithContextHandler expect deps to be in context via MustDepsFromContext(ctx).

No middleware injects deps into context before tool handlers execute.

Fix

Add middleware after deps creation (~line 205):

ghServer.AddReceivingMiddleware(func(next mcp.MethodHandler) mcp.MethodHandler {
 return func(ctx context.Context, method string, req mcp.Request) (mcp.Result, error) {
 return next(github.ContextWithDeps(ctx, deps), method, req)
 }
})

Affected Versions

• v0.26.0
• v0.26.1

Reproduction

export GITHUB_PERSONAL_ACCESS_TOKEN=$TOKEN
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"0.1.0","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_me","arguments":{}}}' | ./github-mcp-server stdio

Workaround

Build from source with the above fix applied.

[SamMorrowDrums]

Thanks for the report, apologies for dropping the ball with that. The prior pattern had caused a performance regression due to the way the tool handler registration was working with the closure in remote server, so I was pretty laser focused on getting that shipped.

Thanks for the excellent report and suggested fix. I am AFK, but I assigned copilot and given your fairly surgical suggestion I fully expect a good end product, if it succeeds I will merge and tag.

[SamMorrowDrums]

Fix is in main @JayRMorris will test when I can.