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

Overview Schema Source Related Servers Discussions Admin

Write module

xlide_write_module

DestructiveIdempotent

Writes a complete VBA module's source into an Excel, Word, PowerPoint, or Access file and saves it, replacing existing code or creating a standard or class module.

Instructions

The canonical way to change VBA. Writes a module's source into the Office file and saves it. It replaces the module's whole source, so send all of it; send the body only, because the attribute header is managed for you. A module that does not exist is created: standard by default, or a class with kind='class'. Pass expected_content_token from your read and the write is refused if the module changed since. The result carries a diff of what the file now holds, read back after saving, which is what to show the user when they ask what changed. After writing, call xlide_analyze and treat any error as a build failure. Identical source is reported without saving. Ask the user first when the project is protected or signed.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	No	Kind for a module being created: 'standard' or 'class'.	standard
`source`	Yes	The module's complete VBA source.
`file_path`	Yes	Absolute path to the Office file.
`module_name`	Yes	Module to write, or to create.
`include_diff`	No	Include a unified diff of what changed. Off in a loop that writes many modules and reads none of them back.
`allow_protected`	No	Write to a password-protected project. Ask the user first.
`expected_content_token`	No	The content_token from your read. Leave empty only when creating a module.
`allow_invalidate_signature`	No	Write to a digitally signed project, dropping the signature. Ask the user first.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that missing modules get created, that writes are refused on token mismatch, that identical source is a no-op, that the attribute header is managed automatically, and that protected/signed projects need user consent. These are exactly the failure/edge behaviors an agent needs and none are in the structured fields.

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?

Dense and front-loaded, with the critical 'replaces whole source / send body only' constraint leading. It is longer than most definitions but nearly every sentence carries a distinct operational fact; only minor tightening is possible.

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, and the description still explains that the result carries a read-back diff and how to present it. Combined with the safety, token, and follow-up guidance, nothing an agent needs to invoke 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 baseline is 3, but the description adds non-obvious meaning the schema lacks: kind='class' only matters on creation, expected_content_token should be left empty only when creating, and source must be the body without the attribute header. That last point is a genuine semantics addition.

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 ('Writes a module's source into the Office file and saves it') and immediately distinguishes itself from sibling edit tools by declaring it replaces the whole source. The agent knows exactly what class of operation this is versus xlide_edit_module.

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 conditional guidance: send the whole body, pass expected_content_token from your read, call xlide_analyze afterward, ask the user first for protected/signed projects. It implies but never names xlide_edit_module as the partial-edit alternative, so sibling routing is left to inference.

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

Deploy Server