Skip to main content
Glama
bim-ba

ycli

by bim-ba
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Move Tracker issue

tracker_issues_move

Move a Yandex Tracker issue to another queue, assigning a new key while the old redirects. Fields absent in the target queue may be dropped.

Instructions

Move a Tracker issue to another queue (it gets a new key there; the old key redirects).

queue is the target queue key. Fields that do not exist in the target queue may be dropped. Returns the moved issue with its new key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queueYesTarget queue key, e.g. NEW.
expandNoExtra blocks to include in the reply.
notifyNoNotify the users in the fields of the object; omitted, the API notifies.
issue_keyYesIssue key, e.g. QUEUE-123.
notify_authorNoNotify the author of the change; omitted, the API does not.
initial_statusNoReset the status to the new queue's initial one.
move_all_fieldsNoKeep the versions, components and projects the new queue also has.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.122.1
    • addedInput schema / properties / issue_key
      Added value: +{
+  "description": "Issue key, e.g. QUEUE-123.",
+  "type": "string"
+}
    • removedInput schema / properties / key
      Removed value: -{
-  "description": "Issue key, e.g. QUEUE-123.",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "key",
-  "queue"
-]New value: +[
+  "issue_key",
+  "queue"
+]
  2. First observedv0.67.0

TDQS

A4/5.0
Behavior4/5

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

With annotations covering read-only/destructive/idempotency flags, the description adds real behavioral context: the key changes, the old key redirects, and fields absent from the target queue may be dropped. It does not mention that notifications may be sent or what permissions are required, which is why it stops short of 5.

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

Conciseness5/5

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

Two tight sentences plus a short parameter note, with the most important fact (new key, old key redirects) front-loaded. No filler or repetition.

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?

Despite no output schema, the description states the return (the moved issue with its new key) and the key-dropping caveat. It omits permission requirements and notification side effects, but for a 2-required-param move tool this is close to complete.

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 description coverage is 100%, so every parameter including ''queue'' is already documented in the schema; the description's restatement of ''queue'' adds nothing new. It indirectly hints at the field-dropping behavior tied to move_all_fields, but that is marginal over the schema baseline.

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?

It states a specific verb and resource ("Move a Tracker issue to another queue") and immediately distinguishes itself from the bulk sibling by operating on a single issue. The added detail that the issue gets a new key and the old key redirects makes the operation's identity unambiguous.

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

Usage Guidelines3/5

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

Usage is implied by the clear action, but there is no explicit when-to-use guidance, no mention of the bulk alternative (tracker_issues_move_bulk), and no prerequisites such as required permissions or queue-access constraints. An agent can infer intent but gets no routing help.

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