MCP server for Yandex Wiki with full-text search
Server implements 6 tools with mostly adequate naming (verb-first convention) and descriptions. Schemas are present and typed for all parameters. However, several critical issues reduce quality: (1) Missing output schemas, tool responses are undocumented, making it impossible for LLMs to plan downstream operations. (2) Parameter descriptions are minimal (10-30 chars on average) and lack actionable constraint details. (3) No error handling guidance, no recovery suggestions for common failure modes. (4) Missing validation constraints on string parameters (e.g., 'url' has no format or pattern; 'limit' has no min/max). (5) Composition issues, page_search and page_get overlap in intent and naming clarity. Overall: functional but below production baseline for agentic tools.
Upload an attachment/file to a Yandex Wiki page
Create a new page in Yandex Wiki
Delete a page from Yandex Wiki
Retrieve full content of a specific Yandex Wiki page by URL or ID
Search for pages in Yandex Wiki by full-text query
Update an existing Yandex Wiki page content
No output schemas documented for any tool. LLMs cannot infer what fields to expect, breaking downstream composition and forcing manual parsing.
Parameter descriptions are 10-60 chars on average, well below baseline (72 chars). Lack actionable constraints: 'url' has no format/pattern; 'limit' has no min/max; 'content' lacks format details.
No error handling guidance. Destructive operations (delete, update) lack recovery suggestions. No indication of retryable vs fatal errors. Missing pattern:recovery-guide implementation.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2025-06-18+ | v2 |
page_delete lacks dry-run or confirmation mechanism for destructive operations. No undo tool documented. Agents can permanently delete pages without safeguards.
Naming ambiguity: page_search vs page_get. Both retrieve pages but differ in mechanism (full-text vs direct). Names don't disambiguate. LLMs may choose wrong tool.
'url' parameter used across multiple tools but described as 'URL or page ID'. Type ambiguity forces LLM reasoning about which form to pass. Should accept both but with separate typed params or resolution logic.