Loading ToolBench
A Model Context Protocol (MCP) server for searching and reading Excel files from your local PC
The Excel Search MCP server has clear tool naming and basic input schemas, but suffers from severely underdeveloped descriptions, missing output schema documentation, and no structured error handling guidance. Tool descriptions are generic (18-45 chars, well below the 50-200 char LLM-optimized target). Parameter descriptions exist but are minimal. No tool response structures are documented. Error handling returns JSON blobs without actionable recovery guidance. The server is functional but falls short of production-grade definition quality expected for confident agent integration.
Search and return a list of Excel files in the configured work directory.
Read Excel file data and convert it to JSON format.
Search for specific text within Excel file(s).
Tool descriptions are critically short (18 - 45 characters) and lack context for LLM selection. 'Search and return a list of Excel files in the configured work directory' (81 chars) is slightly better but still below the LLM-optimized 50 - 200 char baseline. None explain WHEN to use each tool vs alternatives, what structure they return, or how they chain.
Output schemas are NOT documented. The tools return JSON strings, but the caller cannot see what fields to expect (e.g., does list_excel_files_tool return {files: [...], count: N, total: N} or {success: bool, data: [...]}?). Without documented output shapes, LLMs cannot plan downstream actions or extract data reliably.
Error handling returns generic JSON with 'error' field but provides NO recovery guidance. Example: 'Tool execution failed: <error>' gives the LLM no direction on whether to retry, call a different tool, or ask the user. Error messages should classify as retryable/user-fixable/fatal and suggest next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
list_excel_files_tool has NO input parameters documented in the schema. Its description says 'configured work directory' but there is no way for an LLM to override the directory, recursive flag, or max_files limit. The tool reads from config_manager (server-side state), making it inflexible for multi-tenant or multi-directory scenarios.
Parameter descriptions are minimal or missing context. 'Path to the Excel file to search in' (file_path) lacks guidance on format (absolute/relative), character limits, or validation rules. 'Text to search for' (search_term) does not specify max length, encoding, or regex vs literal matching. These gaps force LLMs to guess.
No pagination support. If list_excel_files_tool or search_in_excel_tool return many matches, there is no page/offset/limit mechanism or total count documented. Returning 10,000 files in one response will blow context windows and degrade LLM reasoning.
read_excel_data_tool has max_rows as an optional integer with no bounds. An LLM could pass max_rows=1000000, causing memory exhaustion or timeout. Should specify a reasonable range (e.g., 1 - 10000) in both schema and description.