Loading ToolBench
A server that reconstructs table layouts from document records by matching query terms against record content and ranking matches by relevance.
The server defines a single tool 'document_layout_table_reconstruction' with a basic schema and minimal description. The tool lacks critical production-grade quality standards: the description is vague and under 50 characters, parameter descriptions are generic, output schema is not documented, there is no error recovery guidance, no input validation messaging, and no structure for pagination or result limits despite the tool processing unbounded record lists.
Reconstructs document layout table structure by matching query terms against records, ranking matches by relevance score, and extracting table rows.
Tool description is vague and under 50 characters. Description reads: 'Reconstructs document layout table structure by matching query terms against records, ranking matches by relevance score, and extracting table rows.' This does not answer WHEN to use this tool, what it returns, or what prerequisites exist. LLMs cannot reliably select this tool without context.
Tool name 'document_layout_table_reconstruction' is a compound noun phrase without a clear action verb. Per Arcade pattern guidelines, tool names should start with verbs (get_, create_, search_, list_, etc.) so LLMs infer intent before reading the description. 'reconstruct_table_layout' or 'search_and_rank_records' would be clearer.
Parameter 'records' lacks a meaningful description. The schema says 'List of document records with key-value pairs to search' but does not specify: required fields, data types of values, expected size limits, or examples of the structure. LLMs cannot construct valid input without clearer guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 27 | 2026-07-28+ | v2 |
Parameter 'query' description is generic: 'Search query to match against record content.' Does not specify: case sensitivity, regex support, word-boundary matching rules, minimum/maximum length, or how multi-word queries are tokenized. Code shows case-insensitive regex matching on word boundaries, but LLM sees no constraint in the description.
Output schema is not documented. The tool returns a dict with keys 'query', 'matches', 'table_rows', 'count', 'status' but no schema is visible in the MCP tool definition. LLMs cannot plan downstream operations or extract fields without knowing return types, e.g., what is the structure of a 'match' object in the 'matches' array?
No pagination or result limit handling. The tool processes unbounded record lists and returns all matches. Per Arcade pattern guidelines, tools returning lists should accept limit/offset and enforce a reasonable cap (20-50 items). Returning all matches risks context window explosion.
Error handling is minimal. The mcp_server.py catches all exceptions and returns {'status': 'error', 'error': str(exc)}. Per Arcade pattern guidelines, errors must guide recovery: 'records must be a list and query must be non-empty' tells LLM nothing about how to fix the input. Should return: 'records must be a list of dicts, query must be a non-empty string.'
No input validation constraints declared. Code validates at runtime but the schema and description do not state: minimum records count, maximum records count, query length limits, allowed characters, or what happens with empty results. LLMs have no visibility into constraints.
Missing chaining IDs and downstream context. The tool returns 'record_index' for ranked matches and identifies 'table_rows' but does not return the original record data. If an LLM needs to pass match data to another tool (e.g., extract or validate), it must re-lookup the original records using record_index, wasteful and error-prone.
Lack of idempotency guarantee. The tool's behavior depends on input order (records list) and scoring algorithm. Repeated calls with identical inputs should yield identical outputs, but the tool does not explicitly guarantee idempotency. Per Arcade patterns, idempotent operations prevent duplicate side effects on agent retries.