Loading ToolBench
A Salesforce CRM and Excel analysis assistant using Google Gemini AI with MCP (Model Context Protocol) tools for reading, writing, and managing Excel files. Provides a React frontend UI for chat-based interaction with spreadsheet data.
This MCP server has fundamental quality issues that prevent production use. Tool definitions lack complete parameter descriptions, output schemas are not documented, and error handling does not guide recovery. The average per-tool score is 35/100. STDIO transport limits remote accessibility. Code inspection reveals partial tool definitions with missing parameter documentation and no visible output schema declarations.
Append a new row (as dict) to sheet
Returns list of available Excel file names in excel_data/
Reads specified rows from a sheet
Reads entire sheet from an Excel file and returns table data.
Write value into specific cell in Excel sheet
Parameter descriptions are incomplete or missing across all tools. 'sheet_name' in read_sheet is described only as 'Sheet to read, default first sheet' but does not explain the sheet identifier format, how to discover available sheets, or what happens if the sheet does not exist. 'start_row' and 'end_row' in read_range lack guidance on whether indices are 0-based or 1-based in the description text (though schema shows 'integer', the description should state this explicitly for clarity).
No documented output schema for any tool. The rubric requires that tools document the return type and structure so LLMs can plan downstream calls. For example, read_sheet and read_range claim to return 'table data' but do not specify the format (array of objects? array of arrays? dict keyed by column name?). Without this, LLMs cannot reliably extract and pass data to subsequent tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Error handling does not guide recovery. The code in tool_manager.py shows generic error messages like 'MCP tool not available' and 'Error executing tool', but does not explain to the LLM what to do next. Per the rubric, errors should say 'User not found. Try search_users() first.' or provide actionable next steps. Current errors provide no recovery path.
No destructive operation confirmation or dry-run support. write_cell and append_row modify state, but the tool definitions do not indicate that these are irreversible or offer a way to preview/confirm before executing. The rubric requires destructive tools to support confirmation or dry-run to prevent agent mistakes.
Parameter 'row_data' in append_row is typed as 'object' with description 'New row as {colName: value}' but lacks detail on: (1) whether the keys must match existing sheet column names, (2) what happens if extra keys are provided, (3) what happens if required columns are omitted, (4) whether values are type-coerced or validated. This is a complex nested parameter that needs explicit constraints.
Tool descriptions are below the recommended 50-200 character range for LLM clarity. 'Reads specified rows from a sheet' (45 chars) is vague, it does not explain when to use read_range vs read_sheet, what the performance impact is, or what the return format is. 'Reads entire sheet from an Excel file and returns table data' (64 chars) is also thin.
No pagination or result-limiting guidance. If a sheet has 10,000 rows, read_sheet will attempt to load all of them into memory and return them to the LLM, risking context window exhaustion and token waste. The tool definition does not mention limits or offer pagination parameters like 'limit', 'offset', or 'max_rows'.
Security concern: no mention of file path traversal protection in the tool definition itself. While the implementation (_resolve_file) validates paths, the tool description does not document that only files in excel_data/ are accessible, which means LLMs cannot reason about security boundaries and might attempt to read files outside the sandbox.