Yandex Workspace MCP
An MCP server for Yandex Disk and Yandex Wiki with separate read, write and delete permissions, a path allowlist and audit logging
Medium risk
We rate an entry medium when the tool runs code, makes network calls or reads project files. Check what exactly it does before installing.
Why this level
- Disk and Wiki write and delete can be enabled via separate variables, off by default
- The OAuth token grants access to data within the allowed roots and the application's scopes
- Start with DISK_READ and WIKI_READ without DISK_WRITE and WIKI_WRITE until write access is actually needed
Install
Manual install
git clone https://github.com/denis-samatov/yandex-workspace-mcp.git
cd yandex-workspace-mcp
uv syncInstall dependencies with uv.
This is third-party code. Review the repository files before installing.
What it does
The server combines Yandex Disk and Yandex Wiki behind one MCP interface: 22 tools for Disk and 27 for Wiki, plus a shared search tool that queries both services at once. By default the server is read-only; write and delete are turned on separately via DISK_WRITE, DISK_DELETE, WIKI_WRITE and WIKI_DELETE. Access to Disk and Wiki is restricted by an ALLOWED_ROOTS allowlist, with every operation checked against the allowed roots before and after the request. Deleting a configured root entirely is refused, and emptying the Disk trash only works with an explicit global-destructive flag plus a literal confirm=true on each call. Every write and destructive operation is written to a structured audit log.
Who it is for. For teams who want to give an agent access to their Yandex Disk and Wiki workspace with tight permission control and an action trail.
Good fit when
- You need one search across both Disk and Wiki from a single agent request
- You need to restrict an agent to specific folders and sections rather than the whole account
- You need an audit log of what an agent changed and when
Not a fit when
- You want a simple server with no permission setup: the configuration here is detailed and expects a deliberate choice for every permission
- You need Disk access without Wiki, or vice versa, with minimal config: both services have their own settings blocks but share one config file
Example request
Find every mention of project Atlas across Wiki and Disk and show me where each one livesLimitations
It needs a Yandex OAuth token with Disk scopes and, when Wiki is enabled, a separate organization ID. Multi-user HTTP mode needs Redis, token encryption keys and a registered callback URL. Install is via uv; there was no packaged PyPI release at review time. Wiki full-text search relies on undocumented field stability in the API and falls back to a bounded descendants scan, flagged degraded, when it drifts.
How to disable. Remove the server from your MCP client config, revoke the Yandex OAuth token, and if multi-user mode was used, delete the application's registered callback URL.
MCP
- Transport
- stdio, http
- Authentication
- API key
| Environment variables | |
|---|---|
| YANDEX_OAUTH_TOKEN required, secret | Yandex OAuth token with Disk and, if needed, Wiki scopes |
| YANDEX_WIKI_ORG_ID | Organization ID, required for Wiki under an org account |
| DISK_READ | Enables Disk read tools, defaults to true |
| DISK_WRITE | Enables Disk write tools, defaults to false |
| DISK_DELETE | Enables Disk deletion and trash restore, defaults to false |
| DISK_ALLOWED_ROOTS | List of allowed Disk root paths |
| WIKI_READ | Enables Wiki read tools, defaults to true |
| WIKI_WRITE | Enables Wiki page and grid writes, defaults to false |
| WIKI_DELETE | Enables Wiki page deletion and recovery, defaults to false |
| WIKI_ALLOWED_ROOTS | List of allowed Wiki root sections |
Security check
- Disk and Wiki write and delete can be enabled via separate variables, off by default
- The OAuth token grants access to data within the allowed roots and the application's scopes
- Start with DISK_READ and WIKI_READ without DISK_WRITE and WIKI_WRITE until write access is actually needed
README in short
The English README describes the project as a security-first server for Disk and Wiki with explicit read, write and delete permissions. It details the .env configuration: path allowlists, upload limits, allowed hosts for URL import, stdio and streamable-http transport modes with three auth options, and token encryption keys. Separate sections explain Disk and Wiki tool permission gates, search behavior and the fallback mode on API drift, OAuth setup steps, and a Claude Desktop and Cursor config example. The project has contract and security test suites, a Dockerfile and docker-compose.
FAQ
Can the agent delete the entire Disk or Wiki?
No, deleting a configured root entirely is refused, and emptying the Disk trash only works with a separate global-destructive flag plus a literal confirm=true on every call.
How do I restrict the agent to one folder?
Via the DISK_ALLOWED_ROOTS and WIKI_ALLOWED_ROOTS variables listing allowed paths; every request is checked against these roots before and after the API call.
Related
A self-hosted knowledge base with block-level references and a built-in MCP server for connecting AI agents to your notes
A CLI for every Google Workspace API with JSON output and agent skills: Drive, Gmail, Calendar, Sheets and more
Local search over Markdown notes, docs and meeting transcripts: keywords, semantic search and reranking, with an MCP server
A task manager for AI-driven development: breaks a PRD into dependent tasks and guides the agent through them via MCP or CLI