Skip to main content
Glama
aikts

Yandex Tracker MCP

issues_find

Search and filter Yandex Tracker issues by queue, created date, or custom queries with advanced syntax. Retrieve specific fields, paginate results, and manage complex conditions for precise issue tracking.

Instructions

Find Yandex Tracker issues by queue and/or created date

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldsNoFields to include in the response. In order to not pollute context window - select appropriate fields beforehand. Not specifying fields will return all available.
include_descriptionNoWhether to include issue description in the issues result. It can be large, so use only when needed.
pageNoPage number to return, default is 1
per_pageNoThe 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.
queryYesSearch 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_local_fields` tool result. 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`. # 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 # Examples Find issues in a specific queue: `"Queue": "PROJ"` Find issues by an assignee: `"Assignee": "Иван Иванов"` 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 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

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main MCP tool handler for 'issues_find' that handles parameters, calls the underlying tracker client, processes results (e.g., clears descriptions if not needed, filters fields), and returns the list of issues.
    @mcp.tool(description="Find Yandex Tracker issues by queue and/or created date")
    async def issues_find(
        ctx: Context[Any, AppContext],
        query: YTQuery,
        include_description: Annotated[
            bool,
            Field(
                description="Whether to include issue description in the issues result. It can be large, so use only when needed.",
            ),
        ] = False,
        fields: Annotated[
            list[IssueFieldsEnum] | None,
            Field(
                description="Fields to include in the response. In order to not pollute context window - select "
                "appropriate fields beforehand. Not specifying fields will return all available."
            ),
        ] = None,
        page: PageParam = 1,
        per_page: PerPageParam = 100,
    ) -> list[Issue]:
        issues = await ctx.request_context.lifespan_context.issues.issues_find(
            query=query,
            per_page=per_page,
            page=page,
            auth=get_yandex_auth(ctx),
        )
    
        if not include_description:
            for issue in issues:
                issue.description = None  # Clear description to save context
    
        if fields is not None:
            set_non_needed_fields_null(issues, {f.name for f in fields})
    
        return issues
  • Pydantic schema definition for the 'query' parameter of issues_find tool, including detailed description of Yandex Tracker Query Language syntax.
    YTQuery = Annotated[
        str,
        Field(
            description=(
                """Search query to filter issues using Yandex Tracker Query.\n"""
                """# General instructions\n"""
                """1. To search by a specific field use the following syntax: `Description: "some issue description"`\n"""
                """2. Multiple fields should be separated by space: `Description: "some issue description" Created: today()`\n"""
                """3. If you need to specify multiple values for the same field - provide them using comma (,), e.g.: `author: "vpupkin","iivanov"`\n"""
                """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>"`\n"""
                """5. You may use brackets for complex logical expressions\n"""
                """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\n"""
                """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\n"""
                """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_local_fields` tool result.\n"""
                """9. For dates use the format YYYY-MM-DD.\n"""
                """10. For numerical values you may use comparison operators (>, <, >=, <=): `<param>: ><value>`.\n"""
                """11. To sort the result specify the `Sort By` directive (you may provide ASC or DESC for the sort order): `"Sort By": Created ASC`.\n"""
                """12. For Assignee field and any other field representing a user (such as Author and others) always use username and not name.\n"""
                """# Functions\n"""
                """These functions may be used, for example: `Created: week()` - return issues created on the current week"\n"""
                """* `empty()` - empty value\n"""
                """* `notEmpty()` - not empty value\n"""
                """* `now()` - current time\n"""
                """* `today()` - current date\n"""
                """* `week()` - current week\n"""
                """* `month()` - current month\n"""
                """* `quarter()` - current quarter\n"""
                """* `year()` - current year\n"""
                """* `unresolved()` - there is no resolution\n"""
                """* `me()` - currently logged in user\n"""
                """# Examples\n"""
                """Find issues in a specific queue: `"Queue": "PROJ"`\n"""
                """Find issues by an assignee: `"Assignee": "i.ivanov"`\n"""
                """Find not resolved (open, in progress) issues: `"Resolution": unresolved()`\n"""
                """Find issues in specific status: `"Status": "Открыт", "В работе"`\n"""
                """Find issues created in a specific range: `"Created": "2017-01-01".."2017-01-30"`\n"""
                """Find issues created by currently logged in user: `"Author": me()"`\n"""
                """Find issues assigned to currently logged in user: `"Assignee": me()"`\n"""
                """Find issues created no earlier than 1 week and 1 day before today: `Created: > today() - "1w 1d"`\n"""
                """Complete instructions page is available here: https://yandex.ru/support/tracker/ru/user/query-filter\n"""
            )
        ),
    ]
  • The call to register_tools which defines and registers the 'issues_find' tool (along with other tools) to the FastMCP server instance.
    register_tools(settings, mcp)
  • Protocol definition for the underlying issues_find method called by the MCP handler.
    async def issues_find(
        self,
        query: str,
        *,
        per_page: int = 15,
        page: int = 1,
        auth: YandexAuth | None = None,
    ) -> list[Issue]: ...
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Find') but doesn't explicitly state safety aspects like whether it's non-destructive or has rate limits. The description hints at filtering capabilities but lacks details on pagination behavior or response format, which are partially covered in the input schema (e.g., 'page', 'per_page'). It adds some context but falls short of comprehensive behavioral transparency.

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 extremely concise—a single sentence that directly states the tool's purpose without any fluff. It's front-loaded with the core action and resource, making it efficient and easy to parse. Every word earns its place, achieving optimal brevity for the information conveyed.

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?

Given the tool's complexity (5 parameters, rich query functionality) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the primary use case (finding issues by queue/date) but could be more comprehensive by addressing sibling tool relationships or behavioral nuances. The high schema coverage and output schema reduce the burden on the description, making it adequate though not exhaustive.

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%, meaning all parameters are well-documented in the schema itself. The description mentions filtering by 'queue and/or created date', which aligns with the 'query' parameter but doesn't add significant meaning beyond what the schema provides (e.g., the schema details query syntax extensively). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description offers minimal additional parameter insight.

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 description clearly states the action ('Find') and resource ('Yandex Tracker issues') with specific filtering criteria ('by queue and/or created date'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'issues_count' or 'issue_get', which also involve issue retrieval, so it doesn't reach the highest score for sibling differentiation.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'issues_count' for counting issues or 'issue_get' for retrieving a single issue, nor does it specify prerequisites or contexts for usage. This lack of comparative guidance limits its effectiveness for agent decision-making.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aikts/yandex-tracker-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server