Loading ToolBench
Quality-aware read-only MCP server for Wolof speech corpus selection
Server has 8 well-named tools with complete input schemas and descriptions. All tools follow verb_noun naming (list_, search_, stats, etc.). Descriptions are present and contextual (avg ~80 chars), exceeding the 10-char minimum but below the 50-200 char LLM-optimized range. Input parameters are typed and described. However, output schemas are not explicitly documented in the visible code, responses are Pydantic models (CorpusAuditResponse, SearchResponse, etc.) but their field definitions are not shown. Error handling exists (ToolError raised with messages) but lacks recovery guidance. No tool annotations visible despite the import of ToolAnnotations. READ_ONLY constant defined but not applied to tool registrations.
Retrieve BibTeX citation and usage notes for one corpus.
Compare audit metrics across multiple corpus variants.
Retrieve audit observations for one corpus variant.
Filter rows by quality status using a local audit manifest.
List language/task/config variants with audit and verification state.
Plan a training set by language, task and quality level.
Full-text search over one corpus split.
Retrieve row counts, byte sizes and column names for one corpus split.
Output schemas not documented in visible code. Response types (CorpusAuditResponse, SearchResponse, etc.) are Pydantic models but their field definitions are not shown. LLMs cannot plan downstream tool calls without knowing what fields to extract.
Tool annotations (READ_ONLY constant) defined but not applied to tool registrations. The ToolAnnotations import and READ_ONLY definition exist, but no evidence they are passed to tool registration calls. Agents cannot determine which tools are safe to retry or have side effects.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Error messages lack recovery guidance. ToolError is raised with descriptive messages (e.g., 'corpus not found'), but no actionable next steps are provided. Errors should suggest alternative tools or corrective actions.
Descriptions are functional but brief (avg ~70-75 chars). LLM-optimized descriptions should be 50-200 chars and include WHEN to use the tool and any prerequisites. E.g., 'list_corpora' description could explain when to call it before other tools.
No pagination guidance in search tool. The 'search' tool accepts offset and length but does not document max result limits or whether a total_count is returned. Large result sets could exhaust context windows.