Loading ToolBench
Template for mcp server with connection to database
Server has 2 tools with basic schema definitions but significant quality gaps. Both tools have descriptions and input schemas present, but descriptions are minimal and lack actionable guidance. The search tool lacks output schema documentation. The set_data tool has a well-structured Episode object with proper field descriptions, but the overall descriptions do not explain when to use each tool or what the LLM should expect. Error handling is minimal, set_data catches exceptions generically but returns unstructured error strings rather than actionable recovery guidance. No output schemas documented, no tool annotations (readOnlyHint/destructiveHint), and parameter descriptions are sparse. Schema definitions are present but incomplete.
Allows user to search trough reference DB to find knowledge about existing company projects
Uploads data to database
Missing output schemas for both tools. The search tool returns a string with unstructured concatenated fields (UUID, Fact, valid_at, invalid_at). The set_data tool returns a simple string ('OK' or error message). Without documented output schemas, LLMs cannot reliably parse results or plan downstream calls.
Tool descriptions lack actionable context. The search description ('Allows user to search trough reference DB to find knowledge about existing company projects') does not explain what 'reference DB' is, what kind of knowledge is indexed, when to call this vs. other tools, or what format results are in. The set_data description ('Uploads data to database') is equally vague, does it insert, update, or replace? What is an 'episode'? Why would an LLM call this?
Missing destructive/readonly tool annotations. The set_data tool is a WRITE operation that mutates state (adds episode to database), but there is no destructiveHint annotation. The search tool is READ-only but has no readOnlyHint. These hints are critical for agents to understand safety and idempotency, LLMs need to know which tools are safe to retry and which have irreversible consequences.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Error handling returns unstructured error strings. The set_data tool catches exceptions and returns 'Error: {str(e)}', which provides no recovery guidance. An LLM does not know whether the error is retryable, user-fixable, or fatal. There is no distinction between validation errors, database errors, and timeout errors.
Search tool output is unstructured concatenation. The search tool concatenates result fields into a single string with no delimiter or structure: 'UUID: {uuid}Fact: {fact}Valid from: {...}Valid until: {...}---'. This forces the LLM to parse ad-hoc text, which is error-prone and wastes tokens. Should return a structured array of objects with typed fields.
No pagination or result limiting in search tool. The search code sets limit=5 internally, but this is not documented in the tool description. If a query matches thousands of results, the tool returns only 5 with no indication of total count or how to retrieve more. The LLM cannot page through results or know if additional data exists.
Tool naming could be more specific. 'set_data' is generic and does not clearly indicate 'add_episode' or 'create_episode'. The name alone does not convey that this creates a new episode entry in a knowledge graph. A clearer name would be 'add_episode' or 'create_knowledge_episode'.
Parameter 'query' in search tool lacks constraints. The description is just 'Search query string' with no guidance on length, format, or special characters. Should specify: minimum/maximum length, whether regex is supported, language constraints, etc.