Loading ToolBench
An MCP server that implements multimodal query planning and record ranking based on term matching and modality detection
Single tool with minimal definition quality. Tool name lacks action verb, description is sparse, input parameters lack individual descriptions, no output schema documented, and no error handling guidance. The server implements a basic keyword-matching algorithm but falls well short of production-grade agent tool standards. While the code is syntactically correct and the algorithm is sound, the MCP interface is severely underdeveloped.
Ranks records based on term matching against a query and organizes them by modality for retrieval planning
Tool name does not start with action verb. 'multimodal_query_planning' is a noun phrase describing a concept, not an action. Should be 'rank_by_modality', 'search_records_by_modality', or 'plan_multimodal_query' to signal the action taken.
Input parameters 'records' and 'query' lack individual descriptions in the schema. The tool schema shows types (array, string) but no description field explaining what each parameter controls, its format, constraints, or when/how to use it.
No output schema documented. The tool returns a dict with 'query', 'matches', 'plan', 'count', 'status' fields, but there is no formal schema definition visible in the MCP registration showing structure, types, or field descriptions. LLMs cannot infer downstream field availability without explicit schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 30 | 2026-07-28+ | v2 |
Tool description is only 118 characters and lacks clarity on when to use this tool vs alternatives, what the output fields mean, and how 'modality' is determined. Current description: 'Ranks records based on term matching against a query and organizes them by modality for retrieval planning', no mention of how modality is extracted, what 'plan' structure contains, or error cases.
No error handling guidance in tool definition. The code catches generic exceptions and returns {'status': 'error', 'error': str(exc)}, but the schema has no documented error cases, recovery guidance, or classification (retryable vs fatal). Per pattern:recovery-guide, errors must tell the LLM what to do next.
Input validation error message lacks specificity. When 'records' is not a list or 'query' is empty, the server returns 'records must be a list and query must be non-empty'. This is actionable but does not tell the LLM what actual values were received or how to fix them (e.g., 'Invalid query: received empty string. Query must be 1 - 1000 alphanumeric characters.').
No pagination or result limits documented. The tool can return an unbounded 'matches' array. If 'records' contains thousands of items, the response grows without bound, risking context-window exhaustion.
Modality extraction logic is opaque. The code extracts modality via record.get('modality', 'text') but the tool description does not explain: (a) what field name to use in records, (b) what modality values are expected or valid, (c) what happens if modality is missing (defaults to 'text' but LLM is not told).
No mention of supported query syntax or search behavior. The code lowercases and tokenizes via regex '[a-z0-9]+', but LLMs and users may expect: phrase search, boolean operators, wildcards, or field-specific matching. Current behavior is simple term intersection, but this is not documented.