Skip to main content
Glama
WilliamSmithEdward

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

Analyze VBA

xlide_analyze
Read-onlyIdempotent

Run static analysis on every VBA module in an Office file to return problems with module, line, column, code, and message. No Office installation required.

Instructions

Runs static analysis over every VBA module in an Office file and returns the problems with module, line, column, code and message. Needs no Office installation and runs nothing. Each file is measured against its own host's object model, so Word code is never judged by Excel's surface, and a Visual Basic 6 project against no host at all, because its code does not run in one. Call this after every VBA change and treat any problem at error severity as a build failure: fix it and analyze again until it is clean. Warnings are worth reading; some are style, some are the bug. Use offset and next_offset to read later findings.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNoSkip this many matching findings.
file_pathYesAbsolute path to the Office file.
max_resultsNoReturn at most this many findings.
module_nameNoReport only this module's problems. The whole project is still analyzed, so cross-module references still resolve.
min_severityNoLowest severity to report: 'error', 'warning' or 'information'.information

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.2
    • 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 matching findings.",
      +  "minimum": 0,
      +  "title": "Offset",
      +  "type": "integer"
      +}
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: no Office installation required, nothing is executed, host-specific object-model matching (Word vs Excel vs VB6), and the semantic weight of severities. The annotations already cover the read-only/idempotent safety profile, so this is a strong additive description rather than a restatement.

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?

Front-loaded with the core action and return shape, then guidance, then pagination. All sentences carry information, though the VB6 clause is niche and the sentence is longer than needed.

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?

An output schema exists, so return-value explanation is optional; the description nonetheless names the returned fields, and it covers purpose, constraints, severity policy, and pagination. Nothing needed to invoke it correctly 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 earns an extra point by explaining the pagination flow ('use offset and next_offset to read later findings'), which ties the input parameter to an output field. It adds nothing for min_severity or module_name beyond what the schema already 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?

States a specific verb (static analysis) and scope (every VBA module in an Office file), plus the exact shape of what it returns (module, line, column, code, message). The 'every VBA module in an Office file' scope implicitly distinguishes it from the source-level sibling xlide_analyze_source.

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 explicit when-to-use ('call this after every VBA change') and an actionable operating policy (treat error severity as a build failure, re-analyze until clean, read warnings). It does not name alternatives such as xlide_analyze_source or xlide_compile_check, so the routing decision is left partly to inference.

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