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

Overview Schema Source Related Servers Discussions Admin

Write Power Query

xlide_write_query

DestructiveIdempotent

Manage Power Query queries in an Excel workbook: set M formulas, rename, remove, load or unload results, and save changes.

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. Pass expected_content_token from xlide_read_query to refuse a change if that query changed meanwhile.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`cell`	No	For load: the table's top-left cell.	A1
`group`	No	For set on a new query: the folder in the Queries pane.
`sheet`	No	For load: the worksheet. Empty uses the first.
`action`	Yes	'set', 'rename', 'remove', 'load' or 'unload'.
`columns`	No	For 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.
`formula`	No	For set: the whole M expression, such as 'let Source = 1 in Source'.
`new_name`	No	For rename: the new name.
`file_path`	Yes	Absolute path to the Excel workbook.
`query_name`	Yes	The query to change.
`description`	No	For set: the query's description.
`include_diff`	No	For set: include a unified diff of the M that changed. Nothing to diff for the other actions.
`expected_content_token`	No	Optional read token to guard the change.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.2.2Sep 30, 2026

addedInput schema / properties / expected_content_token

Added value: +{
+  "default": "",
+  "description": "Optional read token to guard the change.",
+  "title": "Expected Content Token",
+  "type": "string"
+}

First observedv0.1.0Sep 20, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already cover the safety profile (destructiveHint=true, idempotentHint=true), and the description layers on meaningful behavior the annotations cannot convey: that 'remove' cascades to anything loaded onto a sheet with no undo, that 'rename' rewrites name references, and that loaded queries keep stale rows until Excel refreshes. That is exactly the beyond-annotation context this dimension rewards.

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?

Front-loaded with the core action semantics and free of filler, but it is delivered as one dense paragraph where a short action list would have scanned faster. Every sentence carries information, so the length is justified if not optimally structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 12 parameters at 100% coverage and an output schema present, the description needn't describe returns, and it correctly avoids doing so. It covers all five actions, their side effects, prerequisites, and the token guard, leaving only minor gaps such as grouping behavior for 'set'.

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 description coverage is 100% and each parameter already carries its own 'For X' note, so the baseline is 3. The description goes further by explaining why columns is mandatory (the connection must name them, nothing here runs the query, Excel reconciles on first refresh) and how expected_content_token acts as an optimistic-concurrency guard.

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+resource ('Changes a workbook's Power Query and saves it') and then enumerates all five actions with concrete semantics. It is immediately distinguishable from xlide_read_query, which merely reads a query, and it makes clear that the five actions are not interchangeable.

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?

Usage context is strong per action: 'remove' deletes dependents and has no undo ('ask the user first'), 'load' needs column names, and expected_content_token is routed from xlide_read_query for conflict guarding. It stops short of naming any tool the agent should prefer for reading or editing, so routing is implied rather than fully explicit.

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

Deploy Server