Skip to main content
Glama
Sign In

DevTune MCP

by ai.devtune
OverviewDiscussionsAdmin

devtune_change_action_status

DestructiveIdempotent

Move an action through its lifecycle as the member who created the API key or authorized this connection; they must manage actions in this project. Transitions come in pairs: accept a suggestion and unaccept it; archive and restore; block and unblock accepted work; mark_live and reopen. accept and archive of a suggestion, and their inverses, act on every suggestion merged into it. unaccept returns an accepted suggestion to the queue only while nothing has happened to it: no owner, never live, not blocked or in progress, nothing measured, and no brief, draft, edit, Library item, retest, prompt request added from another prompt, or dismissal note attached, whenever it was written; otherwise it is refused and the action stays accepted. Actions someone created, such as prompt actions, and acceptances recorded before DevTune noted they came from a suggestion, are refused too. Each undo is kept in the action's acceptance history, which outlives the suggestion if a later refresh replaces or drops it. restore returns archived work to the status it had, including live. Work archived while blocked returns to blocked, except work archived before DevTune kept that state, which returns to the status it had before it was blocked. mark_live opens the before/after measurement in Results from now, or from liveOn, the UTC day the fix went live (today or up to 14 days back); an optional publishedUrl is added to the pages the action already carries, which all stay. mark_live with liveOn on a live action moves its go-live date and rebuilds its measurement from that day; a measurement that has closed or is dated by a recorded page change keeps its date and the move is refused with invalid_transition. reopen keeps the measurement, its go-live date and its published pages. A high-stakes target page refuses accept until acknowledgeHighStakes is true, which needs a human's confirmation; a locked page refuses it. Repeating accept, unaccept, archive, block, unblock, reopen, or mark_live without a new page or go-live date changes nothing and returns changed false; restore of an action that is not archived is refused with invalid_transition, because the status it would return to is not known. A refusal is a 409 with reason invalid_transition, not_reversible, acknowledgment_required, page_locked, superseded or conflict (the action, its merged suggestions or its target page's protection changed during the request, or the merged suggestions cannot all move in one change), and nothing is written. Some suggestions archived before DevTune recorded which suggestions were archived together share their archive time with others and are always refused with conflict; they stay archived. The credential and member are checked again where the change is written, so access revoked mid-request refuses it. Returns a receipt of the transition as it applied: fromStatus, toStatus, blocked, actionIds affected and transitionedAt. It is not a current read; use devtune_get_actions for that. Nothing is published to the customer's site.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "actionId": "<actionId>",
      "transition": "<transition>"
    },
    "name": "devtune_change_action_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
liveOnNoOnly with mark_live. The UTC day the fix went live, YYYY-MM-DD, today or up to 14 days back; defaults to today. On a live action it moves the go-live date. Obtain human confirmation of the date first.
actionIdYes
transitionYesThe lifecycle move to make.
publishedUrlNoOnly with mark_live. The http(s) page where the fix shipped; added to any published pages the action already has.
acknowledgeHighStakesNoOnly with accept. Confirms a human approved changing a high-stakes page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / actionId / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • addedInput schema / properties / liveOn / pattern
      Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$"
  2. Changed1 schema field changed
    • addedInput schema / properties / liveOn
      Added value: +{
+  "description": "Only with mark_live. The UTC day the fix went live, YYYY-MM-DD, today or up to 14 days back; defaults to today. On a live action it moves the go-live date. Obtain human confirmation of the date first.",
+  "format": "date",
+  "type": "string"
+}
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Far beyond the annotations, it discloses the 409 refusal vocabulary (invalid_transition, not_reversible, acknowledgment_required, page_locked, superseded, conflict), the guarantee that 'nothing is written' on refusal, the mid-request credential re-check, and the no-op semantics that underpin idempotency. It also scopes side effects clearly — the receipt fields and 'Nothing is published to the customer's site' — so destructiveHint is bounded.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a dense multi-hundred-word wall of prose with long embedded conditions ('whenever it was written; otherwise it is refused...'). Every clause carries real information, yet grouping it by transition would make it far more scannable, and the closing 'Nothing is published to the customer's site' is only loosely tied to the preceding flow.

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 an eight-transition mutation tool with no output schema, it supplies the return receipt fields (fromStatus, toStatus, blocked, actionIds, transitionedAt), the failure modes per transition, permission requirements, and the one human-confirmation gate. An agent can call this correctly without consulting anything else.

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 80%, so the schema already documents liveOn, publishedUrl, acknowledgeHighStakes and transition. The description still adds cross-parameter meaning the schema cannot express: liveOn moves a go-live date and rebuilds the measurement on a live action but is refused if the measurement closed, publishedUrl appends without dropping existing pages, and acknowledgeHighStakes gates high-stakes accept. actionId itself gets no added description, which keeps it from a 5.

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 opening sentence names a specific verb and resource — 'Move an action through its lifecycle' — and immediately enumerates the eight transitions. It also explicitly separates itself from the read path with 'It is not a current read; use devtune_get_actions for that,' so an agent can tell it apart from the get_actions sibling without opening a schema.

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?

Prerequisites are stated (caller must be the API-key creator/authorizer and must manage actions in the project), and the read alternative is named explicitly. Per-transition selection rules are given in detail — mark_live vs reopen, unaccept only while nothing has happened to the suggestion, restore refused when not archived — which is exactly the when-and-when-not guidance an agent needs.

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

All DevTune MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources