xlide-excel-word-powerpoint-access-office-vba-mcp

Overview Schema Source Related Servers Discussions Admin

Run a macro

xlide_run_macro

Destructive

Execute an existing macro in an Office file under a deadline. Returns the procedure's result, logs, and VBA error details, and terminates the app on timeout.

Instructions

Runs a procedure that already exists in an Office file, in an application this server starts and owns, under a deadline. Windows only, with the application installed. The document opens read-only unless read_only=false, and closes without saving unless save=true. Returns the procedure's return value, anything it logged, and, on a VBA error, the error number and message. The failing line and call stack come from instrumentation applied to injected source, so a procedure already in the document does not carry them; run the same code through xlide_run_vba when you need them. A run that exceeds its timeout reports 'timeout' and the application is terminated. Ask the user before running a macro that changes data.

Input Schema

TableJSON Schema

Name	Required	Description
`args`	No	Arguments, in order. Scalars only.
`save`	No	Save the document after the run. Needs read_only=false.
`timeout`	No	Seconds before the run is terminated.
`file_path`	Yes	Absolute path to the Office file.
`procedure`	Yes	Procedure to call, as 'Proc' or 'Module.Proc'.
`read_only`	No	Open the document read-only. False lets the macro change it.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 20, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description reveals key behaviors: the document opens read-only by default, closes without saving unless save=true, returns the procedure's return value and logs, reports timeout by terminating the application, and lacks call-stack info for existing procedures. This is rich, accurate context that annotations alone do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact despite covering environment constraints, defaults, return values, error behavior, an important limitation, and a safety instruction. Every sentence adds useful information, and the core action is stated first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the description covers prerequisites, default behaviors, return values, timeout semantics, error limitations, and the safe alternative. The output schema handles return-value structure, so nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics for parameters such as read_only and save by explaining their interaction, and for timeout by describing what happens on expiry. This goes beyond the schema's field-level definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it runs a procedure that already exists in an Office file. It also distinguishes itself from the sibling xlide_run_vba by noting that call-stack instrumentation applies to injected source, not to procedures already in the document.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly names xlide_run_vba as the alternative when failing line and call stack are needed, giving a concrete selection condition. It also gives environment prerequisites (Windows, application installed) and instructs the agent to ask the user before running a data-changing macro.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server