Loading ToolBench
MCP server for managing VBA projects in Microsoft Office applications (Excel and Access). Provides tools to list, read, write, create, delete, and export VBA modules in open Office documents.
This MCP server provides 16 well-structured tools for VBA manipulation in Access and Excel. All tools are explicitly registered with [McpServerTool] attributes and have descriptions. However, the server has significant gaps in schema completeness, error handling guidance, and parameter descriptions that prevent it from reaching production-grade quality. Input schemas exist but are minimal, most parameters lack formal type constraints, enums, and detailed descriptions. Error messages are returned as plain strings rather than structured responses with recovery guidance. The tool set is well-composed (clear single responsibilities, good naming) but lacks pagination support for list operations and confirmation patterns for destructive operations.
Create a new VBA module in an Access database. The database must be open in Access.
Create a new VBA module in an Excel workbook. The workbook must be open in Excel.
Delete a VBA module from an Access database. IMPORTANT: This operation is irreversible. Make sure to backup your file before using this tool. Cannot delete document modules (Forms, Reports with code-behind).
Delete a VBA module from an Excel workbook. IMPORTANT: This operation is irreversible. Make sure to backup your file before using this tool. Cannot delete document modules (ThisWorkbook, Sheet modules).
Export a VBA module from an Access database to a file (.bas, .cls, or .frm)
Export a VBA module to a file (.bas, .cls, or .frm)
Input schemas lack formal constraints and enums. All file path parameters accept free-form strings with no format validation, pattern matching, or example guidance. moduleType parameter in create_* tools accepts 'standard', 'class', 'userform' but not declared as enum, LLMs may hallucinate invalid types like 'document' or 'sheet'.
Output schemas not documented. Tools return JSON-serialized objects (e.g., {count, databases} for list_open_access_files, {file, moduleCount, modules} for list_access_vba_modules) but LLMs have no formal schema definition of expected fields, types, or structure. This forces LLMs to parse unstructured output and guess at field names.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
List all VBA modules in an Access database. The database must be open in Access.
List all procedures in an Access VBA module with detailed metadata including name, type, line numbers, and access modifiers
List all VBA modules in an Excel workbook. The workbook must be open in Excel.
List all procedures in a VBA module with detailed metadata including name, type, line numbers, and access modifiers
List all currently open Access databases that contain VBA projects (.accdb, .mdb)
List all currently open Excel workbooks that contain VBA projects (.xlsm, .xlsb, .xls)
Read the complete VBA code from a module in an Access database. The database must be open in Access.
Read the complete VBA code from a module. The workbook must be open in Excel.
Write VBA code to a module in an Access database, replacing its entire content. IMPORTANT: This operation is irreversible. Make sure to backup your file before using this tool. The database must be open in Access.
Write VBA code to a module, replacing its entire content. IMPORTANT: This operation is irreversible. Make sure to backup your file before using this tool. The workbook must be open in Excel.
Error handling returns plain-text error messages with no guidance on recovery or retry semantics. Examples: 'Error: Database not found or not open: {filePath}' (user-fixable, should suggest 'Open the file in Access first'), 'Error: {ex.Message}' (opaque, LLM cannot self-correct). No distinction between retryable errors, user-fixable errors, and fatal errors.
Destructive operations (write_*_vba_module, delete_*_vba_module) lack confirmation patterns or dry-run support. Descriptions warn 'This operation is irreversible' but provide no mechanism for the agent to request confirmation before executing. An LLM mistake could silently corrupt or delete user code.
List operations (list_access_vba_modules, list_excel_vba_modules, list_access_vba_procedures, list_excel_vba_procedures) do not support pagination. If a database has hundreds of modules or procedures, returning all items in one response will bloat the LLM context, increase latency, and degrade reasoning. No limit or offset/page parameters.
Parameter descriptions in code use [Description] attributes but do not include format specifications, constraints, or examples. For example, 'Full file path to the Access database' lacks a pattern (e.g., must end with .accdb or .mdb), expected length, or valid examples. This forces LLMs to infer valid inputs.
Tool composition is good (single-responsibility tools with clear naming), but read-only discovery tools (list_*) do not return IDs/references that downstream modify tools need. For example, list_access_vba_modules returns a list of module names and types, but does not include metadata needed to chain to read_access_vba_module, write_access_vba_module, or delete_access_vba_module without extra parsing.