How a subtle MCP server bug almost cost me $230 a month
Source: Dev.to
An important part of my job is to collect and distill feedback into recommendations for product and engineering teams. It isn’t as glamorous as traveling the world, but it’s a lot of fun: I get paid to experiment with brand‑new tech and directly influence the developer experience of our products.
Like any job, there’s a lot of routine work, especially the boring type. My ADHD brain hates that, and the top offender is processing tasks in a project‑management tool. To automate this, I built an AI agent that triages tasks, adds context, drafts comments, and moves items around—all through an MCP server.
The Unexpected Failure
The MCP server provides an update_task tool that accepts a custom_fields parameter. The agent called it, received a success response, but the custom fields remained unchanged. Repeating the call with different formats produced the same result: three success responses, zero actual updates. The API never indicated anything was wrong.
After several attempts, the agent investigated:
- Checked access permissions – still fine.
- Bypassed the MCP layer with
curl– the update succeeded, confirming the issue wasn’t permissions.
The root cause turned out to be that create_batch_request—a completely different MCP tool—is the only way to update custom fields. The update_task tool silently drops the custom_fields parameter (it isn’t in the tool’s schema) and still returns a success message.
Scale of the Problem
The bug manifested repeatedly:
| Metric | Value |
|---|---|
| Wasted tokens per failed attempt | ~93,000 |
| Average failed attempts per task | 2.3 |
| Cost per attempt (Claude Opus @ $5/MTok) | ~$0.47 |
| Cost per task | ~$1.08 |
Team‑level cost projection (5‑person team, 10 tasks per person per day)
| Timeframe | Per person | Team of 5 |
|---|---|---|
| Per day (10 tasks) | $10.80 | $54 |
| Per month (22 working days) | $238 | $1,190 |
| Per year | $2,856 | $14,280 |
These numbers assume every task hits the bug, which was true in my case because each triage task required custom‑field updates. Once the workaround (create_batch_request) was discovered, the waste dropped to zero.
Lessons Learned
- API Design – Add input validation. Reject or warn on unrecognized parameters instead of silently ignoring them. A single check could have saved every token and dollar in this story.
- Agent Implementation – Never trust a success response blindly. Verify state after every state‑changing call and surface any unexpected outcomes.
- Graceful Degradation vs. Silent Acceptance – Returning success for unsupported parameters isn’t graceful; it’s costly.
- Architecture Matters More with AI – Even though AI agents can adapt, solid software‑architecture principles (clear contracts, validation, observability) become even more critical.
Conclusion
This is Part 1 of The Inconsistency Tax, a three‑part series on what happens when AI agents meet inconsistent APIs. The next installment will explore why these failures aren’t random and why simply “wrapping an API in an MCP server” doesn’t automatically make it agent‑ready.