Loading ToolBench
An MCP server implementation using Azure Functions as a serverless backend, providing tools via HTTP webhooks
Two tools with minimal definitions. Both have descriptions (10-20 chars baseline met), but lack depth for LLM selection. FibonacciTool and HelloTool have basic input schemas with type and description, but no output schema documentation. No error handling guidance, no parameter constraints (e.g., count bounds), no idempotency hints. Naming is generic ('FibonacciTool', 'HelloTool') rather than action-verb style (e.g., 'generate_fibonacci', 'send_greeting'). No composition guidance or chaining IDs. Security and audit logging absent.
Generates Fibonacci numbers up to the specified count.
Responds to the user with a hello message.
Tool names lack action verbs. 'FibonacciTool' and 'HelloTool' are nouns, not verbs. LLMs infer intent from verb-first names like 'generate_fibonacci' or 'send_greeting'. Current names are ambiguous and do not follow the verb_noun convention.
No output schema documented. FibonacciTool returns a comma-separated string; HelloTool returns a greeting string. LLMs cannot plan downstream calls or extract structured data without knowing the response format. Document return types explicitly.
FibonacciTool parameter 'count' has no bounds. Unbounded integers let LLMs pass absurd values (e.g., count=1000000) causing timeouts or memory exhaustion. Add min/max constraints in schema and description.
No error handling guidance. FibonacciTool returns 'Count must be greater than 0' on invalid input, but does not guide the LLM on recovery. Error messages should suggest next steps or valid ranges.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | <=2025-11-25 | v2 |
Tool descriptions are too brief (10-20 chars). Baseline for A+ tools is 50-200 chars. Current descriptions lack context on WHEN to use each tool, prerequisites, or what the output represents. Expand to guide LLM selection.