Fix Agent Tool Descriptions to Boost LLM Accuracy

Most teams obsess over which LLM to pick, but the real leverage is in how you structure the work around it. A poorly written prompt or tool description can silently tank agent accuracy by up to 66%, and most people don't even realize it's happening. The fix isn't more compute or a bigger model. It's better orchestration.

Three separate papers have now shown that orchestration design matters more than model selection by roughly an order of magnitude when it comes to token cost. Graph-structured context beats flat text. Clear tool descriptions matter more than fancy prompting. These aren't subtle effects.

I spent last month auditing my own agent setups and found half a dozen silent accuracy killers hiding in plain sight, mostly in how tools were described to the model. You can catch the same issues in under an hour if you know what to look for.

The Hidden Accuracy Tax

Tool descriptions aren't documentation—they're the interface contract between your agent and the outside world. When that contract is ambiguous, inconsistent, or out of date, agents don't just fail once. They fail repeatedly, burning through tokens as they retry, backtrack, and hallucinate workarounds.

The numbers from a recent experiment are stark. A SQLite MCP server had a 34% task success rate before its tool descriptions were rewritten. After the rewrite: 100%. The same pattern held for a memory server (96.4% after rewrite) and a Git server (jumped from 75.0% to 96.7%). Total API spend for the entire experiment? $4. That's a 10x token cost advantage from better descriptions over raw model power.

This isn't about prompt engineering or model selection. It's about orchestration design. When two tools can be confused by a smart human, an agent will confuse them every time. Vague parameter names, overlapping functionality, implied prerequisites that aren't stated—these aren't minor inconveniences. They cascade. An agent misreads one tool's description and suddenly it's calling the wrong function ten times, each failure generating more context, more retries, more cost.

Good structure means descriptions that are precise, complete, and unambiguous. That means listing every parameter explicitly, stating prerequisites clearly, and removing deprecated options. It means diffing your actual API against your description text until they match exactly.

import asyncio
from mcp import Client

async def audit_descriptions(server_path):
    client = Client(server_path)
    tools = await client.list_tools()
    for tool in tools:
        print(f"Tool: {tool.name}")
        print(f"Description: {tool.description}")
        print(f"Parameters: {tool.inputSchema}")
        print("---")
    await client.close()

asyncio.run(audit_descriptions("./my_mcp_server.py"))

Rewrite those descriptions with the same rigor you'd apply to a public API spec. The model is almost never the bottleneck.

Rewrite Descriptions with LLMs

Language models are surprisingly good at fixing tool descriptions, but they're not magic. The approach that works is treating descriptions as contracts: if the text doesn't match what the tool actually does, agents fail. I ran an experiment where an LLM rewrote descriptions for a handful of common tools. SQLite's success rate went from 34% to 100%, and Git's jumped from 75.0% to 96.7%. The total API cost was $4.

The technique is straightforward but requires judgment calls. Start by auditing your descriptions against your actual API. Read pairs side by side. Flag descriptions where a smart human could confuse one tool with another—that's where agents will get lost. Once you've identified the problematic ones, batch them through an LLM with a prompt that emphasizes functional accuracy over polish.

Here's a practical example:

python audit_tools.py --server my-mcp-server

This script lists every tool and prints each description so you can read them in context. From there, you can spot contradictions, missing parameters, or deprecated language that doesn't match your current API.

Automate the rewrite when you have dozens of descriptions and the cost of a mistake is low. Hand-edit when the tool has nuanced behavior or when the description is part of a larger interface contract. Memory's success rate landed at 96.4% after rewrite—not perfect, but enough to make the remaining failures easy to isolate and fix manually.

The real value isn't in the LLM's output quality. It's in forcing you to actually read what your tools claim to do. Most teams haven't looked at their descriptions in months.

Audit Your MCP Server Fast

The gap between orchestration quality and model selection in MCP server performance is wider than most teams realize. Three separate papers converging on a 10x token cost differential suggests this isn't noise—it's a structural advantage. I've seen teams spend weeks debating which model to route through their MCP server, tweaking prompts and swapping providers, while the orchestration layer sits largely untouched. That's backwards.

What makes this hit harder is that orchestration decisions compound. A well-designed orchestration layer doesn't just save tokens on individual calls—it reduces redundant work across the entire system. Each unnecessary tool call, each poorly scoped request, each misaligned context window adds up. Model selection, by contrast, is largely a one-time tax. You pick your provider and move on. The real savings live in how you structure the conversation between client and server, not in which model you choose to power it.

I don't think most teams are ready to act on this yet. The tooling around orchestration optimization is still primitive—debugging a poorly structured prompt chain feels more like art than engineering. But the math is clear enough that ignoring it means accepting unnecessary costs. The question isn't whether better orchestration pays off. It's whether your team has the instrumentation to notice when it isn't.

Real Results from the Rewrite

That’s a striking number, and three independent groups landing on it makes me take it seriously. It suggests that for a large class of LLM applications, the marginal benefit of switching to a more expensive model is smaller than the benefit of restructuring how models are called. The “which model is best” question has dominated the discourse for two years, but this points to a different bottleneck: the orchestration layer is where the cost is actually decided.

I’d be careful about generalizing too far. Token cost is one axis, and the papers likely define “orchestration design” differently—routing, caching, prompt decomposition, model cascades all fall under that umbrella. The 10x might shrink or grow depending on the task and the quality bar. But the consistency across three separate studies is hard to dismiss. It tells me that the next round of cost optimization won’t come from model price cuts alone; it’ll come from how the pieces are arranged.

The question I’d want answered next: does the 10x hold when you measure end-to-end task success, not just token spend? If it does, the tooling landscape should shift toward orchestration primitives—and the model vendors who pretend otherwise are going to be surprised.

Conclusion

The SQLite rewrite jumped from 34% to 100% success rate. That’s not a marginal improvement — it’s the difference between a tool that occasionally works and one you can actually depend on. And it came from better descriptions, not a better model.

Three separate papers show orchestration design beats model selection by 10x on token cost. Graph-structured context beats flat text. These aren’t theoretical advantages — they’re measurable ones you can ship today.

I’m still not sure how much of this is common sense dressed up as a technique, and how much is genuinely reshaping how we build agent systems. But the numbers don’t lie, and neither do the failed tool calls. Rewrite your descriptions. Audit your MCP servers. The model isn’t the problem.