Skip to main content
Glama
WilliamSmithEdward

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

Write Power Query

xlide_write_query
DestructiveIdempotent

Manage Power Query in Excel workbooks: set or rename query formulas, remove queries, and load or unload query results to worksheets.

Instructions

Changes a workbook's Power Query and saves it. action='set' replaces a query's M formula, creating it if it does not exist; 'rename' renames it and rewrites the queries that reference it by name; 'remove' deletes it and everything that loaded it onto a sheet, which has no undo, so ask the user first. 'load' puts a query's result on a worksheet and 'unload' takes it back off. Loading needs the column names, because writing the connection means naming the columns and knowing them means running the query, which nothing here does; Excel settles them against the real result on the first refresh. A query already loaded keeps its rows until Excel refreshes it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cellNoFor load: the table's top-left cell.A1
groupNoFor set on a new query: the folder in the Queries pane.
sheetNoFor load: the worksheet. Empty uses the first.
actionYes'set', 'rename', 'remove', 'load' or 'unload'.
columnsNoFor load: the column names the query returns, in order. Required, because the connection has to name them and nothing here runs the query to find out. Excel corrects them on the first refresh.
formulaNoFor set: the whole M expression, such as 'let Source = 1 in Source'.
new_nameNoFor rename: the new name.
file_pathYesAbsolute path to the Excel workbook.
query_nameYesThe query to change.
descriptionNoFor set: the query's description.
include_diffNoFor set: include a unified diff of the M that changed. Nothing to diff for the other actions.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing that remove deletes the query and everything loaded from it, has no undo, and therefore requires asking the user first. It also explains the subtle load behavior: column names must be provided, Excel reconciles them on first refresh, and a loaded query keeps existing rows until refresh.

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?

The description is long, but the tool has five distinct actions with important caveats, so the length is largely justified. The main purpose is front-loaded and the action list is organized; the load explanation is a bit dense but still earns its place.

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?

For a complex mutation tool with five actions and 11 parameters, the description covers action semantics, parameter requirements, destructive side effects, and refresh behavior. With a full input schema and an output schema present, an agent has enough context to invoke the 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 adds real semantic value by tying parameters to specific actions: columns/cell/sheet for load, formula/group/description/include_diff for set, and new_name for rename. It also explains why columns are mandatory even though the schema merely lists them.

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 opens with a specific verb and resource: 'Changes a workbook's Power Query and saves it.' It then enumerates all five action modes (set, rename, remove, load, unload), so an agent immediately knows this is the write/mutate counterpart to sibling tools like xlide_read_query.

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?

Clear usage context is provided for each action, including what set vs. rename vs. remove vs. load vs. unload do. It does not explicitly name alternatives or state when not to use this tool, but the action-by-action guidance makes the intended use fairly unambiguous.

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