Skip to main content
Glama
S-CurveLabs

letin

Official
by S-CurveLabs

set_query

Replace or create a Power Query formula in a query, with validation against unbalanced brackets and optional dry-run.

Instructions

Replace a query's M (or create it with create_if_missing). Rejects unbalanced brackets/strings before writing. For standard actions prefer apply_transform; for renames prefer rename_query / rename_step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
sourceYes
dry_runNo
formulaYes
descriptionNo
create_if_missingNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does well by revealing validation behavior ('Rejects unbalanced brackets/strings before writing') and conditional creation via create_if_missing. It could go further by mentioning dry_run behavior or the result of a successful write, but the core mutation and validation traits are clear.

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?

Two sentences with no filler. The core behavior is front-loaded, the create_if_missing behavior is included, and the sibling routing is appended without wasting words.

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

Completeness3/5

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

The description captures the essential behavior, validation, and tool-selection context. However, with no output schema and several under-documented parameters, an agent may still be unsure about what values source/name/dry_run expect and what the call returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only clarifies formula and create_if_missing. The roles of source, name, description, and dry_run are not explained, especially source/name, which are ambiguous in this domain.

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 and resource: 'Replace a query's M', and explicitly mentions the create_if_missing option. It also differentiates against siblings by saying apply_transform is preferred for standard actions and rename_query/rename_step for renames.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit routing guidance: 'For standard actions prefer apply_transform; for renames prefer rename_query / rename_step.' This tells an agent when not to choose this tool and which sibling to use instead.

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