Skip to main content
Glama
WilliamSmithEdward

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

List modules

xlide_list_modules
Read-onlyIdempotent

List VBA modules in an Office file with name, kind, line count, and content_token for guarded writes. Paginate large projects using offset and max_results.

Instructions

Lists the VBA modules in an Office file: name, kind (standard, class, document or userform), line count, and a content_token to pass to a guarded write. xlide_project_info returns this and more in one call; use this one when the file is already known and only the module list is wanted. Use offset and next_offset to read large projects in pages.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNoSkip this many modules before a page.
file_pathYesAbsolute path to the Office file.
max_resultsNoReturn at most this many modules.

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 modules.",
      +  "maximum": 300,
      +  "minimum": 1,
      +  "title": "Max Results",
      +  "type": "integer"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Skip this many modules before a page.",
      +  "minimum": 0,
      +  "title": "Offset",
      +  "type": "integer"
      +}
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered; the description adds genuinely new context by noting the returned content_token is meant to be passed to a guarded write, plus that large projects must be paged. It stops short of describing limits or what the write guard actually enforces.

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?

Three sentences, each carrying distinct load: what is returned, when to prefer this tool over the sibling, and how to page. The returned-field list is front-loaded and the alternative routing comes before the pagination detail.

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 values need not be spelled out, yet the description still names the key fields and the one non-obvious one (content_token). Routing, paging and return shape are all covered; nothing an agent needs to call this 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 offset, max_results and file_path are already documented, which sets the baseline at 3. The description adds meaning beyond the schema by explaining the offset/next_offset pairing as a paging loop, which the schema alone does not convey.

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 and resource (lists VBA modules in an Office file) and enumerates exactly what is returned: name, kind, line count, content_token. The kind values are even spelled out (standard, class, document, userform), so the agent knows the shape without opening the schema.

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?

Explicitly names the overlapping sibling xlide_project_info and gives the selecting condition: use that one for more data, use this one when the file is already known and only the module list is wanted. Also gives pagination guidance for large projects, so both the routing and the operational path are covered.

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