Loading ToolBench
A Model Context Protocol server for Excel file operations including generation, reading, modification, and remote loading of Excel files.
This server exhibits significant quality gaps across naming, descriptions, schema completeness, and error handling. While all 7 tools are registered with basic schemas, most lack production-grade descriptions and comprehensive parameter documentation. Tool names are reasonably verb-oriented (generateExcel, downloadUrl, read, addColumn, addRow, updateCell, load) but descriptions are minimal, often under 100 characters and lacking context about when to use each tool or what happens on failure. Parameter descriptions exist but are sparse (e.g., 'Excel文件id' for the 'id' parameter, no guidance on format or origin). No output schemas are documented. Error handling is absent, no guidance on recoverable vs. fatal errors, and no recovery suggestions. The server uses HTTP transport (positive) but shows no evidence of current MCP spec alignment (stateless _meta, tool annotations, structured output guidance, MRTR for user confirmation on destructive ops). Overall, this reads as a working but immature implementation suitable for internal use, not production agent integration.
根据ExcelId添加一列
根据ExcelId添加一行
根据Excel文件id，获取Excel文件的下载地址（注意！使用此mcp Server必须要调用此工具获取下载地址给用户）
根据输入生成一个新的Excel文件,并返回excel文件id，可以根据id进行后续操作。
使Excel Mcp Server从远端url中拉取一个Excel文件，并转换为服务器中的excel id，并通过excel id进行后续操作
根据ExcelId读取Excel的数据，返回的map中key是sheet页，value是表格数据
更新指定单元格的值
No documented output schemas for any tool. Agents cannot plan downstream calls or extract needed fields (e.g., does generateExcel return {id: string}? {id, sheetName, path}?). Critical for tool chaining.
Descriptions are minimal (mostly under 50 characters), written in terse Chinese, and lack LLM-friendly context on when to use each tool, prerequisites, and side effects. Tool descriptions should be 50-200 chars and answer: What does it do? When should I call it instead of similar tools? What happens if it fails?
Parameter descriptions are sparse and non-actionable. Examples: 'columnNum' says '列数，从1开始' (column number, starts from 1) but does not explain what happens if you insert at an invalid position, whether it shifts existing columns, or what the maximum is. Descriptions should state format, range, and constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
No error handling or recovery guidance. Tools provide no indication of success/failure conditions, what errors are retryable, or how to recover. E.g., load from invalid URL should return actionable error, not a stack trace.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot infer which operations modify state, which are safe to retry, or which require confirmation. read and downloadUrl should be marked readOnly; generateExcel, load, addColumn, addRow, updateCell should be marked destructive/write.
No confirmation step for destructive operations. generateExcel, addColumn, addRow, updateCell all modify state but have no dry-run or confirmation option. Agents can accidentally corrupt data.
Tool names use camelCase (generateExcel, addColumn) instead of snake_case (generate_excel, add_column). While not strictly incorrect, inconsistency with wider agent tooling conventions makes tool discovery slightly harder for LLMs.
'id' parameter appears in 5 tools but is never defined as an enum or constrained. Agents don't know what valid IDs look like (UUID? numeric? arbitrary string?). No hint on how to discover or list available ids.
'sheetName' parameter in addColumn, addRow, updateCell is marked optional or has no discovery guidance. Agents don't know how to enumerate available sheets or what default applies if omitted.
No pagination or result size limits documented for read tool. If an Excel sheet has 10,000+ rows, returning all of them blows the context window. Should cap at 50-100 rows with pagination tokens.