Yandex Tracker MCP Server
# Yandex Tracker MCP Server
Local [Model Context Protocol](https://modelcontextprotocol.io/) server (Node.js + TypeScript) that exposes the [Yandex Tracker REST API v3](https://yandex.ru/support/tracker/en/api-ref/about-api) as tools for LLM clients. Transport is **stdio** only (the host spawns the process; there is no HTTP port).
## Prerequisites
- Node.js **18+**
- A Tracker OAuth token and organisation ID (see below)
## Install and run
```bash
npm install
npm run build # compile to dist/
npm run start # run compiled server (used by MCP hosts)
```
Other scripts:
| Script | Purpose |
|--------|---------|
| `npm run clean` | Remove the `dist/` directory |
| `npm run dev` | Run `src/index.ts` with [tsx](https://github.com/privatenumber/tsx) (handy for quick local checks; MCP hosts normally use `start`) |
After `clean`, run `build` again before `start`.
## Configuration
1. Copy `.env.example` to `.env` and fill in values (do not commit `.env`).
2. Required variables:
- `TRACKER_TOKEN` — OAuth token (see below)
- `TRACKER_ORG_ID` — Organisation ID from [Tracker administration → Organisations](https://tracker.yandex.com/admin/orgs)
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)
## Getting a Tracker OAuth token
1. **Create an OAuth app** at [https://oauth.yandex.ru/](https://oauth.yandex.ru/) (choose API access / debugging, add scopes **`tracker:read`** and **`tracker:write`**, note the **Client ID**).
2. **Authorize in the browser** (implicit flow). Open (replace `YOUR_CLIENT_ID`):
[https://oauth.yandex.com/authorize?response_type=token&client_id=YOUR_CLIENT_ID](https://oauth.yandex.com/authorize?response_type=token&client_id=YOUR_CLIENT_ID)
3. After you approve access, the redirect URL will contain `access_token=...`. Copy that value into `TRACKER_TOKEN`.
4. **Smoke test** (optional):
```bash
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.
## Using with Cursor
1. Build the project and note the **absolute path** to `dist/index.js`.
2. Edit your MCP config (e.g. `~/.cursor/mcp.json`) and add a server entry. Example:
```json
{
"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.
3. Restart Cursor. In chat, try: use the Tracker MCP to call **`get_myself`** to verify auth.
## Using with Claude Desktop
1. Build the project and note the **absolute path** to `dist/index.js`.
2. Edit the Claude Desktop config file:
- **macOS:** `~/Library/Application Support/Claude/claude_desktop_config.json`
- **Windows:** `%APPDATA%\Claude\claude_desktop_config.json`
3. Under `mcpServers`, add the same shape as in the Cursor example (`command`, `args`, `env`).
4. Fully quit and reopen Claude Desktop, then use a task that invokes Tracker tools (e.g. **get_myself**).
## Project layout (high level)
- `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
## License
Private / use as you prefer unless you add a formal license file.
TDQS
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.