Skip to main content
Glama
Tingsum26

sdlc-workflow-mcp

by Tingsum26

workflow_ticket_advance

Moves a ticket to its next delivery status using an exact version to prevent conflicting updates in the SDLC workflow.

Instructions

Advance a ticket along its delivery status machine with an exact version.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetYes
ticketIdYes
expectedVersionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. 'With an exact version' hints at optimistic concurrency control, but it does not state what happens on a version mismatch, which transitions are legal, whether the call is idempotent, permission requirements, or side effects.

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?

A single front-loaded sentence with no filler. It is efficient, though given the mutation semantics and 12-state enum it is arguably under-specified rather than optimally concise.

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

Completeness2/5

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

For a state-mutating tool with no annotations, no output schema, three undocumented parameters, and a 12-state enum, the description omits critical context: valid transitions, concurrency failure behavior, and return semantics. It is not complete enough for reliable invocation.

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. It conveys some meaning for expectedVersion ('exact version' implies optimistic locking) and gestures at target ('delivery status machine'), but ticketId is unexplained and the 12-value enum has no transition semantics documented anywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Advance') and resource ('ticket') plus the delivery status machine concept, so the operation is identifiable. It does not explicitly distinguish itself from the similarly named sibling advance_repo_task or from workflow_complete_task, so sibling differentiation is left to inference.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives like advance_repo_task or workflow_complete_task, nor any stated preconditions. The only hint is the implied need for an exact version, which is a constraint rather than usage guidance.

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