Loading ToolBench
MCP server for Excel file processing and conversion to JSON with session-based reading capabilities
Critical gaps across all dimensions. Tool definitions lack coherent descriptions, parameter descriptions, and schema specificity. The server exposes 4 tools with significant quality issues: (1) openFile has a basic description but missing details about return structure; (2) foreach has minimal description and no documentation of what 'header and current line content' means in structure; (3) reset has a description in Chinese only, incomprehensible to English-speaking LLMs; (4) excel2Json has a Chinese description ('将excel文件转换成json') entirely unusable for LLM selection. Parameter descriptions are sparse or missing entirely. No output schemas are documented. The server follows a stateful session pattern (sessionId management) that is not well-documented for composition. Error handling is not visible in the provided code. Overall, this server would confuse an LLM trying to decide when to use foreach vs excel2Json, or what to expect from each tool's output.
将excel文件转换成json
Read next line from the opened session. Returns header and current line content.
Open an Excel file and create a read session. Returns a sessionId.
Reset the reading pointer to the beginning (0) for the given session.
Two tools describe Excel conversion functionality (openFile + foreach vs excel2Json) with conflicting or unclear purposes. LLMs cannot disambiguate: does the agent open a file and iterate rows, or convert the entire file at once? This violates the single-responsibility principle and forces the LLM to guess.
reset and excel2Json descriptions are in Chinese ('重置', '将excel文件转换成json'), making them completely unusable for English LLMs. The server exposes non-English tool descriptions, which breaks discoverability and selection logic.
foreach returns 'header and current line content' but no documented output schema. An LLM cannot know: is the output a JSON object with 'header' and 'line' fields? An array? A string? This breaks downstream tool composition and wastes tokens on exploratory calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Parameter 'type' in openFile has description 'Reading mode: basic or row-object' but should clarify the format as an enum and explain what each mode returns. The description is descriptive but incomplete, no guidance on when to use which mode.
openFile returns a sessionId but the contract is undocumented: How long is the session valid? Can multiple sessions coexist? What happens if the file is deleted while a session is open? These details force the LLM to make unsafe assumptions.
foreach lacks error documentation. What happens when sessionId is invalid, expired, or the session has reached EOF? Does it return an error object, an empty line, or a special marker? LLMs cannot handle edge cases without explicit guidance.
offset parameter in openFile has no bounds or validation guidance. An LLM could pass offset=999999, causing performance issues or undefined behavior. Parameter description should specify valid range (e.g., '0 - 1000000, default 0').
No output schema documentation for openFile (sessionId return type, structure). LLMs cannot plan downstream calls without knowing the format and fields returned.