Skip to main content
Glama
bim-ba

ycli

by bim-ba
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Search Tracker issues

tracker_issues_search
Read-onlyIdempotent

Search Yandex Tracker issues by query-language string or field-value filter, with auto-paginated results. Use it to find open tasks by queue, status, assignee, or custom fields.

Instructions

Issues matching a query-language string or a filter, auto-paginated.

body.query is a TQL string, body.filter a field → value object. Returns at most limit issues; exactly limit back means more may match — refine the search or raise limit. E.g. {"body": {"query": "Queue: QUEUE Status: open"}} or {"body": {"filter": {"queue": "QUEUE", "assignee": "ann"}}}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesTyped request body for ``POST /issues/_search`` and ``POST /issues/_count``. Give ``query`` (the query language) or ``filter`` (field name → value); a body with neither matches every issue the caller can see. ``extra="allow"`` passes the API's other keys (``keys``, ``queue``, ``order``) through.
limitNoMax issues to return; omitted means the configured cap (YCLI__HTTP__MAX_ITEMS).
expandNoExtra blocks to include in the reply.
per_scrollNoIssues per scroll page (1000 at most).
scroll_typeNoScroll through the results (no 10 000 cap).
scroll_ttl_millisNoHow long the scroll stays open, in milliseconds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.122.1
    • addedInput schema / properties / body
      Added value: +{
+  "additionalProperties": true,
+  "description": "Typed request body for ``POST /issues/_search`` and ``POST /issues/_count``.\n\nGive ``query`` (the query language) or ``filter`` (field name → value); a body with neither\nmatches every issue the caller can see. ``extra=\"allow\"`` passes the API's other keys\n(``keys``, ``queue``, ``order``) through.",
+  "properties": {
+    "filter": {
+      "anyOf": [
+        {
+          "additionalProperties": true,
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "description": "Field name → value the issues must have."
+    },
+    "query": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "description": "A query-language string."
+    }
+  },
+  "type": "object"
+}
    • removedInput schema / properties / query
      Removed value: -{
-  "description": "TQL query, e.g. ``Queue: QUEUE Status: open``.",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "query"
-]New value: +[
+  "body"
+]
  2. First observedv0.67.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so the safety profile is covered. The description adds genuine behavioral context beyond that: the result set is auto-paginated, and a result count exactly equal to `limit` signals possible truncation requiring refinement or a higher limit. It does not discuss the scroll-related options, but with annotations lowering the bar this is solid added value.

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 paragraphs, front-loaded with the core purpose, then the query/filter distinction, then the pagination caveat, with inline examples. Every sentence carries information; nothing is padding.

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 6-parameter search tool with full schema coverage and no output schema, the description covers the essential decision points (query vs filter, limit truncation behavior). The scroll-related parameters are only documented in the schema, which is acceptable given coverage, but a phrase on when scrolling is warranted would complete the picture.

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 100%, so the baseline is 3, but the description goes beyond the schema by supplying concrete TQL and filter examples ('Queue: QUEUE Status: open', {'queue': 'QUEUE', 'assignee': 'ann'}) that the schema's terse 'A query-language string' does not convey. The scroll/expand parameters are left to the schema alone, keeping it from a 5.

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 (search) and resource (Tracker issues) and clarifies that matching is driven by either a TQL query string or a field→value filter. An agent understands what the tool does immediately, though it never names how it differs from siblings like tracker_issues_list or tracker_issues_count.

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?

Gives in-tool usage guidance (use query OR filter, and how to react when exactly `limit` results return), but offers no routing guidance versus tracker_issues_list, tracker_issues_count, or tracker_entities_search. Usage is implied rather than framed as a choice among alternatives.

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