Full-text search across the entire Yandex Wiki. Returns results (pages and files) ranked by relevance, each with a title, slug, url, and a text excerpt in content. Two modes: by default one call returns the top limit (up to 50) results and that is the whole reachable set — the response cursors stay null. With highlight=true the search switches to a paginated mode: pages are hard-capped at 10 results no matter the limit, and cursor (the page number echoed back in next_cursor) walks up to ~100 results — deeper than the default mode reaches. The set is over when results comes back empty or next_cursor is null on a non-empty page; past the end next_cursor keeps incrementing over empty pages, so do not treat it alone as 'more exists'. Use this tool to DISCOVER pages, then call page_get with a result's slug to read full content. content is an excerpt of at most ~510 characters cut from wherever the match sits in the page — not the page and not a summary of it, with no guarantee the query terms are even inside it — so treat it as a relevance signal and read the page before answering from it. Wrap multi-word exact phrases in double quotes. All filters (slug_prefix, result_type, authors, dates) run in the search backend itself, before the result limit, so a filtered search does not lose matches to it. To enumerate a section (or the whole Wiki) rather than search it, use page_get_descendants.

Get a Yandex Wiki page by page_id or slug.

Get the subtree of Yandex Wiki pages under a parent page. Returns descendants from ALL nesting levels as one flat list of {id, slug} items — slugs encode the hierarchy ('/x/y' is nested under '/x'), so the tree can be reconstructed without further calls. Combine with fetch_all=true to map a whole section at once; if the result comes back truncated=true, continue via next_cursor or narrow down by calling this tool on a subsection's slug. Pass from_root=true instead of page_id/slug to enumerate the WHOLE Wiki, top-level pages included — the way to inventory an organization when no starting slug is known. Prefer a section slug when you have one: a full wiki is routinely thousands of pages, so a root walk costs many requests and a large reply, and fetch_all stops at its ~500-item cap with truncated=true.

Get comments for a Yandex Wiki page.

Get resources linked to a Yandex Wiki page, including attachments and grids.

Get dynamic tables attached to a Yandex Wiki page.

Get a Yandex Wiki dynamic table by grid ID.

Get attachments for a Yandex Wiki page.

Read a Yandex Wiki page attachment's content into the conversation (nothing is saved anywhere): PNG/JPEG/GIF/WebP images arrive as a native image block — vision-capable clients render and see them — text files (SVG included, it is XML) as text, anything else base64-encoded. Meant for images and text attachments — diagrams, screenshots, configs, CSVs, logs. Refuses non-image content over 128 KiB and images over 2 MiB. Use page_download_attachment to save it locally, or fetch the attachment's download_url from page_get_attachments yourself. page_get_attachments is also where file ids come from.

Get the calling Yandex Wiki user: username, home_cluster (the caller's personal-section slug, e.g. 'users/' — where 'create it in my section' requests belong), and identity/org ids.

Create a Yandex Wiki dynamic table resource on a page. This changes structured data.

Update a Yandex Wiki dynamic table. Fetch the grid first and pass the latest revision. This changes structured data.

Add rows to a Yandex Wiki dynamic table. Fetch the grid first and pass the latest revision. This changes structured data.

Delete a Yandex Wiki dynamic table. This changes structured data and is destructive.

Copy a Yandex Wiki dynamic table to an existing target page. This starts an asynchronous operation and returns operation metadata.

Update cells in a Yandex Wiki dynamic table. This changes structured data. Each cell patch must include row_id, value, and exactly one of column_id or column_slug.

Delete rows from a Yandex Wiki dynamic table. Fetch the grid first and pass the latest revision. This changes structured data.

Add columns to a Yandex Wiki dynamic table. Fetch the grid first and pass the latest revision. This changes structured data.

Delete columns from a Yandex Wiki dynamic table. Fetch the grid first and pass the latest revision. This changes structured data.

Move a row inside a Yandex Wiki dynamic table. Fetch the grid first and pass the latest revision. This changes structured data.

Move a column inside a Yandex Wiki dynamic table. Fetch the grid first and pass the latest revision. This changes structured data.

Create a Yandex Wiki page. Content is Markdown (YFM): plain Markdown renders as-is, but GitHub-specific extensions ('[!NOTE]' alerts, raw HTML) do not — see the wiki-mcp://yfm-cheatsheet resource for YFM equivalents.

Update an existing Yandex Wiki page: title, content, or a redirect to another page. Content replacement is full-page when content is provided. Content is Markdown (YFM): plain Markdown renders as-is, but GitHub-specific extensions ('[!NOTE]' alerts, raw HTML) do not — see the wiki-mcp://yfm-cheatsheet resource for YFM equivalents.

Edit a Yandex Wiki page by exact-text replacements, without resending the whole page: reads the current content, applies the replacements in order, and writes the result back with a single update. Each old_text must match the stored YFM markup exactly (copy it from page_get, whitespace included) and occur exactly once unless replace_all is set — a missing or ambiguous match fails the whole call before anything is written. NOTE: the Wiki API has no page revisions, so the read-modify-write is not atomic; allow_merge (on by default) asks Wiki to merge a concurrent edit that landed in between rather than overwrite it. Do NOT blindly retry a call whose result you did not see: a replacement whose new_text contains its own old_text applies again on a repeat. Content is Markdown (YFM): plain Markdown renders as-is, but GitHub-specific extensions ('[!NOTE]' alerts, raw HTML) do not — see the wiki-mcp://yfm-cheatsheet resource for YFM equivalents.

Append content to the top, bottom, or anchor of a Yandex Wiki page. Content is Markdown (YFM): plain Markdown renders as-is, but GitHub-specific extensions ('[!NOTE]' alerts, raw HTML) do not — see the wiki-mcp://yfm-cheatsheet resource for YFM equivalents.

Copy a Yandex Wiki page to a new slug and return the copy's id and slug once the operation completes. Copies title and content only: child pages, comments, attachments, and edit history stay with the original, and the copy gets a new page id. Fails when the target slug is already occupied. The Wiki API has no true move/rename; to relocate a page, clone it and delete the original — re-uploading attachments and re-creating grids on the copy if they must follow.

Add a comment to a Yandex Wiki page.

Delete a comment from a Yandex Wiki page and return the page's updated comment count. Comment ids come from page_get_comments.

Delete an attachment from a Yandex Wiki page. File ids come from page_get_attachments. Does not touch page content — any file macro referencing the attachment stays behind, broken.

Delete a Yandex Wiki page and return a recovery token.

Recover a deleted Yandex Wiki page using a recovery token.

Upload a local file to Yandex Wiki and attach it to a page.

Download a Yandex Wiki page attachment to a local file: the bytes stream to disk without a size cap and never enter the conversation — the counterpart to page_read_attachment, for getting the artifact itself (a PDF, an archive, a large export). Writes atomically; refuses to replace an existing file unless overwrite is true. File ids come from page_get_attachments.