Loading ToolBench
MCP server that routes payloads to EC2 and Lambda backends, supporting utility tools like hashing, word counting, and basic arithmetic
This server exhibits severe definition quality issues across multiple dimensions. Tool naming lacks consistency and clarity (add, hello, goodbye appear multiple times with identical or near-identical functionality). Descriptions are present but minimal (average ~40 chars, well below the 194-char production baseline). Parameter documentation is sparse, many parameters lack descriptions entirely (e.g., tools 11-18 have parameters with no descriptions). Schemas are present but incomplete: parameter types exist but descriptions are often missing. The server exposes highly generic, demo-quality tools (hello, goodbye, add, hash) rather than domain-specific capabilities. Error handling is minimal, only hash_this and word_dictionary validate inputs; most tools have no error recovery guidance. The architecture shows tool duplication (add appears in both server.py and lambdaCode.py; hello/goodbye/timestamp exist in multiple variants). Composition is poor: tools like route_backend and compare_backends conflate multiple concerns and leak internal backend logic to the agent. No security-relevant scoping or permission declarations. Output schemas are not formally documented, responses are wrapped in custom {request_id, status, result, duration_ms} structures that are not standard MCP.
Add two numbers together.
Adds two numbers
Call both EC2 and Lambda backends and return which was faster.
Returns the current Unix timestamp
Say goodbye to someone.
Say goodbye
Returns the SHA-256 hash of a string
SHA-256 hash a message.
Severe tool duplication: 'add' defined twice (server.py + lambdaCode.py), 'hello' defined 3 times, 'goodbye' defined twice. This violates single-responsibility and confuses LLM tool selection.
Parameters in lambdaCode.py tools (tools 11-18) lack any description fields. LLMs cannot infer parameter meaning from names alone. Rule: 'Every parameter needs a description explaining what it controls.'
Tool descriptions are minimal and uninformative. E.g., 'Return greeting' (hello), 'Say goodbye' (goodbye), 'Adds two numbers' (add). Average ~30-40 chars vs. production baseline of 194 chars. LLMs need explicit WHAT, WHEN, and WHY to select tools correctly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | 2024-11-05+ | v1 |
Say hello to someone.
Return greeting
Returns a static hello message
Say hello world to someone.
Route a payload to either the EC2 or Lambda backend.
Returns the top N most frequent words from a sentence
Return the top-n most frequent words in a sentence.
Return the current Unix timestamp.
Returns a dictionary of word counts for a given sentence
Count word occurrences in a sentence.
Tool names violate verb-noun clarity rules. 'hello', 'goodbye', 'helloWorld' do not start with action verbs (should be 'send_greeting' or 'get_greeting'). Generic names like 'hello' provide no context for agent selection. Production baseline: 90% of A+ tools start with action verbs.
Output schemas are not formally documented. Tools wrap responses in custom {request_id, status, result, duration_ms} structures that deviate from standard MCP response patterns. LLMs cannot predict or chain on undocumented output schemas. Rule: 'Document the output schema.'
route_backend and compare_backends conflate multiple concerns: they route payloads to backends and handle multi-backend orchestration. This violates single-responsibility. Should split into separate tools or move routing logic server-side. Rule: 'Each tool should do exactly one thing.'
No error recovery guidance. Most tools (hello, goodbye, add, timestamp) have no error handling at all. Only hash_this and word_dictionary validate inputs. Rule: 'Error responses must tell the LLM what to do next.'
Demo-quality tools with no production value. Tools like 'add', 'hello', 'goodbye', 'timestamp' are toy utilities, not business-domain tools. Server lacks any EC2-related functionality despite being named 'EC2 MCP Server'. Unclear intended use case.
Inconsistent naming conventions across server.py and lambdaCode.py. server.py uses snake_case (word_dictionary, sorted_word_dictionary), while lambdaCode.py uses camelCase (wordDictionary, sortedWordDictionary). This inconsistency forces LLMs to reason about naming variants.
No parameter constraints or enums declared. Many parameters could accept enums (e.g., backend in route_backend should be enum ['ec2', 'lambda'], n in sorted_word_dictionary should have min/max bounds). Free-form strings invite hallucinated values.