Loading ToolBench
MCP server for the VBA, forms, Power Query and sheets inside Office files
XLIDE presents a moderately well-structured MCP server for Office file manipulation with 28 tools. The majority of tools have explicit descriptions and parameter schemas, but quality is uneven across the toolkit. Critical strengths: all 28 tools are explicitly registered with names, descriptions, and typed input schemas in python/src/xlide_mcp/tools/*.py files. Parameters consistently include type and description fields. Output schemas are NOT documented in the source provided, this is a significant gap for LLM planning. Naming follows verb_noun convention (xlide_read_*, xlide_write_*, xlide_delete_*, xlide_list_*) which aids clarity. Critical weaknesses: (1) Many descriptions are too brief (20-50 chars) and lack actionable context; (2) No error handling guidance in descriptions, agents don't know what to do if a tool fails; (3) Irreversible operations (xlide_delete_*) lack confirmation/dry-run patterns; (4) No output schema documentation visible; (5) Input validation and constraint documentation is minimal; (6) No audit/permission checks evident in tool definitions. The server is domain-competent for Office file editing but lacks production-grade polish around error recovery, user safety, and LLM-optimized descriptions.
Analyze VBA code for errors and warnings
Build a catalog of definitions in VBA code
Create a new form in a project
Create a new module in a project
Create a new Office file with an empty VBA project
Delete a form from a project
Delete a module from a project
Delete a Power Query from a workbook
Report what this server can do on this machine
Irreversible delete operations (xlide_delete_module, xlide_delete_form, xlide_delete_query) lack confirmation/dry-run patterns and have minimal descriptions. Agents cannot reason about consequences or request confirmation before executing deletions.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields from responses. Critical for tools that return complex structures like xlide_project_info, xlide_analyze, xlide_catalog, and xlide_git_changes.
Tool descriptions are too brief (40-70 chars typical) and lack actionable context. Missing: WHEN to use this tool, WHAT it returns, prerequisites, error recovery guidance. E.g., xlide_delete_module: '26 chars, no context.' Should be 150-200 chars explaining deletion semantics and recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Export a module as a .bas or .cls file
Format VBA code according to style rules
Show VBA and Power Query changes between file revisions in git
Import a module from a .bas or .cls file
List Office files in the workspace roots
List all worksheets in an Excel file
List named ranges defined in a workbook
Read a project's structure: modules, forms, queries, sheets, and whether it is password-protected or signed
Read worksheet cells from an Excel file
Read a form's design as XML
Read a module's source code
Read a Power Query expression
Run a macro in a workbook and capture the result
Run unit tests in a workbook
Synchronize a module with an exported .bas or .cls file
Write values and formulas to worksheet cells
Write or replace a form's design
Write or replace a module's source code
Write or replace a Power Query expression
No error handling guidance. Descriptions do not explain what can fail, how the LLM should respond to failures, or what to try next. E.g., xlide_write_module accepts expected_content_token for concurrency detection, but no description explains what happens on token mismatch or how to recover.
Parameter descriptions lack constraints and formats. E.g., xlide_read_cells 'reference' param: no description of A1 notation syntax, range limits, or validation. xlide_run_macro 'timeout' param: no min/max bounds or what happens on timeout.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) evident in source. These are critical for agents to reason about side effects and retry safety. Destructive tools (delete, write) must be marked explicitly.
xlide_doctor tool name is non-standard and vague. 'doctor' is a domain-specific term not universally understood. Consider 'get_server_capabilities' or 'describe_server_features' to match verb_noun convention and be self-documenting.
expected_content_token pattern in xlide_write_* tools implements optimistic locking but is undocumented. No description explains what triggers a mismatch, what error is returned, or how the LLM should recover (retry read, merge, abort).
No permission/audit checks evident. No descriptions mention required permissions (e.g., 'requires write access to the Office file'). No evidence of audit logging for destructive operations.
xlide_run_macro and xlide_run_tests lack safety descriptions. No guidance on sandbox isolation, timeout handling, what happens if macro crashes, or side effects (file writes, external API calls). Macro execution is high-risk and requires extensive error guidance.