Loading ToolBench
Building AI MCP Servers - a collection of MCP server examples demonstrating calculator tools, knowledge base integration, and AI assistant integration with Gemini
This server exhibits significant quality gaps across naming, descriptions, schema documentation, and error handling. Seven tools are defined with basic descriptions, but most lack proper input schema documentation, have generic/incomplete descriptions, and contain critical naming and composition issues. Two tools have identical names ('add'), violating the single-responsibility principle. Parameter descriptions are sparse or absent. No error handling guidance is present. The server demonstrates basic functionality but falls well short of production quality standards.
Add two numbers together
Adds two integers together.
Divide the first number by the second. Raises error on division by zero.
Retrieve the entire knowledge base as a formatted string.
Multiply two numbers together.
Say hello to someone
Subtract two numbers. Subtract the second number from the first.
Duplicate tool name: two 'add' tools with identical signatures in different files (mcp_vs_function_calling/function_calling.py and alternate_simple_server/simple_calc_server.py). This violates single-responsibility and composition patterns, forces LLMs to guess which 'add' to call, and causes runtime ambiguity.
No output schemas documented for any tool. LLMs have no formal definition of what fields/structure to expect from responses. For 'divide', output is a float but not documented. For 'get_knowledge_base', output format (Q1, A1, Q2, A2) is invisible to schema. This forces LLMs to infer structure from examples or narrative descriptions, increasing parse errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Descriptions are too short or generic. Most tools (add, multiply, say_hello, get_knowledge_base) have descriptions under 40-65 characters that lack context for when to use the tool or how it differs from related tools. Baseline for A+ tools is 194 chars. Example: 'Add two numbers together' does not explain return type, precision, or constraints.
Parameter descriptions are minimal or absent context. E.g., 'a (int | float): first number' does not explain range, precision, or constraints. 'divide' parameter descriptions mention 'integer' when params are typed as float. No parameter has a description over 50 characters. Baseline is ~72 chars per param description in A+ tools.
No error handling guidance beyond basic try/catch blocks. For 'divide', the code raises ValueError on division by zero, but the tool description does not explain recovery (e.g., 'if result is None, operands may be invalid'). For 'get_knowledge_base', file-not-found and JSON-decode errors return strings like 'Error: Knowledge base file not found', not actionable for LLM recovery. Baseline pattern 'recovery-guide' requires 'what to do next' in error messages.
No parameter validation or constraint declarations. Numeric parameters (a, b in all calculator tools) have no min/max bounds, no precision specification, no handling of edge cases (Infinity, NaN, very large exponents). LLMs can pass absurd values (e.g., 1e308 or -1e308) causing overflow or precision loss. Baseline requires explicit bounds in descriptions.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in any tool definition. Marked risk as READ_ONLY in the evaluation, but this is not encoded in schemas. MCP spec 2026-07-28 supports tool annotations to help clients assess safety; absence means clients cannot auto-detect read-only tools.