yandex-wiki-search-mcp
Server Quality Checklist
Latest release: v1.5.0
- Disambiguation5/5
Each tool targets a distinct resource and action: page operations, grid operations, comments, attachments, and search are clearly separated. Even similar tools like grid_update vs grid_update_cells serve different purposes, and overlapping helpers like page_get_resources are explicitly documented.
Naming Consistency5/5All tools follow a consistent <resource>_<action> pattern (e.g., page_get, page_create, grid_delete_rows, grid_update_cells). There is no mixing of conventions or vague verbs, making the naming predictable and easy to navigate.
Tool Count3/5The 27 tools are on the heavy side, exceeding the 15-tool sweet spot. However, the complexity of managing wiki pages plus dynamic tables (grids) with row/column operations justifies the count, and each tool has a clear niche.
Completeness4/5The tool surface is quite comprehensive, covering page CRUD, search, comments, attachments, and extensive grid management. Minor gaps exist, such as no update or delete for comments/attachments, but these are workable and do not block core workflows.
Average 4/5 across 27 of 27 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 54 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=false but no readOnlyHint. The description adds no extra behavioral context beyond the obvious additive nature of 'add'. It doesn't disclose side effects like comment visibility, permission requirements, or what happens if parent_id is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action. It is not bloated, though it does closely mirror the title 'Add Page Comment' with the added 'Yandex Wiki' context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple write tool, the description plus schema and annotations provide the necessary mechanics. However, it lacks any high-level guidance on how the parameters relate (e.g., 'use parent_id to reply in a thread'), though the schema individually covers this. An output schema exists, so return values need no explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has clear descriptions (e.g., 'Provide either page_id or slug', 'Optional parent comment ID'). The tool description adds no additional parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a comment') and the target ('a Yandex Wiki page'). This distinguishes it from sibling tools like page_get_comments (read) and page_update (modify page content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool versus alternatives, nor does it mention any exclusions or required prerequisites. For example, it doesn't say 'Use this to add comments, use page_get_comments to read them'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation, so the description doesn't need to restate that. However, it adds no behavioral context beyond the literal action—no mention of pagination, response shape, or any side effects. The bare statement adds minimal value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is appropriately concise for a simple read endpoint, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema, complete parameter descriptions, and annotations indicating read-only, the description's brevity is acceptable. However, it lacks any high-level context about pagination or the need to provide a page identifier, which the schema covers indirectly. It is adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage, with each parameter described in detail (e.g., slug/page_id mutually exclusive, cursor for pagination, fetch_all behavior). The description itself adds no parameter explanation, but the schema fully compensates, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('comments for a Yandex Wiki page'). It distinguishes itself from siblings like page_add_comment and page_get by specifying exactly what is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It neither mentions exclusions nor describes scenarios where this tool is preferred over siblings like page_get or page_get_resources. The name implies usage, but explicit context is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint: true, and the description merely repeats this by saying 'This changes structured data and is destructive'. It adds no new behavioral context beyond the annotation, such as whether the deletion is irreversible, whether it cascades to rows, or what happens to dependent data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences. The first sentence states the core action, and the second reinforces the destructive nature. No irrelevant information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive delete with an output schema, the description is minimally adequate. However, it omits context about the consequences of deletion (e.g., whether all rows are deleted, if there is any recovery path) and does not mention any permissions or prerequisites, which would be valuable for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents grid_id with a description ('Wiki dynamic table ID'), and schema coverage is 100%. The tool description adds no additional meaning to the parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete' and the resource 'Yandex Wiki dynamic table', which is specific and immediately distinguishes it from sibling tools like page_delete or grid_update. The name grid_delete aligns perfectly with the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as grid_delete_rows (deleting specific rows) or page_delete (deleting pages). The usage is implied by the name, but the description does not clarify the scope (entire grid vs. part) or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide (readOnlyHint=true). It does not mention pagination behavior, permission requirements, or that it returns metadata rather than file contents. With annotations already covering the read-only safety profile, the description adds no additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the verb and resource, making it immediately clear what the tool does. The brevity is appropriate for a simple read-only operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the detailed schema and presence of an output schema, the description is adequate but minimal. It does not mention pagination or the option to use either page_id or slug, though these are covered in the schema. The description could be slightly more complete by noting the list-return nature, but overall it suffices for a straightforward read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter coverage with detailed descriptions, so the baseline is 3. The description itself mentions no parameters, adding no extra semantic meaning beyond what the schema already documents. This meets the minimum viable level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('attachments for a Yandex Wiki page'). It distinguishes from sibling tools such as page_get and page_get_resources by specifically targeting attachments, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like page_upload_attachment or page_get_resources. It simply restates the tool's function, leaving usage decisions entirely to the reader. No exclusions or alternative pointers are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'Get' is consistent with that (no contradiction). The description adds the scope of the operation ('including attachments and grids') but offers no additional behavioral context such as pagination behavior, permission requirements, or return format. Since the schema covers pagination details, the description adds only minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately conveys the tool's purpose without filler. It is front-loaded with the action and resource, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich (all params described, output schema present), but the description itself is minimal and lacks usage context. It does not clarify how this tool relates to sibling resource-specific tools, nor does it mention that it aggregates multiple resource types. An agent would need to infer its role from the name and schema, limiting contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptive text for all 9 parameters (e.g., 'Opaque pagination cursor', 'Optional resource types filter'). The description itself doesn't mention any parameters, so the schema carries the full semantic burden. With complete schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('resources linked to a Yandex Wiki page') and mentions the resource types (attachments and grids). However, it does not distinguish this tool from sibling tools like page_get_attachments or page_get_grids, so an agent might not know which to select.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the alternative resource-specific tools (page_get_attachments, page_get_grids). It doesn't mention that this tool can fetch multiple resource types in one call or any exclusion criteria, leaving the agent without a basis for choosing it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds no further behavioral context, such as side effects, limitations, or pagination behavior, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundancy. It is appropriately concise for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though short, the description is sufficient given that the schema fully documents all parameters and an output schema exists. It could mention the optional filtering/column selection capabilities, but those are already covered by the schema, so the description remains contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 7 parameters having clear descriptions in the input schema. The tool description itself adds no parameter details beyond mentioning grid_id, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('Yandex Wiki dynamic table'), and specifies the key identifier (grid ID). It distinguishes the tool from siblings like grid_create, grid_update, or page_get_grids, which are clearly different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as page_get_grids for listing grids or grid_update for modifying one. The intended use is only implied by the verb 'Get' and the resource name, with no explicit exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds the scope (page_id or slug) but does not disclose behavior like default fields returned, pagination, or error handling. It is consistent with annotations, adding minimal context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the essential purpose without unnecessary words. It is front-loaded with the action and resource, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the rich schema with 100% parameter coverage, and the presence of an output schema, the description is mostly adequate. However, it lacks any usage guidance or context about when to prefer this over sibling getters, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a detailed description. The tool description repeats the 'page_id or slug' relationship but adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a Yandex Wiki page by page_id or slug.' It specifies the verb (get), the resource (Yandex Wiki page), and the scope (by page_id or slug), which distinguishes it from sibling tools like page_get_descendants or page_get_comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as page_search or page_get_descendants. The description only states what it does, not the conditions or contexts for choosing it over other page-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint=false and destructiveHint=false but no readOnlyHint, so the description's added statement 'This changes structured data' provides a useful mutation warning. However, it does not elaborate on permissions, whether the operation is reversible, or how it affects the host page, leaving only partial behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences, front-loaded with the action and resource. The second sentence adds a behavioral warning without redundancy, making every word useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the parameter schema is fully described, the description does not need to restate those details. However, for a creation tool, it is thin on context such as page requirements ('on a page' is vague), how page_id/slug selection works, or what the resulting grid looks like. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (slug, title, page_id) already have descriptive text in the input schema, giving 100% schema coverage. The description adds no parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create') and a specific resource ('a Yandex Wiki dynamic table resource on a page'), which clearly distinguishes it from sibling tools like grid_update, grid_delete, and grid_get. The title reinforces the same clear intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'Create a Yandex Wiki dynamic table resource' implies the tool is for creating a new grid, but it does not explicitly say when to prefer this over alternatives such as grid_add_rows or grid_update. It also does not mention prerequisites like the need for an existing page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation is asynchronous and returns operation metadata, which is valuable beyond the annotations (destructiveHint=false, openWorldHint=false). This tells the agent that immediate results are not returned. However, it does not detail post-completion behavior or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no redundant information. Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the operation is relatively simple, the description covers the essential aspects: what is copied, where, and the async nature. It does not mention edge cases or prerequisites beyond 'existing target page', but the schema and output schema fill most gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-specific details beyond what the schema already provides, but the schema is well-documented with clear explanations for slug, page_id, grid_id, and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool copies a Yandex Wiki dynamic table to an existing target page, using the specific verb 'copy' and naming the resource. It does not explicitly name sibling tools, but the action is distinct from create, update, and delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: copy a dynamic table to an existing page. It does not explicitly state when to prefer this over alternatives, nor does it mention prerequisites such as needing a target page ID or slug. The guidance is minimal but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include idempotentHint=true, but the description adds that the operation 'changes structured data,' which clarifies it is a mutation. It also discloses the revision requirement for safe updates. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. However, the sentence 'This changes structured data' is largely redundant with the verb 'Update' and does not add meaningful new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the prerequisite of fetching the revision but fails to state what aspects of the grid are updated (title, default_sort). Given sibling tools like grid_update_cells exist, this omission could lead to incorrect tool selection. Output schema exists, so return values are not required, but the scope of the update is ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 repeats the revision guidance already present in the schema ('Fetch the grid first and pass its latest revision') and adds no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Update a Yandex Wiki dynamic table' with a clear verb and resource, but does not differentiate from sibling tools like grid_update_cells or grid_add_rows. The input schema clarifies the update targets (title, default_sort), but the description alone is broad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context by instructing 'Fetch the grid first and pass the latest revision,' indicating an optimistic-locking prerequisite. Does not explicitly mention alternatives or when-not-to-use, but the fetch instruction is valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the tool is safe and non-mutating, and the description does not contradict this. The description adds minor context by specifying 'dynamic tables' and 'attached to a page', but it does not disclose pagination behavior, return format, or any operational characteristics beyond what the annotations state. With annotations present, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the core action and resource. There is no redundant information or filler, achieving maximum economy while remaining clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the tool has 7 optional parameters with full documentation, the description does not need to explain return values or parameter details. The one-liner is sufficient for an agent to select the tool correctly. However, it could hint that the result is a list or that pagination is involved, but the schema compensates for this, so the description is almost complete for selection purposes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter (slug, cursor, page_id, order_by, fetch_all, page_size, order_direction) carrying its own description. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate. The schema already explains the optionality and pagination behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get dynamic tables attached to a Yandex Wiki page' uses a specific verb ('Get') and resource ('dynamic tables attached to a Yandex Wiki page'), clearly distinguishing it from sibling tools like grid_get (single grid) and page_get (page content). The phrase 'attached to a page' implies a collection operation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving grids associated with a page, but it provides no explicit guidance on when to use it over alternatives (e.g., grid_get) or when not to use it. There is no mention of prerequisites like needing a page_id or slug, although the schema covers that. No exclusions or comparative context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (non-destructive, open-world false). The description adds value by disclosing YFM format specifics, warning that GitHub extensions like '[!NOTE]' and raw HTML are not supported, and pointing to a YFM cheatsheet resource. This is meaningful behavioral context beyond the schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose, the second adds format guidance. No redundant text. Every sentence earns its place, and critical info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and the existence of an output schema, the description covers the main operation and content format. It could be more explicit about the mutual exclusivity of slug and page_id (though the schema mentions it). The reference to a YFM resource is helpful. Overall, it is sufficiently complete for a focused append tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds significant context for the 'content' parameter by explaining the YFM Markdown format and unsupported extensions. Other parameters (slug, page_id, location, anchor) rely on schema descriptions. Overall, the description enriches one parameter, raising the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append content to the top, bottom, or anchor of a Yandex Wiki page') with a specific verb and resource. However, it does not explicitly differentiate this tool from siblings like page_update or page_edit, which would help an agent decide when to use append versus replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (appending to an existing page at specific locations) but provides no direct guidance on when to use this tool versus alternatives (e.g., page_update for full content replacement, page_add_comment for comments). It also does not state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the caveat 'This changes structured data,' which informs the agent that this is a mutating operation—useful context given the annotations do not include readOnlyHint. However, beyond this, it does not disclose additional behavioral traits such as error handling, conflict behavior, or the effect of optimistic locking failures. The schema already covers the revision mechanism, so the description contributes little extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the main purpose in the first sentence and a critical prerequisite plus a caution in the second. Every sentence adds value, there is no redundancy, and the structure is front-loaded with the verb and resource. This is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, an output schema, and annotations, the description provides the essential context: what the tool does, the necessity of fetching the grid first, and a warning that it changes data. The schema covers parameter detail, so the description does not need to enumerate every field. It is complete enough for a competent agent to invoke the tool correctly, though it could mention error/rejection conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all parameters, including details about rows, grid_id, position, revision, and after_row_id. The description does not add meaning beyond the schema—it merely restates the requirement to fetch the latest revision. Therefore, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add rows to a Yandex Wiki dynamic table.' This uses a specific verb ('Add') and resource ('rows', 'Yandex Wiki dynamic table'), and it is clearly distinct from sibling tools like grid_delete_rows or grid_update_cells. The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Fetch the grid first and pass the latest revision.' This tells the agent the necessary pre-step and the locking requirement. However, it does not mention when to avoid this tool or how it compares to alternatives beyond the inherent nature of adding rows, so it misses explicit exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true but no readOnly/destructive hints. The description adds 'This changes structured data,' signaling mutation, which is useful. It does not, however, describe the effect on existing values (e.g., full replacement) or error behavior. This is acceptable given annotations cover idempotency, but still leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, ~23 words. It front-loads the action and resource, then immediately states the critical constraint. No filler or redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation that takes an array of cell patches, the description covers the essential purpose and constraint. An output schema exists, so return value explanation is handled. The only minor gap is not mentioning that cells is an array or that multiple patches are allowed, but the schema already defines this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents grid_id and cells. The description reiterates the 'exactly one of column_id or column_slug' constraint, which is also present in the schema. It adds no new meaning beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update cells in a Yandex Wiki dynamic table,' clearly stating the verb and resource. It distinguishes from sibling tools like grid_update (grid-level) and grid_add_rows (row-level) by specifying 'cells.' The phrase 'This changes structured data' reinforces the mutation scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use it (updating cells) and the required argument structure (row_id, value, exactly one of column_id/column_slug). However, it does not explicitly state exclusions or alternatives, such as using grid_add_rows for inserting rows or grid_update for changing grid settings, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint:false and openWorldHint:false, but no readOnlyHint. The description adds the requirement of a recovery token, which is useful, but it does not disclose post-recovery behavior, potential side effects, or any restrictions. This is similar to a baseline where the description adds minimal context beyond what the title and schema already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main verb and resource. It contains no filler or redundant wording, conveying the core functionality efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, presence of an output schema, and clear prerequisites from the schema), the description is complete enough. It does not need to explain return values because the output schema covers that, and the token origin is already in the schema. Minor gaps like error handling are not essential for this simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the sole parameter with 100% coverage, including the fact that the token is returned by page_delete. The tool description does not add any additional semantic information about the parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Recover' with the resource 'a deleted Yandex Wiki page' and the mechanism 'using a recovery token.' This clearly distinguishes it from sibling tools like page_delete, page_create, or page_update. No ambiguity exists about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user has a recovery token obtained from page_delete, which gives clear context. However, it does not explicitly state exclusions or alternatives, so it falls short of a full 5. The phrase 'recovery token' itself signals the prerequisite without further elaboration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds that the tool attaches the file to a page, but does not disclose nuances like whether append_markup modifies page content or how duplicate filenames are handled. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the tool's purpose. Every word serves a function, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full schema coverage, output schema presence, and clear annotations, the description is nearly sufficient. A slightly richer note about side effects (e.g., append_markup triggering page edits) or when to prefer this over other upload mechanisms would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all parameters, including descriptions for slug, page_id, file_path, append_markup, and append_location. The description itself adds no parameter-level detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload a local file'), the target system ('Yandex Wiki'), and the purpose ('attach it to a page'). It distinguishes this from sibling tools like page_get_attachments (which lists attachments) and page_append_content (which appends content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate use case: when a user needs to upload a local file and attach it to a Wiki page. It does not explicitly name alternatives or provide exclusions, but the context is clear enough to guide tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, so the description doesn't need to repeat that. It adds value by disclosing the return value ('updated comment count'), which is a behavioral trait beyond the annotation. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the action and outcome, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a destructive tool with 3 params (1 required), existing output schema, and sibling tools, the description adequately covers the action, return value, and source of required input. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline is 3. The description adds minimal extra meaning: it mentions that comment IDs come from page_get_comments, which is useful context but not a semantic definition beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a comment') and the specific resource ('from a Yandex Wiki page'), and distinguishes it from siblings like page_add_comment and page_get_comments by specifying the verb and return value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('Comment ids come from page_get_comments') but does not explicitly state when to use this tool vs alternatives, nor does it give conditions or warnings about irreversibility beyond what annotations provide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool 'changes structured data,' which is a key behavioral trait not captured by annotations. It also hints at optimistic locking by requiring the latest revision. This adds meaningful context beyond the annotations, though not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the main action stated first and no redundant filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a well-covered schema, annotations, and the description addresses the main concurrency concern (passing the latest revision). While it doesn't describe return values or error cases, the presence of an output schema reduces that burden. It is complete enough for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are already described. The description adds context about the revision parameter (fetch the grid first), which reinforces its purpose, but does not deeply enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add columns to a Yandex Wiki dynamic table.' This uses a specific verb and resource, and distinguishes it from sibling tools like grid_delete_columns or grid_move_column.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow context: 'Fetch the grid first and pass the latest revision.' This tells the agent what to do before calling, but does not explicitly name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true. The description adds valuable context about the need to fetch the latest revision for optimistic locking, and reinforces the destructive nature with 'This changes structured data.' This goes beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, with the main purpose front-loaded. The warning about changing data is brief and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and full parameter descriptions, the description covers the essential workflow (fetch first) and safety profile. It lacks explicit mention of irreversibility or failure on stale revision, but is reasonably complete for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter (grid_id, revision, column_slugs) fully described. The description reiterates the revision requirement but does not add semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete columns from a Yandex Wiki dynamic table,' specifying the exact verb and resource. This distinguishes it from sibling tools like grid_add_columns or grid_delete_rows by focusing on columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a concrete prerequisite: 'Fetch the grid first and pass the latest revision.' This tells the agent the proper workflow before invoking the tool. Does not explicitly name alternatives, but the instruction is actionable and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true, so the baseline is lower, but the description adds valuable behavioral context: the need to fetch the grid first and pass the latest revision, indicating optimistic locking behavior. The statement 'This changes structured data' reinforces the destructive nature, but the revision requirement is the key extra transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy: the first sentence states the function, and the second provides a critical prerequisite and consequence. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete tool with annotations and an output schema, the description is nearly complete. It covers the operation, the prerequisite of fetching the grid, and the revision requirement. It could explicitly mention what happens on stale revision, but the schema already explains optimistic locking, and the description is sufficient for an agent with access to structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 does not add new parameter semantics beyond the schema; it simply restates the revision requirement already described in the schema. The workflow hint (fetch first) is useful but does not provide additional syntax or format details for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete rows from a Yandex Wiki dynamic table.' This is a specific verb+resource pair that distinguishes it from sibling tools like grid_add_rows or grid_delete. The added context about fetching the grid and passing the latest revision further clarifies the tool's exact purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context by instructing to 'Fetch the grid first and pass the latest revision,' which is a clear prerequisite for correct use. However, it does not mention alternatives or when not to use this tool, such as distinguishing it from grid_delete (which may delete the entire grid). This is a clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds valuable context by stating 'This changes structured data' and requiring the latest revision for optimistic locking. This goes beyond what annotations provide, alerting the agent to potential side effects and the need for a fresh read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the primary action. Every sentence serves a purpose: what it does, a critical prerequisite, and a behavioral warning. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters, an output schema, and annotations, the description provides the key operational detail (fetch grid first, pass revision) and flags that it changes structured data. It is sufficiently complete for an agent to use the tool correctly without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions, so the baseline is 3. The description reinforces the revision parameter's purpose ('pass the latest revision') but does not add significant new semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move a column inside a Yandex Wiki dynamic table,' which is a specific verb+resource combination. It distinguishes from sibling tools like grid_move_row (move row) and grid_delete_columns (delete columns) by explicitly naming the column as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Fetch the grid first and pass the latest revision' provides a clear prerequisite and usage pattern. It does not explicitly mention alternatives or exclusions, but the context of moving a column and the need for a fresh revision is clear enough for an agent to know when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses that the operation changes structured data and requires the latest revision for optimistic locking. This adds practical behavioral context without contradicting the annotations. It could further explain consequences of stale revisions, but the current level is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loading the purpose and following with a key usage note. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full input schema, existing output schema, and suitable annotations, the description covers the essential usage context. It could mention the mutual exclusivity of position and after_row_id, but that is already in the schema, so the current level is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 reinforces the revision parameter's purpose but does not add new semantic details beyond the schema's already thorough parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'move' with the resource 'row inside a Yandex Wiki dynamic table', clearly distinguishing it from siblings like grid_move_column. It immediately communicates the tool's core function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context by instructing the user to 'Fetch the grid first and pass the latest revision', which is a critical prerequisite. It also notes that the operation changes structured data, implying caution. However, it does not explicitly mention alternatives or when not to use the tool, so it misses the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by detailing the return fields and explaining the meaning of 'home_cluster' (personal-section slug). This contextual elaboration goes beyond the structured annotations, even though it does not cover all possible return value attributes (output schema handles that).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (with a parenthetical elaboration) that promptly states the purpose and key outputs. Every word earns its place, and there is no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema present, the description sufficiently covers the tool's behavior. It explains the most salient return field (home_cluster) and implies the others. The fact that it does not list every field in detail is acceptable given the output schema's existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter documentation burden. Baseline is 4. The description adds meaning to the return values, particularly 'home_cluster', which is valuable beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the calling Yandex Wiki user and enumerates specific fields (username, home_cluster, identity/org ids). It distinguishes itself from sibling tools, which are all page/grid operations, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. However, since no sibling tools serve a similar user-identification purpose, the usage context is implied: use this to get current user info. The absence of exclusions or alternatives makes it minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=false and openWorldHint=false, which the description complements by mentioning non-destructive creation. The description adds value by disclosing the behavioral nuance of content rendering (Markdown limitations and YFM requirements), which goes beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and immediately provides actionable detail about content formatting. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only 3 required parameters, a clear input schema, an output schema (not shown but mentioned in signals), and good annotations, the description is complete. It addresses the key nuance (content rendering) that could trip up an AI agent, and the reference to a resource for YFM equivalents is a helpful touch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented in the schema. The description adds context about the 'content' parameter (Markdown/YFM format) but does not elaborate on 'slug' or 'title' beyond the schema. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a Yandex Wiki page') and the resource ('Wiki page'). It distinguishes from siblings like page_update or page_edit by specifying creation. The mention of Markdown (YFM) adds specificity about the content format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to create a new wiki page) and provides a crucial detail about content formatting (YFM vs plain Markdown). However, it does not explicitly state when not to use it or contrast with similar tools like page_clone or page_update, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description is consistent. It adds the behavioral detail that a recovery token is returned, which goes beyond the annotation. However, it doesn't elaborate on consequences like deleted comments or descendants, so it adds some but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and informative. It highlights the core action and the notable return value without filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With destructive annotation and an output schema present, the description covers the main purpose and key behavior. The recovery token is mentioned. For a simple deletion tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both slug and page_id have descriptions explaining the either/or requirement. The tool description adds no additional parameter detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('Yandex Wiki page'), and adds a distinctive outcome ('return a recovery token'). This clearly distinguishes it from sibling tools like page_recover or grid_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is obvious: when you want to delete a wiki page. It does not explicitly mention alternatives like page_recover for restoring, but the recovery token hints at reversibility. The context is clear, though not without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, so the description goes beyond by warning that file macros referencing the attachment will become broken, despite page content being untouched. This adds valuable side-effect context not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Every sentence adds value: first states the primary action and source of file IDs, second clarifies what happens to content and macros. Front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that annotations declare destructiveHint=true, the description covers the behavioral side-effect (broken macros), and the output schema likely explains return values. The tool is simple with few parameters, and the description is complete enough for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description doesn't need to detail parameters. It mentions file_id indirectly by referencing page_get_attachments, which adds some context, but doesn't explain slug vs page_id ambiguity; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('attachment from a Yandex Wiki page'), clearly distinguishing it from siblings like page_get_attachments (listing) or page_upload_attachment (adding). It also notes the source of file IDs, adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent to use file IDs from page_get_attachments, providing a prerequisite. It doesn't explicitly say when not to use this tool or name alternatives for similar actions, but the context is clear enough for a destructive attachment operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare idempotentHint=true, which implies the tool is safe to retry. The description adds behavioral details beyond annotations: it explains that content replacement is full-page, describes Markdown rendering limitations (YFM vs GitHub-specific extensions), and provides a reference to a YFM cheatsheet resource. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and highly efficient. The first sentence front-loads the core purpose and resource, while the second adds critical behavioral nuance (full-page replacement, Markdown compatibility). Every word earns its place—no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 optional parameters and an output schema (which presumably documents return values), the description covers the essential update behaviors and Markdown caveats. It could be more complete by noting that parameters like allow_merge or is_silent are optional and have default behaviors, but the schema already documents those. The pointer to the YFM cheatsheet resource fills a gap for users unfamiliar with Yandex Markdown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds minimal value beyond the schema for parameters—it doesn't provide examples, format details, or behavioral notes for parameters like allow_merge or is_silent. It does imply that redirect_to_page_id and clear_redirect relate to redirect behavior, but this is already clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update,' the resource 'an existing Yandex Wiki page,' and specifies the modifiable fields: title, content, or redirect. It distinguishes itself from siblings like 'page_create' (which creates a new page) and 'page_edit' (which might imply a different editing flow), leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context such as 'Content replacement is full-page when content is provided,' which guides when to use this tool versus incremental tools like 'page_append_content.' However, it lacks explicit 'when-not-to-use' guidance or alternatives, like mentioning that for adding comments or attachments, other sibling tools (page_add_comment, page_upload_attachment) should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only 'openWorldHint: false' in annotations, the description carries the full behavioral burden and handles it well. It discloses atomic writes, refusal to overwrite unless overwrite is true, unbounded byte streaming, and the fact that content never enters the conversation. These are meaningful behavioral details beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description packs a lot of decision-critical information into two tight sentences. It front-loads the core purpose, then adds the most important behavioral caveats without redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, full schema coverage, and an output schema, the description is complete enough. It names the source of file IDs, gives the counterpart alternative, explains overwrite semantics, and covers the side-effecting download behavior. Nothing an agent needs to choose or invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters adequately. The description repeats that file IDs come from page_get_attachments, which is useful but already present in the file_id schema description. It adds no significant parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it downloads a Yandex Wiki page attachment to a local file. It also explicitly distinguishes itself from the sibling page_read_attachment as the counterpart for obtaining the artifact itself, so an agent can identify the right tool without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: it is for getting the raw artifact bytes, such as a PDF, archive, or large export, and it explicitly names page_read_attachment as the counterpart. It does not spell out hard 'use this instead of X' rules, but the alternative is clearly identified and the artifact-focused purpose is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details content handling (images as native blocks, text as text, else base64) and refusal conditions. This adds substantial transparency about behavior, without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but somewhat verbose, with multiple clauses and parentheticals. It is well-structured and front-loaded with the core purpose, but could be trimmed slightly without losing essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately explains what the tool returns (content into the conversation) and covers failure modes (size limits). It does not mention error handling for missing files, but that is not strictly required and the description is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for all three parameters (file_id, page_id, slug) with 100% coverage. The tool description does not add extra meaning beyond what the schema states, so it does not improve parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'Yandex Wiki page attachment's content', and explicitly differentiates from sibling tools like page_download_attachment by saying to use that for saving locally. It also clarifies that nothing is saved, aligning with the read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use this tool (for images and text within size limits) and when not to (refuses non-image over 128 KiB, images over 2 MiB). It also points to alternatives (page_download_attachment for saving, page_get_attachments for download URL), giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses that only title and content are copied, while child pages, comments, attachments, and edit history remain with the original, and that the copy gets a new page id. This adds significant context beyond the annotations (destructiveHint false) about side effects and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet information-dense, with four sentences covering purpose, copied fields, failure mode, and the move workaround. It is front-loaded with the primary action and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the extensive behavioral details, the description is fully complete. It covers what is copied, what is not, failure conditions, and how to handle relocation, making it self-sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully describes all parameters. The description does not add new parameter-specific details beyond the schema; for example, the schema already notes 'Must not be occupied by an existing page' for target. Hence baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Copy a Yandex Wiki page to a new slug' and specifies the return value ('return the copy's id and slug'). It distinguishes this from sibling tools like page_create and page_update by focusing on cloning existing content and noting its limitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool for relocating pages, stating 'The Wiki API has no true move/rename; to relocate a page, clone it and delete the original.' It also mentions the failure condition on occupied targets, which helps in planning usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses multiple critical behaviors beyond the minimal annotations (only openWorldHint: false): read-modify-write non-atomicity, allow_merge for concurrent edits, exact matching requirements (including replace_all semantics), failure conditions for missing/ambiguous matches, and YFM content limitations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then incrementally adds necessary details (exact matching, atomicity warning, retry danger, YFM note). Every sentence serves a distinct purpose, and there is no redundancy. It is appropriately sized for a complex mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, sequential replacements, non-atomic behavior), the description covers all essential aspects: how it works, failure modes, concurrency handling, content format, and a pointer to a YFM cheatsheet resource. The presence of an output schema (from context signals) means return values need not be explained. No gaps remain for an agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters, setting a baseline of 3. The description adds significant value beyond the schema: it explains that replacements are applied sequentially, that each old_text must match exactly once unless replace_all is set, and that failures abort the entire call. It also clarifies the merge parameter's role in concurrent edits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Edit a Yandex Wiki page by exact-text replacements, without resending the whole page', which clearly identifies the verb (edit), resource (Wiki page), and method (exact-text replacements). This distinguishes it from sibling tools like page_update (full page rewrite) and page_append_content (appending), as it specifies the targeted, in-place replacement approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for small, precise edits (vs. full page resend) and warns against blind retries. However, it does not explicitly list when not to use it or compare directly to siblings like page_update or page_append_content. The context is clear but lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond the readOnlyHint annotation: it explains the flat list format, how slugs encode hierarchy for tree reconstruction, pagination behavior (truncated, next_cursor), and the cost/impact of whole-wiki walks. This transparency enables accurate expectations without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence adds essential context (output format, pagination, performance tradeoffs, from_root usage). It is information-dense, yet a slight trimming of the final sentence about 'thousands of pages' might improve focus without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, pagination, multiple modes), the description covers all key aspects: output structure, hierarchy reconstruction, from_root behavior, pagination continuation, and performance guidance. With an output schema present, the description need not repeat return type details, and it adequately complements the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description enriches parameter meaning substantially: it explains slug hierarchy encoding, the semantics of from_root (mutually exclusive with page_id/slug), and fetch_all's automatic pagination with a ~500-item cap. These clarifications go well beyond the schema's per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the subtree of Yandex Wiki pages under a parent page.' It specifies the resource (Yandex Wiki pages) and distinguishes itself from siblings like page_get and page_search by emphasizing hierarchical descendants and the from_root option for whole-wiki enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Prefer a section slug when you have one' and 'narrow down by calling this tool on a subsection's slug' directly addresses when to use this vs alternatives. It also instructs on using from_root when no starting slug is known, and warns about fetch_all's ~500-item cap with truncated=true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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