Skip to main content
Glama
aikts

Yandex Tracker MCP

issues_count

Count Yandex Tracker issues based on a custom query to filter by fields, status, dates, or logical conditions. Simplify issue tracking by extracting specific metrics.

Instructions

Get the count of Yandex Tracker issues matching a query

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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

  • MCP tool handler for 'issues_count'. Delegates to the underlying IssueProtocol.issues_count method with authentication.
    @mcp.tool(description="Get the count of Yandex Tracker issues matching a query")
    async def issues_count(
        ctx: Context[Any, AppContext],
        query: YTQuery,
    ) -> int:
        return await ctx.request_context.lifespan_context.issues.issues_count(
            query,
            auth=get_yandex_auth(ctx),
        )
  • Input schema for the 'query' parameter of the issues_count tool, defining it as a string with detailed Yandex Tracker Query Language instructions.
    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"""
            )
        ),
    ]
  • Registration of all MCP tools, including 'issues_count', via the register_tools function call on the FastMCP server instance.
    register_tools(settings, mcp)
  • Core implementation of issues_count in the TrackerClient, performing a POST request to Yandex Tracker API v3/issues/_count endpoint.
    async def issues_count(self, query: str, *, auth: YandexAuth | None = None) -> int:
        body: dict[str, Any] = {
            "query": query,
        }
    
        async with self._session.post(
            "v3/issues/_count", headers=await self._build_headers(auth), json=body
        ) as response:
            response.raise_for_status()
            return int(await response.text())
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the tool's behavior as a read operation ('Get'), but lacks details on rate limits, authentication needs, error handling, or performance characteristics. The description doesn't contradict any annotations (none exist), but provides only basic behavioral context.

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, efficient sentence that front-loads the core purpose ('Get the count of Yandex Tracker issues matching a query') with zero wasted words. It immediately communicates the tool's function without unnecessary elaboration.

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 simplicity (one parameter with full schema coverage and an output schema exists), the description is reasonably complete. It states the purpose clearly, though it could benefit from more behavioral context (e.g., noting it's a read-only operation or typical use cases). The existence of an output schema means return values need not be explained.

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%, with the 'query' parameter extensively documented in the schema (including syntax, examples, and functions). The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate as the schema does all the heavy lifting.

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 clearly states the specific action ('Get the count') and resource ('Yandex Tracker issues matching a query'), distinguishing it from sibling tools like 'issues_find' (which retrieves full issue data) and 'issue_get' (which retrieves a single issue). The verb 'count' precisely indicates the tool's function.

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 implies usage context by mentioning 'matching a query,' suggesting this tool is for filtered counting rather than retrieving individual issues. However, it doesn't explicitly state when to use this tool versus alternatives like 'issues_find' for detailed results or when not to use it (e.g., for unfiltered counts).

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