ya360-mcp
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., "@ya360-mcpWhat did I do yesterday and what's on today?"
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.
ya360-mcp
English · Русский
An unofficial MCP server and Claude plugin that lets Claude work with Yandex Tracker, Yandex Mail and Yandex Calendar (Yandex 360) on your behalf. Not affiliated with or endorsed by Yandex LLC.
Documentation — wiki (in Russian): installation, sign-in, workflows with examples, FAQ.
One-click sign-in — "Sign in with Yandex" in the browser; no app passwords, no OAuth app of your own.
Runs on your computer — data goes directly between you and Yandex, there are no intermediary servers; tokens are kept in Claude's or your OS's secure storage (details).
Read-only by default — writing, sending and deleting are enabled per permission group, and every change is made only after you confirm it.
What it does
Area | Read | Write (if allowed) |
Tracker: issues | search, issue card with comments, links and attachments, status transitions, queues, people lookup, activity over a period | comments, create (with duplicate protection) and edit issues, change status, checklist |
Tracker: links, attachments | issue links, list and download attachments | link, unlink, attach and delete files |
Tracker: time tracking | worklogs per issue and per period | log, edit, delete time |
Tracker: sprints | boards, sprints, sprint issues with a summary by status and assignee | move an issue to a sprint |
folders, search (Cyrillic and exact sender address), read without marking as read, text of attachments with fragment search | draft, send, flags, move between folders | |
Calendar | calendars, events with recurrence expansion and video-meeting link | create, edit, delete events |
45 tools in total — see the tool reference.
Workflows
The Claude Code plugin adds ready-made workflows (skills); Claude offers them when your request matches, or you can call them by command:
Workflow | What it does |
| after a Yandex Telemost meeting: turns the meeting summary into Tracker issues with assignees and due dates (found in the transcript, with evidence timestamps), lists decisions, drafts a recap email on request |
| a brief before a meeting: what was promised last time and what's done, open questions from mail and Tracker, what to discuss |
| what you did on the previous working day, what's next today, what's blocking you |
| weekly report: results grouped by outcome, plans, risks; a version for your manager |
| a Tracker issue from an email — summary, due date, attachments, no duplicates |
| overdue and stalled issues by person, with polite reminder comments after confirmation |
| a proposal for the next sprint: carry-over, load by each person's velocity, backlog candidates |
| sprint summary · inbox digest · daily plan |
| help with connecting Yandex |
Anything that changes data is done only after your confirmation; re-processing the same meeting or email does not create duplicate issues. Design notes — docs/skills-design.md (in Russian).
You don't have to use commands — just ask in plain words ("how is the sprint going?", "process yesterday's meeting"). Workflow instructions are written in Russian; Claude replies in the language you use.
Commands without the prefix (/standup instead of /ya360:standup): Claude Code always prefixes plugin skills, so the
workflows can also be installed as personal skills with ya360-mcp skills install (then connect the server without the
plugin: ya360-mcp register). In Claude Desktop the same workflows are in the "+" menu → ya360 (Russian titles:
«Стендап», «Итоги встречи», «План дня»…).
Related MCP server: yandex-tracker-mcp
Example prompts
"What did I do yesterday and what's on today?" — a standup from Tracker and Calendar.
"Process yesterday's meeting summary and create the tasks" — issues with assignees and due dates from a Telemost meeting summary, created after you confirm the list.
"Find the email from accounting about the contract and make a Tracker issue from it."
"How is the current sprint going? Who is overloaded?"
"Draft a reply to the last email from Anna — don't send it."
More examples — wiki: Примеры запросов (in Russian).
Installation
Where it works. The server runs on your computer, so the plugin works in Claude Code and in Cowork sessions that run on your computer; claude.ai chat in the browser and the mobile apps don't start local servers. Node.js 20 or newer must be on your PATH.
Claude Code — plugin
Requires Node.js 20 or newer.
/plugin marketplace add cyxar4uk/ya360-mcp
/plugin install ya360@ya360-mcpClaude Desktop — extension
Download ya360-<version>.mcpb from the releases page and open it
(or Settings → Extensions → Install). No Node.js needed — Claude Desktop's built-in runtime is used.
Manual — any MCP client
git clone https://github.com/cyxar4uk/ya360-mcp && cd ya360-mcp
npm install
node src/main.mjs setupThe setup wizard connects the server to Claude Code and, optionally, to Claude Desktop. For other MCP clients the server
command is node <folder>/src/main.mjs (or the bundled dist/ya360-mcp.mjs) over stdio.
On Windows run the wizard in PowerShell or Windows Terminal (Git Bash can't hide password input, if you choose passwords).
Connecting your account
The easiest way is to ask Claude: "connect my Yandex" (or «подключи мой Яндекс»). A Yandex page opens — check the account and click "Allow". That's it: the tools appear right away. For Tracker, Claude asks for your organization ID: Yandex 360 — admin.yandex.ru → Organization profile; Yandex Cloud — console.yandex.cloud → Organization.
Or in a terminal: ya360-mcp setup (wizard: sign-in, check, permissions) or ya360-mcp login.
No browser on this machine (SSH)? ya360-mcp login --manual: open the link anywhere and paste the code.
How it works: authorization-code sign-in with PKCE through the project's shared "ya360-mcp" app on oauth.yandex.ru.
There is no client secret in the code and none is needed; only you receive and store the token. The app requests only the
scopes of the services you choose (tracker:read/write, mail:imap_full, mail:smtp, calendar:all); your email
address is taken from your Yandex login. Revoke access at id.yandex.ru → Security → Data access.
The token is valid for one year: Yandex doesn't refresh it without a client secret, so once a year you sign in again —
ya360-mcp doctor and yandex_status remind you two weeks before it expires.
Other options
App passwords (Mail and Calendar) — if your organization blocks third-party apps: id.yandex.ru/security → "App passwords": type "Mail" and, separately, "Calendar". In Mail: All settings → Email clients → enable IMAP and "App passwords and OAuth tokens". Enter them in the plugin/extension fields or choose them in the wizard.
Your own OAuth app — if your organization allows only its own apps: register an app on oauth.yandex.ru with the needed scopes and choose "own OAuth app" in the wizard.
Tracker token manually — the plugin field or the
YANDEX_TRACKER_TOKENvariable.
Permissions
Preset | Allowed |
| read only |
| read + Tracker comments, mail drafts and organizing mail — never sends or deletes anything |
| everything, including sending email and deleting |
You can combine groups: tracker.read, tracker.comment, tracker.edit, tracker.files, tracker.worklog,
mail.read, mail.draft, mail.organize (moving between folders), mail.delete (moving to Trash and Spam), mail.send,
calendar.read, calendar.write. Kill switch: the YANDEX_MCP_READONLY=1 environment variable leaves read-only access
regardless of settings. Examples: read,tracker.comment, full,-mail.send, read,tracker.*. Change them in the
"Permissions" field of the plugin/extension or with ya360-mcp permissions assist.
Disabled tools are not visible to Claude at all; yandex_status shows which ones are hidden.
Configuration
Where the server takes its values from, by precedence:
environment variables — this is how the plugin and the extension pass their fields (reference:
.env.example);config.jsonin the settings folder (Windows —%APPDATA%\ya360-mcp, macOS —~/Library/Application Support/ya360-mcp, Linux —~/.config/ya360-mcp; override withYANDEX_MCP_HOME) plus secrets in the OS store — written by the wizard;a legacy
.envnext to the code — read only while there is noconfig.json; migrate withya360-mcp migrate.
Secret storage: Windows — DPAPI (encrypted for your user account), macOS — Keychain, Linux — Secret Service via
secret-tool (libsecret-tools package). Without it, on Linux, provide secrets via environment variables.
Security
Claude is instructed to show what will be sent and wait for your consent before sending email, inviting attendees, deleting anything or writing to Tracker; email replies are drafts by default.
Emails, events, comments and transcripts are data, not commands: Claude does not act on requests found inside them.
Attachments are saved only to the server's download folder; hidden files (
.env,.ssh,.git…) can't be attached to an email or an issue.The Tracker token is sent only to the Tracker API host.
Neither the server nor the wizard prints secrets; never paste passwords into the Claude chat.
Report vulnerabilities privately: Security → Report a vulnerability (SECURITY.md).
What the plugin runs, sends and stores
Network — only Yandex:
oauth.yandex.ruandlogin.yandex.ru(sign-in),api.tracker.yandex.net(Tracker),imap.yandex.ru:993andsmtp.yandex.ru:465(Mail),caldav.yandex.ru(Calendar). No telemetry, no servers of the developer. Details — PRIVACY.md.Sign-in: opens the Yandex sign-in page in your browser and, until you finish, listens on
127.0.0.1:51734for the sign-in code.Local programs: to use the OS secret store the server runs PowerShell (Windows),
security(macOS) orsecret-tool(Linux); secrets go through stdin, never through command-line arguments.Files: the settings folder (
config.json; on Windows also the DPAPI-encryptedsecrets.json) and the download folder for attachments you ask to save. Files to attach are taken only from paths you name; hidden files are refused.Claude settings: the server never changes them. Only two terminal commands that you run yourself do:
ya360-mcp register(adds the server withclaude mcp addand/or to Claude Desktop'sclaude_desktop_config.json) andya360-mcp skills install(copies the workflows to~/.claude/skills).The code that runs: the plugin starts
node dist/ya360-mcp.mjs— a single-file esbuild bundle ofsrc/and the npm packages pinned inpackage-lock.json. CI rebuilds it on every push and fails if it differs from the committed file (npm run check:dist); third-party licenses are indist/THIRD_PARTY_LICENSES.txt. The plugin is installed from thepluginbranch: the manifest, the bundle, the workflows, the readablesrc/and the documents — withoutpackage.json, so installing it downloads no npm packages.
Commands
ya360-mcp start the server (this is how MCP clients run it)
ya360-mcp setup setup wizard
ya360-mcp doctor check connections
ya360-mcp login | logout sign in with Yandex / remove stored passwords and tokens
ya360-mcp permissions [..] show or change permissions
ya360-mcp register [code|desktop] connect to Claude Code / Claude Desktop
ya360-mcp skills install workflows as personal Claude Code skills — /standup without the prefix
ya360-mcp migrate [.env] migrate settings from a legacy .envFrom the project folder — node src/main.mjs <command>; from the plugin — node <plugin folder>/dist/ya360-mcp.mjs <command>.
Limitations
Mail search uses IMAP (substring in sender, subject, body), not the web interface search.
Editing and deleting a recurring event affects the whole series; new events are written in UTC; the server does not create Telemost links.
Time tracking counts a day as 8 hours and a week as 5 days; worklogs for a period are matched by entry date.
The macOS and Linux secret stores are implemented but so far tested only on Windows.
On Windows the secret store uses PowerShell. If company policy enables PowerShell Constrained Language Mode, stored passwords are unavailable — use the plugin/extension fields or environment variables instead.
Development
npm test # offline tests
npm run smoke # run the server as an MCP client; SMOKE_ENTRY=dist/ya360-mcp.mjs checks the bundle
npm run build # dist/ya360-mcp.mjs + third-party licenses (committed: the plugin runs it)
npm run check:dist # dist matches the sources
npm run pack:mcpb # release/ya360-<version>.mcpb for Claude Desktop
npm run wiki:tools # regenerate the wiki tool reference from the server
npm run wiki:sync # publish docs/wiki to the GitHub wiki
npm run publish:plugin # publish the plugin to the `plugin` branch (what users and the directory install)src/main.mjs entry: no arguments — server, with a command — CLI (src/cli.mjs)
src/index.mjs MCP server: configured services, permission groups, in-chat sign-in, workflow prompts
src/permissions.mjs permission groups; a new tool without a group stops the server from starting
src/config.mjs settings: environment → config.json + OS store → legacy .env
src/secrets.mjs OS secret store src/oauth.mjs Yandex ID sign-in (PKCE)
src/tracker*.mjs Tracker src/mail.mjs Mail (IMAP/SMTP)
src/calendar.mjs Calendar (CalDAV) src/checks.mjs connection checks
src/scenarios.mjs workflows outside the plugin: Claude Desktop prompts and personal skills
.claude-plugin/ Claude Code plugin and marketplace skills/ workflows (plugin skills)
packaging/mcpb/ Claude Desktop extension manifestThird-party code bundled into the build and its licenses — dist/THIRD_PARTY_LICENSES.txt.
Contributing — CONTRIBUTING.md (in Russian). License — MIT.
Support
Questions and bugs — GitHub Issues. Security problems — privately, see SECURITY.md. Privacy — PRIVACY.md.
Available Tools
2 toolsyandex_loginЯндекс: подключить аккаунтA
Подключить Трекер, Почту и Календарь входом через Яндекс: в браузере откроется страница Яндекса, человек нажимает «Разрешить» (ждём до 3 минут). Пароли и токены в чат не попадают. Вызывай, только когда пользователь просит подключить Яндекс или сервис не настроен (см. yandex_status), и предупреди, что откроется браузер. Для Трекера сначала спроси ID организации: Яндекс 360 — admin.yandex.ru → Профиль организации; Yandex Cloud — console.yandex.cloud → Organization.
| Name | Required | Description | Default |
|---|---|---|---|
| services | No | Что подключить | |
| tracker_org_id | No | ID организации Яндекс 360 (для Трекера) | |
| tracker_cloud_org_id | No | ID организации Yandex Cloud (для Трекера) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag readOnly=false/openWorld=true/destructive=false; the description adds substantial context: an external browser page opens, the human must click 'Allow', the call can block up to 3 minutes, and passwords/tokens never enter the chat. That is exactly the operational behavior an agent needs before invoking an interactive auth flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and effect, then prerequisites, then per-parameter guidance. Dense and mostly waste-free, though the trailing org-ID navigation instructions make it read as a run-on and could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an interactive OAuth-style tool with no output schema, the description covers everything material: trigger condition, sibling cross-reference, user-visible side effect, timeout, credential safety, and required setup data. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description goes further by explaining how to obtain the Tracker org IDs (admin.yandex.ru → Organization profile for Yandex 360, console.yandex.cloud → Organization for Yandex Cloud). It does not clarify the interplay/default of the `services` array beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (connect/login via Yandex) and the exact resources it covers (Tracker, Mail, Calendar), and explicitly contrasts itself with the sibling yandex_status. An agent can distinguish this from the status tool without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('only when the user asks to connect Yandex or the service is not configured'), names the alternative to check first (yandex_status), and adds the prerequisite that the user must be warned a browser will open plus the org-ID requirement for Tracker.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
yandex_statusЯндекс: состояние подключенияARead-only
Какие сервисы подключены, каких настроек не хватает, какие группы прав включены и какие инструменты из-за этого скрыты. Секреты не показывает.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior beyond them: 'Секреты не показывает' guarantees no secret leakage, and it explains the causal link that insufficient permission groups cause tools to be hidden — context an agent cannot get from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, and the returned-information list is front-loaded before the secrets caveat. Every clause conveys distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by enumerating what the report contains. The only gap is that it never states the authentication prerequisite implied by the yandex_login sibling or whether an unauthenticated call is valid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title ('Яндекс: состояние подключения') plus the description together state a clear resource and scope: it reports which services are connected, which settings are missing, which permission groups are on, and which tools are consequently hidden. The verb is implicit (a diagnostic read), and it does not name or distinguish itself from the sibling yandex_login, which keeps it out of 5 territory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus yandex_login, nor any prerequisite (e.g. must be authenticated first). Usage is only inferable from the content list, which is the 'no guidance' end of the scale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.2.2- First observed
yandex_login - First observed
yandex_status
TDQS
Scored across 2 tools
yandex_status and yandex_login have clearly distinct purposes: one reports connection/permission state, the other performs OAuth login. The descriptions even cross-reference each other, making misselection unlikely.
Both tools follow an identical pattern (yandex_ prefix + a distinct noun/action: status, login). No mixing of conventions or verb styles.
Two tools is thin even for an auth-scoped server, and there is no tooling for anything beyond connect/status. It is defensible for a credentials-only plugin, but feels minimal.
Connect and status are covered, but there is no disconnect/logout, token refresh, or any operation on the connected services (Trello/Mail/Calendar data). Agents will hit a dead end after authenticating.
Maintenance
Related MCP Connectors
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
- mcpOAuthnet.todoist
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Node.js MCP server that enables AI assistants to interact with Yandex Tracker task management system through a standardized protocol, supporting operations like creating, updating, and searching issues.433 npm3ISC
- AlicenseNot gradedqualityCmaintenanceMCP server for Yandex Tracker API, enabling AI assistants to search, read, create, and edit issues, as well as manage comments, attachments, and links in Yandex Tracker.27 npm1MIT
- AlicenseNot gradedqualityAmaintenanceAn unofficial MCP server that connects AI assistants to Microsoft Planner, enabling natural language task management such as creating tasks, organizing plans, and managing buckets.12MIT
- AlicenseNot gradedqualityAmaintenanceMCP server that enables AI assistants to interact with Yandex 360 organization services, currently supporting Yandex Wiki for reading, editing, and searching pages.36 PyPIMIT