Yandex Tracker MCP Server

Overview Schema Source Related Servers Discussions Admin

Get All Queues

queues_get_all

Read-only

Retrieve all Yandex Tracker queues available to the user, with optional pagination and field selection to manage context limits.

Instructions

Find all Yandex Tracker queues available to the user (a queue is a project in some sense). page defaults to None and fetches ALL pages; pass a page number only when the result does not fit the context window.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number to return, default is None which means to retrieve all pages. Specify page number to retrieve a specific page when context limit is reached.
`fields`	No	Fields to include in the response; omitting returns ALL of them (unlike project_find/portfolio_find/goal_find, which default to a small subset). key and name are usually enough.
`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.

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.3/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true, so the read-only nature is covered. The description adds useful behavioral context beyond that: the default behavior of fetching ALL pages, the context-window consideration, and that the result is scoped to queues available to the user. This is valuable because page semantics can otherwise be surprising.

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 two short sentences with the purpose front-loaded and pagination guidance immediately after. Every sentence earns its place, and the parenthetical about queues being projects adds useful domain context without bloating the text.

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?

Given the readOnlyHint annotation, the extensive schema descriptions, and the presence of an output schema, the description covers the essential operational guidance: what the tool returns, its scope, and how to handle pagination when context limits are hit. Nothing critical is missing for an agent to call it correctly.

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%, and the schema already thoroughly documents page, fields, and per_page, including defaults and the restart-on-per_page-change caveat. The tool description repeats the page default but adds little beyond the schema, so the baseline of 3 applies.

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 states a specific action and resource: 'Find all Yandex Tracker queues available to the user.' It clearly distinguishes this list-all operation from sibling tools like queue_get_metadata or queue_get_components by emphasizing scope ('all queues available to the user') and the pagination behavior tied to fetching all pages.

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 page parameter: only pass a page number when the result does not fit the context window; otherwise fetch all pages. It does not explicitly name alternatives or when-not-to-use the tool versus siblings, but the pagination guidance is actionable and unambiguous.

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

Deploy Server