Provides an optional sync map for agent-driven synchronization between Yandex Tracker and Miro, enabling cross-platform issue and board management.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Yandex Tracker MCP Server show me open issues in queue TEST"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Local Model Context Protocol server (Node.js + TypeScript) that exposes the Yandex Tracker REST API v3 as tools for LLM clients. Transport is stdio only (the host spawns the process; there is no HTTP port).
Node.js 18+
A Tracker OAuth token and organisation ID (see below)
Related MCP server: Yandex Tracker MCP
npm install
npm run build # compile to dist/
npm run start # run compiled server (used by MCP hosts)Other scripts:
Script | Purpose |
| Remove the |
| Run |
After clean, run build again before start.
Copy .env.example to .env and fill in values (do not commit .env).
Required variables:
TRACKER_TOKEN — OAuth token (see below)
TRACKER_ORG_ID — Organisation ID from Tracker administration → Organisations
Optional:
TRACKER_ORG_HEADER — X-Org-ID (Yandex 360, default) or X-Cloud-Org-ID (Yandex Cloud)
TRACKER_BASE_URL — default https://api.tracker.yandex.net/v3; change for self-hosted
TRACKER_AUTH_SCHEME — OAuth (default) or Bearer (e.g. IAM)
Create an OAuth app at https://oauth.yandex.ru/ (choose API access / debugging, add scopes tracker:read and tracker:write, note the Client ID).
Authorize in the browser (implicit flow). Open (replace YOUR_CLIENT_ID):
https://oauth.yandex.com/authorize?response_type=token&client_id=YOUR_CLIENT_ID
After you approve access, the redirect URL will contain access_token=.... Copy that value into TRACKER_TOKEN.
Smoke test (optional):
curl -sS 'https://api.tracker.yandex.net/v3/myself' \
-H 'Authorization: OAuth YOUR_TOKEN' \
-H 'X-Org-ID: YOUR_ORG_ID'401 usually means a bad token; 403 often means a wrong org header or ID.
Build the project and note the absolute path to dist/index.js.
Edit your MCP config (e.g. ~/.cursor/mcp.json) and add a server entry. Example:
{
"mcpServers": {
"tracker-custom": {
"command": "node",
"args": ["/absolute/path/to/tracker-mcp-server/dist/index.js"],
"env": {
"TRACKER_TOKEN": "your_oauth_token",
"TRACKER_ORG_ID": "your_org_id",
"TRACKER_ORG_HEADER": "X-Org-ID",
"TRACKER_BASE_URL": "https://api.tracker.yandex.net/v3",
"TRACKER_AUTH_SCHEME": "OAuth"
}
}
}
}You can rely on a .env file only if your host loads it; many setups pass env explicitly as above.
Restart Cursor. In chat, try: use the Tracker MCP to call get_myself to verify auth.
Build the project and note the absolute path to dist/index.js.
Edit the Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Under mcpServers, add the same shape as in the Cursor example (command, args, env).
Fully quit and reopen Claude Desktop, then use a task that invokes Tracker tools (e.g. get_myself).
src/index.ts — MCP entry, registers tools, stdio transport
src/tracker-client.ts — HTTP client for Tracker API
src/tools/*.ts — tool implementations (read, write, validate, checklist, sync)
convention.json — validation rules for validate_issue / audit_queue
sync-map.json — optional Tracker ↔ Miro id map for agent-driven sync
Private / use as you prefer unless you add a formal license file.
Adds one checklist row to an issue. Only text is required; optional checked, assignee (login or id), and deadline (date ISO string + deadlineType, default date).
Inputs: issue_key (required), text (required), checked, assignee, +2 more.
Adds a comment to an issue. When posting on behalf of the agent, always begin the comment with '[AI Agent]:' so assignees know it is automated.
Inputs: issue_key (required), text (required), mention.
Validates all open issues in a queue against convention.json and returns a violation report. Always run as dry_run=true first and show the user the results before posting any comments. Only set post_comments=true after the user explicitly confirms. Comment posts are throttled (~200ms between each, plus an extra ~200ms after every 10 posts) to reduce rate-limit risk.
Inputs: queue (required), sprint, post_comments, dry_run.
Deletes the entire checklist on an issue (all items at once). Destructive — confirm with the user before calling.
Inputs: issue_key (required).
Creates a new Tracker issue. Always confirm queue and summary before creating. Returns the new issue key so the user can reference it immediately.
Inputs: queue (required), summary (required), type, description, +8 more.
Removes a single checklist item from an issue. Requires the checklist item id from list_checklist_items.
Inputs: issue_key (required), item_id (required).
Returns the full child hierarchy under an epic: stories, tasks, and subtasks nested under their parents. Use when the user wants to see the full breakdown of a feature or initiative.
Inputs: epic_key (required), include_closed.
Gets full details of a single issue by key (e.g. BACK-42). Use when you need the complete picture: all fields, description, checklist, linked issues. Use list_issues first if you do not have the exact key.
Inputs: issue_key (required), include_comments, include_checklist.
Returns the Tracker↔Miro sync map from sync-map.json (board item IDs paired with issue keys). Use before two-way sync: find which issues already map to Miro widgets, or resolve a Miro item ID to a Tracker key. Combine with the Miro MCP server to read/update board content. Optional filters narrow the result.
Inputs: board_id, tracker_key.
Verifies API credentials and returns the current authenticated user's login, display name, and email. Call this first in any new session to confirm the connection is working before calling other tools.
Inputs: no named parameters.
Creates a typed link between two issues. Use to connect related work, mark blockers, or set parent-child relationships.
Inputs: from_key (required), to_key (required), link_type (required).
Lists all checklist items on an issue. Use get_issue with include_checklist or this tool to obtain item ids before update_checklist_item or delete_checklist_item.
Inputs: issue_key (required).
Lists all components in a queue. Use this to validate component names before creating or updating issues. Component names must match exactly.
Inputs: queue.
Lists Tracker issues with optional filters. Use this when the user asks to show, find, list, or check issues. Returns key, summary, status, assignee, priority, components, sprint, storyPoints. Always call this before update_issue or add_comment if you only have a description and not an issue key.
Inputs: queue, status, assignee, component, +3 more.
Lists all sprints for a queue ordered by start date, with status (active/upcoming/closed). Use this to find the current sprint ID or to resolve a sprint name the user mentioned.
Inputs: queue (required).
Searches issues using a raw Yandex Tracker Query Language (YQL) string. Use for complex filters that list_issues cannot express. Example query: 'Queue: BACK AND Status: Open AND Tags: backend'. Prefer list_issues for simple cases.
Inputs: query (required), limit.
Scrollable issue search for very large result sets (10k+ matches). First call: pass query (YQL) and optional per_scroll (max 1000), scroll_type (sorted|unsorted), scroll_ttl_millis. Returns issues plus next_scroll_id — pass that id back with the SAME query on the next call until next_scroll_id is null. Do not use queue-only search body here; use a query or filter-style search per Tracker API scroll rules.
Inputs: query (required), scroll_id, per_scroll, scroll_type, +1 more.
Updates one checklist item by its id (from list_checklist_items). The Tracker API requires the item text on each edit — if you omit text, the current text is loaded automatically. Pass checked/assignee/deadline only when changing them.
Inputs: issue_key (required), item_id (required), text, checked, +3 more.
Updates fields on an existing issue. Only changed fields need to be provided. Pass assignee as an empty string to clear assignee (sends null); some Cloud orgs or queues reject this and require an assignee. For status changes, use the transition flow: first GET /issues/{key}/transitions, then POST /issues/{key}/transitions/{id}/_execute. Do not attempt to set status directly as a field — it will fail silently.
Inputs: issue_key (required), summary, description, assignee, +5 more.
Updates sync-map.json with new or changed Tracker↔Miro pairs after creating or matching board items. Writes are serialized so parallel tool calls cannot corrupt the file. Use mode 'upsert' (default) to merge by board_id + tracker_key; use 'replace_all' to set the full mapping list for one board (pass only entries for that board plus other boards' entries you want to keep — safer to read first with get_miro_sync_map). Prefer upsert when adding one pair at a time.
Inputs: entries (required), mode, board_id_for_replace.
Checks whether one issue satisfies the team's ticket convention defined in convention.json. Returns a list of missing fields and violations. Does NOT post a comment automatically — use add_comment separately after showing the user the violations first.
Inputs: issue_key (required).
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 21 tools
Each tool serves a clearly distinct purpose. Checklist operations are separated into add, list, update, delete, and clear. Issue operations are similarly granular. Even similar tools like search_issues and search_issues_scroll are differentiated by scroll capability, leaving no ambiguity.
All tools follow a consistent verb_noun pattern using snake_case (e.g., add_checklist_item, list_components, update_issue). The naming is predictable and uniform across the entire set.
With 21 tools, the server covers the typical lifecycle of an issue tracker: CRUD for issues and checklists, search, linking, comments, sprints, components, validation, and Miro sync. The count is well-scoped for the domain without being too sparse or excessive.
The tool surface covers most essential operations: issue creation, retrieval, update, checklist management, linking, commenting, validation, and sprint/component listing. Minor gaps exist, such as no tool for deleting an issue or removing a link, but these are not critical dead ends.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Every Canopy public API operation as a tool, run as you after a browser sign-in or on an API key.
AI-callable tools for API mocking, testing, monitoring, security, and automation.