The latest articles on DEV Community by Ruturaj Shinde (@ruturaj_shinde_156652cc61). https://dev.to/ruturaj_shinde_156652cc61 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4110894%2F0e92be0e-534d-4032-ac85-f8d65d041e78.png https://dev.to/ruturaj_shinde_156652cc61 en Ruturaj Shinde Sat, 05 Sep 2026 08:30:54 +0000 https://dev.to/ruturaj_shinde_156652cc61/generic-apm-tools-couldnt-tell-me-why-my-mcp-tool-calls-were-failing-so-i-built-something-that-20h1 https://dev.to/ruturaj_shinde_156652cc61/generic-apm-tools-couldnt-tell-me-why-my-mcp-tool-calls-were-failing-so-i-built-something-that-20h1 <p>Every tracing tool I tried treated MCP tool calls like generic HTTP — "340ms, status: error" and nothing else. Couldn't tell me if the tool actually failed, if the client called a tool that doesn't exist, if the arguments failed validation, or if it was just a 401 (which is a normal part of the MCP auth handshake, not an error).</p> <p>So I built mcpobs. Drop it into your server (pip install mcpobs, then instrument(mcp)) and it classifies failures into categories that map to an actual fix, tracks progress on long-running tools while they're still running, and shows the downstream db/http/llm calls in the same trace.</p> <p>Apache-2.0, self-hostable, docker compose up and you're running — no account needed: <a href="https://github.com/Ruturajs4/mcpobs" rel="noopener noreferrer">https://github.com/Ruturajs4/mcpobs</a></p> <p>I also host it for people who don't want to run the pipeline themselves — invite-only for now at <a href="https://mcpobs.dev" rel="noopener noreferrer">https://mcpobs.dev</a>, since I'd rather work with a few early users than scale something unstressed.</p> <p>Would love to hear what's broken for MCP servers you're running that I haven't thought about yet.</p> mcp aiops ai