Skip to main content
Glama
luno-cms

LUNO — AI Backend Platform

Official
by luno-cms
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

propose_change

Propose a multi-step backend structure change plan using dry-run previews and execution bodies, pending human approval before any mutation runs.

Instructions

複数ステップの構造変更を Change Plan として提案（schema/full）。必須: goal, risk, steps（各 step に dry_run + mutation.body）。本ツールは mutations を実行しない。Human が Console で承認するまで pending_approval。先に apply_* / migrate_field_to_master_reference / rename_master_record_slug を dryRun: true で呼び、返却を steps[].dry_run.raw に格納し、本実行用 body を mutation.body に入れる。action は apply_form_blueprint / apply_builtin_form_template / apply_master_blueprint / migrate_field_to_master_reference / rename_master_record_slug。詳細: agent.change-plans / agent.mcp-security-permissions

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYesWhat this multi-step change intends to achieve
riskYesSuggested risk; server may bump from dry_run signals
runIdNoOptional Agent Run correlation (#109)
stepsYesOrdered steps with dry_run previews + mutation.body for later execution. Build from apply_* dryRun first.
impactNoHuman-readable impact bullets for Console review

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
statusNo
changePlanNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.5
    • changedInput schema / properties / steps / items / properties / action / description
      Previous value: -"apply_form_blueprint | apply_builtin_form_template | apply_master_blueprint"New value: +"apply_form_blueprint | apply_builtin_form_template | apply_master_blueprint | migrate_field_to_master_reference | rename_master_record_slug"
    • changedInput schema / properties / steps / items / properties / action / enum
      Previous value: -[
-  "apply_form_blueprint",
-  "apply_builtin_form_template",
-  "apply_master_blueprint"
-]New value: +[
+  "apply_form_blueprint",
+  "apply_builtin_form_template",
+  "apply_master_blueprint",
+  "migrate_field_to_master_reference",
+  "rename_master_record_slug"
+]
  2. Addedv0.1.4

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden. It clearly states mutations are NOT executed, that the plan sits in pending_approval until a Human approves in Console, and that dry_run outputs are stored verbatim but not re-run. It lacks explicit side-effect details (e.g., audit events or rate limits), but the pending-approval and no-execution behavior is the critical disclosure and is well covered.

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 dense but purposeful: it front-loads the core purpose and requirements, then gives the critical usage workflow, then the actionable list. Every sentence earns its place; the only slight inefficiency is the repetition of the action enum already present in the schema's enum.

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?

The description covers goal, requirements, workflow, non-execution semantics, approval status, and cross-references to detailed docs. With an output schema present and 100% parameter coverage, this is complete for an agent to invoke the tool correctly. The steps.dry_run and mutation.body relationship, which is the trickiest part, is explicitly spelled out.

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 meaningful semantics beyond the schema: it explains how steps[].dry_run.raw relates to prior apply_* dryRun calls, that mutation.body is the execution payload for Human approval, and that dryRun must be absent/false at execution time. It also maps the action enum to the sibling tools. This is a clear value-add over the schema's meager property descriptions.

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 precise action: proposing multi-step structural changes as a Change Plan, scoped to schema/full, and lists the exact required constraints (goal, risk, steps with dry_run + mutation.body). It also names the five supported action types, making the tool's role unambiguous and distinguishable from the apply_* siblings.

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?

The description explicitly states when to use it: after calling apply_* / migrate_field_to_master_reference / rename_master_record_slug with dryRun: true, and instructs how to populate steps[].dry_run.raw and mutation.body. It also clarifies that this tool does not execute mutations, which differentiates it from the executor siblings.

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

Deploy Server

Other Tools