Loading ToolBench
The server exposes a single tool 'example' with critically inadequate definition quality. The tool has a description ("Simple example tool to demonstrate MCP server functionality.") but this is vague and non-actionable for LLM selection. The tool does not declare what it actually does beyond 'demonstrates MCP server functionality', it makes an HTTP GET request to an external API_BASE_URL endpoint, but this behavior is never documented in the tool definition. There is no parameter descriptions, no output schema documentation, no error handling guidance, no information about when to call this tool vs. alternatives. The implementation shows the tool is stateless and read-only (fetches from /example endpoint), but these properties are not exposed via tool annotations. By baseline calibration, a tool with zero input schema and generic 20-40 char description that lacks actionable context cannot score above 20-30.
Simple example tool to demonstrate MCP server functionality.
Tool 'example' has NO input schema at all (empty {}). This violates pattern:tool and makes the tool unusable by agents, they cannot understand what parameters (if any) are accepted.
Tool description is generic and non-actionable (21 characters, below 30-char minimum for context). 'Simple example tool to demonstrate MCP server functionality.' does not answer: What does it do? When should the LLM call it? What does it return? For LLM selection to work, descriptions must be 50-200 chars and explicit about behavior.
No output schema documented. The tool returns response.json() from an external API call, but LLMs have no way to know what fields to expect, breaking downstream reasoning and chaining.
Tool makes external HTTP requests with no timeout, retry logic, or error classification. Network failures produce raw exceptions (response.raise_for_status()) with no recovery guidance for the agent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 26 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 28 | - | v1 |
API_BASE_URL is required but no validation or error message guides the agent if it is missing. Tool will fail at runtime with KeyError.
Tool uses bearer token (API_KEY) injected from environment, but this is never documented in tool definition. Agent has no visibility into authentication requirements or scope.
Tool naming 'example' is non-action-oriented and provides zero semantic meaning. Does not start with a verb. Baseline names follow verb_noun pattern (get_, create_, search_, etc.). 'example' could mean anything.