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

by WilliamSmithEdward

Overview Schema Source Related Servers Discussions Admin

Python

Local

Analyze VBA source

xlide_analyze_source

Read-onlyIdempotent

Instructions

Runs static analysis over VBA source you are holding, before it is written to a file. Use it to check code you have just generated: it costs nothing, needs no file, and catches the compile errors that would otherwise surface in front of the user. Pass host so the code is measured against the right object model, and file_path instead if the code is destined for a file that already exists, which resolves calls into the rest of that project. Use offset and next_offset to read later findings from a long result.

Input Schema

Name	Required	Description	Default
`host`	No	'excel', 'word', 'powerpoint' or 'access'. Empty checks the language alone, with no host object model.
`kind`	No	'standard', 'class', 'document' or 'userform'.	standard
`offset`	No	Skip this many findings.
`source`	Yes	The VBA source to check.
`file_path`	No	An existing Office file this module belongs to. Its other modules are read as context, so calls into them resolve; only this source is analyzed. Overrides host.
`max_results`	No	Return at most this many findings.
`module_name`	No	Name to report problems against.	Module1

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.2.4Oct 14, 2026

changedInput schema / properties / file_path / description

Previous value: -"An existing Office file this module belongs to. Its other modules are analyzed alongside, so calls into them resolve. Overrides host."New value: +"An existing Office file this module belongs to. Its other modules are read as context, so calls into them resolve; only this source is analyzed. Overrides host."

Changed2 schema fields changedv1.2.2Sep 30, 2026

addedInput schema / properties / max_results

Added value: +{
+  "default": 300,
+  "description": "Return at most this many findings.",
+  "maximum": 300,
+  "minimum": 1,
+  "title": "Max Results",
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Skip this many findings.",
+  "minimum": 0,
+  "title": "Offset",
+  "type": "integer"
+}

First observedv0.1.0Sep 20, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, but the description adds real context: it costs nothing, needs no file, catches compile errors before they reach the user, and explains that file_path pulls in the rest of a project's modules as context. This meaningfully exceeds the annotation baseline.

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

Conciseness4/5

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

Four front-loaded sentences, each carrying distinct information (value proposition, two operating modes, pagination). Slightly dense but no filler; the 'costs nothing, needs no file' clause earns its place as a selection criterion.

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

Completeness4/5

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

With an output schema present, return values need not be described, and the description covers both input modes plus continuation. It leaves the relationship to the nearest siblings (xlide_analyze, xlide_compile_check) unstated, which is the only meaningful gap for a 7-parameter analysis tool.

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, but the description adds semantics the schema does not: file_path resolves calls into sibling modules and overrides host, and host selects the object model. The reference to 'next_offset' is slightly loose since it is not an input parameter (likely a returned cursor), but the intent is clear.

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

Purpose4/5

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

States a specific verb (runs static analysis) and resource (VBA source held in memory, before write), and implicitly distinguishes itself from file-based analysis via 'before it is written to a file'. It does not, however, name any sibling such as xlide_analyze or xlide_compile_check, so the agent must infer the boundary itself.

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

Usage Guidelines4/5

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

Gives clear usage context ('check code you have just generated') and conditional guidance for host vs file_path and for pagination. It stops short of naming which alternative tool to use when the code is already on disk or when a full compile is wanted, so no explicit when-not routing is provided.

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

Deploy Server