mcp-tool-debugging

Diagnose failing MCP tool calls across transport, stdio framing, handler arguments, and installed package versions.

2|Updated Aug 2, 2026
One-click install
npx skills add https://github.com/Arasz/ai-raccoon --skill mcp-tool-debugging-arasz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: mcp-tool-debugging
Source: https://github.com/Arasz/ai-raccoon/tree/main/.ai-badger/skills/learned/software-development/mcp-tool-debugging
Command: npx skills add https://github.com/Arasz/ai-raccoon --skill mcp-tool-debugging-arasz

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? MCP tool calls that fail, error, or hang over stdio are hard to localize because the fault can live in four different places: the client transport, the server's stdio framing, the handler's argument shape, or the installed package version. This Skill provides an ordered diagnostic method that isolates each layer so you fix the actual cause instead of guessing. ## Core Features & Use Cases - Direct handler reproduction: Bypass MCP entirely by running the server's handler in its own interpreter with the exact tool arguments, splitting transport problems from handler bugs. - Stdio framing inspection: Detect stdout pollution from rich progress bars, print statements, or logos that interleave with JSON-RPC framing and hang clients until timeout. - Argument shape and version checks: Compare handler call signatures against the underlying API, probe the resolved uv-tool/pipx environment rather than the ambient one, and prefer functional probes over version floors. - Use Case: A semantica export_graph call times out at 300s in the client while returning in under 1s directly; the method traces it to a progress tracker writing to stdout and silences it via SEMANTICA_DISABLE_PROGRESS=1. ## Quick Start Debug why my MCP tool call to export_graph hangs in the client while the same call succeeds when run directly in Python.

Frequently Asked Questions about mcp-tool-debugging

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug an MCP tool call that times out?

First reproduce the handler directly in the server's own interpreter with the exact tool arguments. If the direct call works but the MCP call hangs, the problem is stdio framing, typically progress bars or print statements polluting stdout which carries the JSON-RPC protocol.

Why does my MCP server hang the client over stdio?

Over stdio, stdout is the JSON-RPC protocol channel, so any extra output like rich progress bars, tqdm, or print debug lines interleaves with the framing and hangs the client until its timeout. Grep the handler path for console renderers and set any kill-switch environment variable the library provides.

How do I test an MCP server installed with uv-tool or pipx?

Resolve the executable with shutil.which, find the interpreter beside it in the same bin directory, and shell out with subprocess.run using that interpreter. The ambient Python cannot import the isolated venv package, so in-process probes silently report false success.

Should I use a version floor or a functional probe for MCP dependencies?

Prefer a deterministic functional probe that warns and exits 0 over a version floor. A floor like pkg>=0.6.7 fails everyone until the upstream fix actually ships, while a probe only flags the genuinely broken installs.

Why does an MCP error get saved as valid data?

Some transports wrap results as a double-encoded envelope like {"result": "<json-string>"}, so an outer-only error check misses the inner error dict and treats it as data. Apply error checks to the inner decoded dict and the structuredContent envelope as well.