Skip to main content
Glama

Ankra

by ai.ankra
OverviewDiscussionsAdmin

ticket_update_status

Move an AI work board ticket through its lifecycle: triage -> investigating -> planning -> awaiting_review -> awaiting_approval -> executing -> verifying -> done, with blocked/cancelled side exits. Transitions are validated; an invalid move is rejected with the reason. Moving to 'done' requires an explicit resolution - there is no default: fixed, no_action, duplicate, wont_fix, escalated, unverifiable (applied but never confirmed against live state), cleared (the alert stopped firing after an action, with nothing checking the resource), expired (the board's own gate clock writes this when a human gate lapsed unanswered - do not close as expired yourself). 'fixed' means the condition was corrected AND that was confirmed, so it is refused unless you also pass evidence_kind and evidence_reference naming what proves it. If you could not confirm the fix, do not close as fixed: use unverifiable, or move the ticket to 'blocked' and say what you could not verify. Always include a note explaining the move. Moving to 'executing' requires a human-approved plan, and 'awaiting_approval' requires a drafted plan - both are enforced. Desks that require agent review (and have a reviewer configured) also demand the peer verdict before 'awaiting_approval': request one with ticket_request_review first. When you move to 'blocked' because a human must choose between changes, pass them as decision_options (with a decision_prompt) so the board renders them as a choice - the human picks one or answers with something else, and their answer comes back in your next brief as a Human decision to act on. Never ask a human for permission to read: every read needs no approval, the break-glass ssh_kubectl_read included, so do the read yourself; an option declared read_only is refused. After a human answered, a move to 'blocked' is refused until the run has made a tool call other than the ticket tools.

Input Schema

NameRequiredDescriptionDefault
noteNoWhy the ticket is moving (posted on the timeline).
statusYesThe target lifecycle status.
ticket_idNoThe ticket UUID. Optional when ticket_number is given.
resolutionNoRequired when moving to done; there is no default.
duplicate_ofNoOnly with status 'done' and resolution 'duplicate': the number of the open ticket that covers the same cause. The board links the two, so whoever reads either ticket finds the other.
evidence_kindNoWhat confirmed the fix. Required with resolution 'fixed', and must be given together with evidence_reference.
ticket_numberNoThe per-organisation ticket number.
decision_promptNoOnly with status 'blocked': the one-sentence question the human must answer.
decision_optionsNoOnly with status 'blocked', when the block is a choice between changes: the options the human picks from on the board (they can also answer with something else in their own words). Their answer comes back in your next brief as a Human decision to act on. Every option must declare an action_class, 'mutating' or 'none': never offer a read as an option - do the read yourself, every read needs no approval.
evidence_referenceNoThe evidence itself: the probe or run id, the URL, or the tool you read and the exact values you saw. Required with resolution 'fixed'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / decision_options / description
      Previous value: -"Only with status 'blocked', when the block is a choice between alternatives: the options the human picks from on the board (they can also answer with something else in their own words). Their answer comes back as a comment starting with 'Decision:'. Give every option an action_class: it is what lets the board settle the question safely if nobody answers before the organisation's deadline."New value: +"Only with status 'blocked', when the block is a choice between changes: the options the human picks from on the board (they can also answer with something else in their own words). Their answer comes back in your next brief as a Human decision to act on. Every option must declare an action_class, 'mutating' or 'none': never offer a read as an option - do the read yourself, every read needs no approval."
    • changedInput schema / properties / decision_options / items / properties / action_class / description
      Previous value: -"What taking this option would DO: 'none' changes nothing (do nothing, silence it, leave it), 'read_only' gathers more information without changing anything, 'mutating' changes a cluster or the platform. Declare it honestly. It is what lets a deadline settle an unanswered question safely: an option that declares nothing, or declares 'mutating', is never taken automatically."New value: +"What taking this option would DO: 'none' changes nothing (do nothing, silence it, leave it), 'mutating' changes a cluster or the platform. Required, and declared honestly: it is what lets a deadline settle an unanswered question safely, and a 'mutating' option is never taken automatically. 'read_only' is refused - a read is never a question for a human."
    • changedInput schema / properties / decision_options / items / properties / action_class / enum
      Previous value: -[
-  "none",
-  "read_only",
-  "mutating"
-]New value: +[
+  "none",
+  "mutating"
+]
    • changedInput schema / properties / decision_options / items / required
      Previous value: -[
-  "title"
-]New value: +[
+  "title",
+  "action_class"
+]
    • addedInput schema / properties / duplicate_of
      Added value: +{
+  "description": "Only with status 'done' and resolution 'duplicate': the number of the open ticket that covers the same cause. The board links the two, so whoever reads either ticket finds the other.",
+  "minimum": 1,
+  "type": "integer"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the minimal annotations, the description discloses validation behavior (invalid moves rejected with a reason), enforcement rules (plan approvals, peer verdicts, evidence requirements), the lack of a default resolution for 'done', special resolution semantics, and post-human-decision gating for 'blocked'. This is rich behavioral context that an agent cannot infer from the annotations.

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 and front-loads the lifecycle, then layers rules in a logical order. It is lengthy (around 350 words) and has some repetition (the 'every read needs no approval' point appears twice), but nearly every sentence carries necessary behavioral guidance for a complex mutation tool.

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 10-parameter mutation tool with no output schema, the description covers lifecycle rules, validation, resolution requirements, evidence prerequisites, human decision handling, and read-approval behavior. Nothing an agent needs in order to choose the correct status and supply required parameters appears to be missing.

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%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: it explains what each resolution means (especially 'fixed' vs 'unverifiable' vs 'expired'), that 'fixed' is refused without evidence_kind and evidence_reference, and that decision_options action_class must be declared honestly with 'read_only' refused. This goes beyond the schema's field-level documentation.

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 ('Move') and resource ('an AI work board ticket') and enumerates the full lifecycle including side exits. It clearly distinguishes this tool from siblings such as ticket_decide, ticket_request_review, and ticket_draft_plan by focusing solely on status transitions.

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 when-to-use rules for each target status, including prerequisites (human-approved plan before 'executing', drafted plan before 'awaiting_approval'), alternatives when a fix is unconfirmed ('unverifiable' or 'blocked'), and the requirement to request peer review first in certain desks. It also states when not to use 'fixed' and when to use decision_options for blocked transitions.

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

All Ankra toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources