Skip to main content
Glama

Demote production commit

demote_commit
DestructiveIdempotent

Affects the live site. Clears a project's canonical (production) pointer by demoting the commit that holds it (by job_id) — same as the dashboard Actions → Demote. The release keeps running and stays reachable at its per-commit URL; it just stops being production, and NO replacement canonical is picked, so the project's stable host serves nothing until a commit is promoted. This is the unblock for every canonical guardrail: stop_commit, delete_commit and whole-project deletion all refuse the canonical commit, and demote_commit clears it without promoting an unrelated commit into production. No-op (reported as such) when the given commit is not the canonical. Requires a read-write token.

Input Schema

NameRequiredDescriptionDefault
job_idYesthe deployment job id to demote (from list_deployments); must be the project's current canonical, otherwise the call is a no-op

Output Schema

NameRequiredDescriptionDefault
okYes
statusNopresent, and always "pending_approval", only when this call was parked instead of run immediately because the project's (or kad-back's own) plan-mode setting requires a human to approve it first
messageYes
plan_idNopoll get_plan_status with this id for the eventual outcome
approve_atNothe kad.dev dashboard URL a human approves or rejects this plan from
expires_in_sNothe plan can no longer be approved after this many seconds

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the destructiveHint annotation by describing the concrete blast radius: the live site stops serving on its stable host, no replacement canonical is picked, yet the release stays reachable at its per-commit URL. It also discloses the read-write token requirement and idempotent no-op reporting, all of which the annotations alone do not convey.

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?

Impact on the live site is front-loaded and every sentence carries information, including the guardrail routing. It is dense and em-dash heavy, and the no-op and token notes could be ordered more crisply, but there is no filler.

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 destructive, single-parameter mutation with an output schema covering return values, the description supplies the consequences, prerequisites, and side effects an agent needs. Nothing material about invoking it correctly is missing.

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

Parameters3/5

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

Schema coverage is 100% and the single job_id parameter is already documented with its source (list_deployments) and the no-op constraint. The description reinforces 'by job_id' and the canonical prerequisite but adds no format or sourcing detail the schema lacks, so baseline 3 applies.

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?

States a precise verb and object: clearing a project's canonical (production) pointer by demoting the commit holding it, keyed by job_id. It distinguishes itself from promote_commit and from stop_commit/delete_commit by naming exactly which behavior it performs on the canonical pointer.

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?

Explicitly frames the tool as 'the unblock for every canonical guardrail', naming the three siblings that refuse the canonical commit, and states the no-op condition when the commit isn't canonical. Nothing an agent needs in order to choose this over stop_commit or delete_commit is left implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources