Skip to main content
Glama
loncadev

Baron

by loncadev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

baron_issue_move

Advance work items through the workflow using semantic roles, reconcile status conflicts, and block or unblock items with reasons.

Instructions

Move a work item through the workflow, or flag it. ops: transition (id, role, optional fields) — the semantic role layer, resolving an abstract role to the provider’s native state/column/label; on a provider whose transition carries a screen (Jira) a refusal with code TRANSITION_FIELDS_REQUIRED names the fields to pass back, verbatim, as fields; reconcile (id) — clear a role label the provider’s own state contradicts, commanding no role; block (id, reason — required) and unblock (id, optional reason), which set and clear an ORTHOGONAL flag and leave the role alone, so an item keeps the role it is blocked in.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
opYesWhich operation to perform.
roleNo
fieldsNoAnswers for the fields a gated transition demands, keyed by the provider-native names a TRANSITION_FIELDS_REQUIRED refusal reported. Pass only what the refusal asked for: a provider may reject a field its transition screen does not carry (Jira does).
reasonNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.40.0
    • addedInput schema / properties / fields
      Added value: +{
+  "additionalProperties": true,
+  "description": "Answers for the fields a gated transition demands, keyed by the provider-native names a TRANSITION_FIELDS_REQUIRED refusal reported. Pass only what the refusal asked for: a provider may reject a field its transition screen does not carry (Jira does).",
+  "type": "object"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden, and it succeeds. It reveals non-obvious behavior: transition resolves abstract roles to native provider states, Jira gated screens may return TRANSITION_FIELDS_REQUIRED requiring verbatim field names, reconcile clears contradictory role labels, and block/unblock operate orthogonally without changing the role. This is far more transparent than a generic 'update' statement.

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 deliberately structured around the four operations, with the overall purpose front-loaded and no filler words. However, the single sprawling sentence with embedded clauses and parentheticals is harder to parse than an ideal tool description, so it loses a point on readability.

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

Completeness4/5

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

For a 5-parameter, 4-operation tool with no output schema and no annotations, the description provides strong coverage: operation semantics, parameter requirements, orthogonal flag behavior, and Jira-specific refusal handling. It does not describe the success or error response envelope, permissions, or provider behavior beyond Jira, which leaves some gaps for an agent fully operating blind.

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

Parameters5/5

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

The input schema only documents op and fields, leaving id, role, and reason unexplained. The description compensates by mapping parameters to operations: transition(id, role, optional fields), reconcile(id), block(id, reason required), and unblock(id, optional reason). It also clarifies that role is abstract and that reason is conditionally required, giving the agent actionable meaning beyond the raw schema.

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?

The opening phrase, 'Move a work item through the workflow, or flag it,' clearly identifies the tool's core purpose and resource. The four operations (transition, reconcile, block, unblock) are enumerated and briefly differentiated, making the tool distinct from the sibling issue_read/issue_write tools. However, it never explicitly names a sibling or says how this differs from baron_issue_write, so it stops short of a 5.

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

Usage Guidelines4/5

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

The op-by-op breakdown gives strong internal guidance: use transition for role resolution, reconcile for contradictory labels, and block/unblock for orthogonal flagging. It also provides a concrete flow for Jira screen refusals and required fields. It does not explicitly discuss when to choose this tool over related siblings like baron_native_request or baron_issue_write, leaving some external routing to inference.

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