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

Overview Schema Source Related Servers Discussions Admin

Analyze VBA source

xlide_analyze_source

Read-onlyIdempotent

Run static analysis on VBA source before it is written to a file to catch compile errors early; optionally check against a host object model or an existing project file.

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

TableJSON 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 analyzed alongside, so calls into them resolve. Overrides host.
`max_results`	No	Return at most this many findings.
`module_name`	No	Name to report problems against.	Module1

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

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.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavior: no file required, no cost, errors surface here rather than in front of the user, and file_path resolves calls into the surrounding project. It does not describe result shape or error reporting, which keeps it at 4.

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 a distinct payload (purpose, when to use, host vs file_path, pagination). The 'costs nothing, needs no file' clause slightly overlaps with the opening framing, which is the only real waste.

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?

With an output schema present and 100% parameter description coverage, the description need not cover returns. It still covers when to call, the host/file_path trade-off, and how to page through a long result, which is everything an agent needs for a 7-parameter read-only 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 decision-level meaning the schema does not: host is for measuring against an object model while file_path overrides host and pulls in sibling modules. It also explains the offset/next_offset pagination flow, which the schema only half-documents.

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 opening sentence names a specific verb and resource ('Runs static analysis over VBA source') and immediately scopes it: source held in memory, before it is written to a file. That scope is exactly what separates it from the file-based 'xlide_analyze' sibling, so an agent can route without opening either schema.

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 a concrete when-to-use ('check code you have just generated') and clarifies it is free of side effects ('costs nothing, needs no file'). It does not explicitly state exclusions or name the alternative tool to use for already-saved modules, so it stops short of the 5 bar.

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

Deploy Server