Yandex Tracker MCP Server

Overview Schema Source Related Servers Discussions Admin

Find Issues

issues_find

Read-only

Find Yandex Tracker issues using YQL query syntax. Filter by any indexed field like assignee, status, tags, or date to get precise results.

Instructions

Find Yandex Tracker issues matching a Yandex Tracker Query (YQL) - not limited to queue/date, any indexed field can be used (assignee, status, tags, etc., see the query parameter for the full syntax).

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number to return, default is 1
`query`	Yes	Search query to filter issues using Yandex Tracker Query. # General instructions 1. To search by a specific field use the following syntax: `Description: "some issue description"` 2. Multiple fields should be separated by space: `Description: "some issue description" Created: today()` 3. If you need to specify multiple values for the same field - provide them using comma (,), e.g.: `author: "vpupkin","iivanov"` 4. You may specify multiple conditions and combine them using `AND` and `OR` statements, e.g. `<param_1>: "<value_1>" AND <param_2>: "<value_2>"` 5. You may use brackets for complex logical expressions 6. To find issues with exact string matching in the field use this syntax: `Summary: #"Version 2.0"`. If you need to pass special characters - you must escape them using `\` symbol 7. To find issues that don't contain the specified text use this syntax: `Summary: !"Version 2.0"`. If you need to pass special characters - you must escape them using `\` symbol 8. If you need to search by local queue field use the following syntax: `<QUEUE>.<LOCAL_FIELD_KEY>: "<value>", where <QUEUE> is a queue key, <LOCAL_FIELD_KEY> is a local field's key from the `queue_get_fields` tool result (call it with `include_local_fields=true`). 9. For dates use the format YYYY-MM-DD. 10. For numerical values you may use comparison operators (>, <, >=, <=): `<param>: ><value>`. 11. To sort the result specify the `Sort By` directive (you may provide ASC or DESC for the sort order): `"Sort By": Created ASC`. 12. For Assignee field and any other field representing a user (such as Author and others) always use username and not name. # Functions These functions may be used, for example: `Created: week()` - return issues created on the current week" * `empty()` - empty value * `notEmpty()` - not empty value * `now()` - current time * `today()` - current date * `week()` - current week * `month()` - current month * `quarter()` - current quarter * `year()` - current year * `unresolved()` - there is no resolution * `me()` - currently logged in user # Examples Find issues in a specific queue: `"Queue": "PROJ"` Find issues by an assignee: `"Assignee": "i.ivanov"` Find not resolved (open, in progress) issues: `"Resolution": unresolved()` Find issues in specific status: `"Status": "Открыт", "В работе"` Find issues created in a specific range: `"Created": "2017-01-01".."2017-01-30"` Find issues created by currently logged in user: `"Author": me()"` Find issues assigned to currently logged in user: `"Assignee": me()"` Find issues created no earlier than 1 week and 1 day before today: `Created: > today() - "1w 1d"` Complete instructions page is available here: https://yandex.ru/support/tracker/ru/user/query-filter
`fields`	No	Fields to return, in Tracker's own spelling (`storyPoints`, not `story_points`); the standard ones are in this tool's output schema. For a queue's local or the organization's custom fields, pass the field `id` from `queue_get_fields`. An unknown name is dropped silently, so check there if a field comes back missing. Omitting this returns ALL fields.
`per_page`	No	The number of items per page. May be decreased if results exceed context window. If there is a change in per_page argument - retrieval must be started over with page = 1, as the paging could have changed.
`include_description`	No	Whether to include the issue description; it can be large. Ignored when `description` is listed in `fields`.

Output Schema

TableJSON Schema

Name	Required	Description
`hits`	No	Total items matching the request, across all pages. Null if unknown or filtered - then page on until a page comes back empty.
`pages`	No	Total pages at the requested `per_page`; this is the last page when it equals `page`. Null together with `hits`.
`values`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.10.0Sep 14, 2026

TDQS

A4.1/5.0

Behavior3/5

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

The readOnlyHint annotation already establishes that this is a safe read operation, and the description is consistent with that. The main description adds scope context but does not disclose behavioral details such as pagination resets, silent dropping of unknown fields, or return-size implications; those live in parameter descriptions rather than the tool description itself.

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?

The description is a single, front-loaded sentence that states what the tool does, narrows the scope ('not limited to queue/date'), gives concrete examples of supported fields, and points to the authoritative syntax source. Every clause earns its place with no wasted words.

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?

The tool has a rich input schema covering all parameters, an output schema for return values, and a readOnlyHint annotation. The main description supplies the missing high-level framing of YQL-based search scope, and the query parameter description provides the full syntax and examples. Nothing essential for correctly selecting and invoking the tool is missing.

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 the schema already documents all parameters thoroughly, including the full YQL syntax in the query parameter. The main description merely points to the query parameter and mentions indexed field categories, adding little semantic value beyond the schema itself.

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 uses a specific verb-resource pair ('Find Yandex Tracker issues') and immediately distinguishes this tool from other issue tools by framing it as a YQL search that is 'not limited to queue/date' and can target 'any indexed field.' This clearly separates it from issue_get, issues_count, and queue-scoped tools.

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 description gives clear context for when to use the tool: whenever issues need to be found by YQL across indexed fields rather than by a known ID. It does not explicitly name alternative tools such as issue_get or issues_count, nor does it state when not to use this tool, so it stops short of the fullest guidance.

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

Deploy Server