Skip to main content
Glama
WilliamSmithEdward

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

by WilliamSmithEdward
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

List procedures

xlide_list_procedures
Read-onlyIdempotent

List Sub, Function, and Property procedures in a VBA module with kind, scope, line number, and signature to locate code without reading it all.

Instructions

Lists the Sub, Function and Property procedures in one module, with each one's kind, scope, line number and signature. The module's content_token can guard an xlide_edit_module call. Use it to find where to change something without reading a long module in full. Use offset and next_offset to page through a module with many procedures.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNoProcedures to skip.
file_pathYesAbsolute path to the Office file.
max_resultsNoMost procedures to return.
module_nameYesModule name, matched without case.

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": "Most procedures to return.",
+  "maximum": 1000,
+  "minimum": 1,
+  "title": "Max Results",
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "description": "Procedures to skip.",
+  "minimum": 0,
+  "title": "Offset",
+  "type": "integer"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already establish readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds real value beyond that: the content_token can guard an xlide_edit_module call and paging behavior via offset/next_offset, which an agent could not infer from annotations alone.

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?

Three sentences, front-loaded with what is returned and then usage, then paging. No filler, though the pagination sentence and the token-guard sentence are somewhat loosely tied to the main purpose.

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 not required. The description covers purpose, the edit-guard token, and pagination, which is everything an agent needs to call this read-only list tool correctly.

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 above baseline by explaining that offset and next_offset are for paging through a module with many procedures, giving operational meaning to the pagination parameters beyond the schema's terse 'Procedures to skip.'

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 the Sub, Function and Property procedures in one module') and enumerates the returned fields (kind, scope, line number, signature). It also implicitly separates itself from xlide_read_module by framing the tool as a way to avoid reading a long module in full.

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 clear use case ('find where to change something without reading a long module in full') and paging guidance via offset/next_offset. It stops short of explicitly naming the alternative tools (xlide_list_modules, xlide_read_module) and the conditions that would select them.

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

Deploy Server

Other Tools