Skip to main content
Glama
WilliamSmithEdward

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

Create Office file

xlide_create_project

Create a new Office file with an empty VBA project at a specified path. Avoids repair prompts by using a template, and never overwrites existing files.

Instructions

Creates a new Office file with an empty VBA project at the given absolute path, from a template the application itself authored, so it opens with no repair prompt. Extensions: .xlsm, .xlsb, .xlam, .docm, .pptm, .accdb, and .xlsx for a workbook with Power Query and no macros. It never overwrites an existing file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to create. The extension picks the format.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only carry negative hints (readOnly=false, destructive=false, idempotent=false), so the description carries the behavioral burden. It discloses the template origin and the no-repair-promise, the extension-specific behavior for .xlsx, and the no-overwrite guarantee. It doesn't state what happens on conflict or directory creation, but the key behaviors are covered.

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 earning its place: purpose first, then supported formats, then the no-overwrite behavior. No fluff, no repetition of schema details.

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?

Given a single parameter, an existing output schema, and a clear purpose, the description covers everything an agent needs: what is created, how to specify the path, which extensions are valid, and the critical no-overwrite constraint.

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% and already explains 'absolute path' and 'extension picks the format.' The description adds value by enumerating the supported extensions, which clarifies valid values for file_path beyond the schema's generic statement.

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 description states a specific verb ('Creates'), a specific resource ('new Office file with an empty VBA project'), and important distinguishing details (template authored by the app, no repair prompt, never overwrites). This clearly separates it from the many read/write/modify siblings.

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?

The use case is clear: create a new Office file at an absolute path. It also gives an implicit exclusion ('never overwrites an existing file'), telling the agent not to use it when the file already exists. It doesn't explicitly name alternative tools, but no sibling performs creation, so none is needed.

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