Loading ToolBench
A health check for your MCP setup — measure the context tax and hygiene of your MCP servers
Three tools with mixed quality. 'add' and 'greet' are minimal but properly schematized. 'search' has exhaustive parameter documentation (11 params, all described) but suffers from bloated descriptions that violate token efficiency principles. No tool descriptions exceed 1024 chars, but 'search' description is deliberately verbose (900+ chars) to demonstrate 'overweight' definitions, this is anti-pattern for production. Schemas are present and typed for all tools. No error handling guidance, no output schemas documented, no tool annotations. Average param description length is strong (~150 chars for search params), but overall composition lacks production polish.
Add two integers.
Greet someone by name.
See the tool description; it says more than enough.
Tool descriptions lack actionable guidance. 'Add two integers' and 'Greet someone by name' do not explain WHEN to use these tools or what they return. LLMs need context for tool selection.
'search' tool description is deliberately bloated (900+ chars) to demonstrate anti-pattern. Production tools must keep descriptions 10 - 1024 chars and prioritize clarity over exhaustive detail. This wastes tokens and buries key information.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract results without knowing return structure. 'add' returns int, 'greet' returns str, 'search' returns unknown.
No error handling guidance. Tools do not explain what to do on failure (e.g., invalid query, corpus not found, timeout). Agents cannot self-correct without recovery hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All three tools are marked READ_ONLY in metadata but this is not exposed in schema or description for LLM reasoning.