Skip to main content
Glama

Search Wiki

page_search
Read-only

Search Yandex Wiki by full text with optional server-side filters for pages, type, dates, or section. Returns ranked pages and files with excerpts, so you can find the right document.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of search results to return (1-50). Filters are applied by the search backend before this limit, so filtered searches do not need a larger limit to compensate. With highlight=true every page is hard-capped at 10 results, and this value only trims below that cap.
queryYesFull-text search query over the whole Wiki. Wrap a multi-word exact phrase in double quotes.
cursorNoPage number for paging through results, as echoed in `next_cursor` (pages count from 1). Works only together with highlight=true — without it the backend ignores the cursor, so this tool refuses the combination.
authorsNoOptional server-side filter by page owner: a list of user identities (each with uid or cloud_uid), ORed together. Take your own from user_get_current's identity. Omit it to search every author — an empty list is rejected, because it would silently mean the same thing. An unknown identity simply yields no results.
highlightNoWrap query matches inside `content` excerpts in <em>…</em> tags. Also a mode switch, not just markup: it caps every page at 10 results regardless of `limit`, and it is the only mode where `cursor` pages deeper (up to ~100 results).
result_typeNoOptional server-side filter by result type.
slug_prefixNoOptional server-side section filter: only results whose slug equals this prefix or lies under it, e.g. 'tech-doc/ml'. Deep prefixes are fine. An unknown prefix simply yields no results.
created_betweenNoOptional server-side filter by creation time. Both bounds are required — the API rejects open intervals.
modified_betweenNoOptional server-side filter by last-modification time. Both bounds are required — the API rejects open intervals.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsNo
next_cursorNo
prev_cursorNo
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only state readOnlyHint=true and openWorldHint=false; the description carries the full behavioral burden and delivers it richly: the default one-shot mode with cursors staying null, the hard 10-result cap with highlight=true, the ~100-result reach, and the genuinely surprising trap that next_cursor keeps incrementing over empty pages so it alone does not mean 'more exists'. It also discloses that the content excerpt is not a summary and may lack the query terms. Description is fully consistent with the read-only and open-world hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but remarkably dense; nearly every sentence conveys a distinct piece of behavior or usage constraint. It is front-loaded with the core purpose, then covers modes, pagination, excerpt semantics, quoting, and sibling routing. The few schema-related duplications (phrase quoting, filter-before-limit) are brief.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 9 parameters, two pagination modes, and a non-obvious output hazard, nothing an agent needs to safely invoke it is missing: result shape, mode selection, termination condition, the excerpt's meaning, filter placement, and the correct sibling for enumeration. The presence of an output schema means return values do not need restating, and the description still mentions them.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each parameter description is already detailed, so the baseline is 3. The tool description adds real value beyond the schema by explaining how the parameters interact at runtime: the cursor/higher-light combination and its result cap, that default-mode cursors stay null, and the empty-page cursor behavior. The only reason this is not a 5 is that the schema alone already explains limit, cursor, highlight, and the filter-before-limit semantics; the description grooms but does not dramatically expand parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource ('Full-text search across the entire Yandex Wiki') and lists exactly what results carry: title, slug, url, and content excerpt. It names sibling page_get for reading full content and page_get_descendants for enumeration, so an agent can distinguish this tool from its siblings without opening their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly routes usage: 'Use this tool to DISCOVER pages, then call page_get with a result's slug to read full content' and 'To enumerate a section (or the whole Wiki) rather than search it, use page_get_descendants.' It also explains when the highlight/cursor paginated mode is the right choice versus the default one-shot mode, and warns how to recognize when the result set is over.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dlbolshov/yandex-wiki-search-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server