Loading ToolBench
MCP server that works as a meta-data snippet manager
Scoring was not performed
Missing output schema documentation in tool definitions. While Zod schemas are defined in src/schemas.ts, the tool registration in stdio.js and streamableHttp.js does not surface return types. LLMs cannot infer what fields to expect in responses, forcing them to guess at downstream tool chaining and making errors more likely.
Parameter descriptions lack actionable constraint details. For example, 'metadataNames' is described only as 'Array of metadata names to associate with snippet' without specifying: minimum array length, character limits per name, whether duplicates are allowed, or error behavior if a name doesn't exist. This forces LLMs to guess valid input ranges.
No error handling guidance in tool descriptions. Tools do not document what errors they might return, when they are retryable, or how the LLM should respond. For example, delete_snippets does not explain whether deleting a non-existent snippet raises an error or silently succeeds, forcing the agent to handle unexpected behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 25 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Confusing tool name proliferation for metadata queries. Tools like get_metadata_tree, get_metadata_forest, get_metadata_siblings_forest, get_metadata_siblings, and get_metadata_path are thematically related and poorly differentiated by name. LLMs will struggle to pick the right one. Consider consolidating with a single parametrized get_metadata tool or renaming for clarity (e.g., get_metadata_as_tree, get_metadata_as_forest).
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). The Risk column in the spec shows clear classifications (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE), but these are not exposed to the LLM as tool annotations. This prevents agents from reasoning about safety and side effects without reading full descriptions.
Generic descriptions for list tools. list_snippets and list_metadata have no parameters and descriptions of only 'List all snippets in the database' and 'List all metadata entries'. No indication of pagination, result limits, or result structure. For production use, LLMs need to know if calling these returns 10 or 10,000 items.
Incomplete parameter validation description for date filtering. get_snippets_by_date accepts 'date' as optional but does not specify the date format (ISO 8601? natural language? Unix timestamp?). The parameter description must be: 'Date in ISO 8601 format (YYYY-MM-DD). If omitted, defaults to today.'
No batch operation limits documented. Tools like create_metadata_forest and delete_metadata accept arrays but do not specify maximum array size. An LLM could attempt to create 1000 metadata nodes in one call. Tool descriptions should state: 'Maximum 50 items per request.'
Missing idempotency guarantees. Tools like create_snippet do not state whether calling with the same inputs twice will return the same result or throw an error if the snippet already exists. For agent retry logic, this must be explicit: 'Idempotent: calling twice with the same name will return the existing snippet.' or 'Error if snippet exists.'