Kettu Marketplace Intelligence

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.2
Disambiguation4/5
Most tools are clearly separated by marketplace prefix and action type (search, card, selfcheck), so an agent can generally pick the right one. A few pairs could still cause hesitation, such as wb_card vs wb_root_info (both return card-like data) and detmir_category vs detmir_categories, though the descriptions clarify the distinction.
Naming Consistency4/5
The dominant pattern is marketplace_prefix + action, and it is applied predictably to search/card/selfcheck across nearly every marketplace. There are minor inconsistencies like detmir_category vs detmir_categories for tree-browsing vs product-listing, wb_root_info and wb_category_products using noun phrases, and cross-cutting tools (compare_prices, compare_sources) not following the prefix convention.
Tool Count2/5
At 42 tools, the namespace is large and exceeds the 25+ threshold for a heavy tool surface. The count is systematic because each marketplace gets multiple tools, but it still forces agents to scan a long, repetitive list, especially with nine near-identical selfcheck tools.
Completeness4/5
For a read-only marketplace intelligence server, the core workflow is well covered: every marketplace has search and card retrieval, WB has reviews/questions/categories/seller, Avito has seller profiles, and compare_prices ties it together. Some depth is uneven — Ozon lacks categories and seller lookup, Yandex lacks seller lookup, and several marketplaces lack reviews — but these are workable gaps rather than dead ends.
Average 4.4/5 across 42 of 42 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the additional behavioral detail is valuable: rendering in the operator's Chrome, TransportDownError on CDP/nav failures, ParserDriftError on zero SKUs, and the price_rub semantics. There is no contradiction with 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, then short Return Format and Error Format sections. Every sentence carries useful information, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter search tool with an output schema and strong annotations, the description covers the response shape and the key failure modes. It is sufficient for invocation, though the missing usage guidance is a gap captured in the usage dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter, query, including length constraints and an example. The description adds no additional parameter-level semantics, so the baseline of 3 for high schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search Lamoda', a specific verb and resource, and the title/name reinforce the same scope. It does not explicitly differentiate from sibling search tools like wb_search or ozon_search, nor from lamoda_card, but the intended operation is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use lamoda_search versus lamoda_card, lamoda_selfcheck, or the other marketplace search tools. The phrase 'discovery is blocked tier 1' hints at a constraint but does not explain when this tool should be selected over alternatives.
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, openWorldHint, idempotentHint, and destructiveHint false. The description adds meaningful behavioral context beyond these: Tier-1 attempt with curl_cffi, fallback to Chrome CDP on Cloudflare 403, and the operator prerequisite to start Chrome via the provided scripts. This helps the agent anticipate operational dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The primary purpose is front-loaded, and the fallback/setup details are compactly presented. Every clause adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values need no explanation. The description covers purpose, fetch mechanism, fallback behavior, and a critical prerequisite (Chrome CDP setup). Minor details like what happens when both tiers fail are not specified, but overall the agent has enough context to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema description covers 100% of the single parameter, including accepted formats (SKU, URL, /product/<digits>/ path) and SSRF rejection. The tool description itself adds no parameter-level information, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear action and resource: 'Fetch Ozon product card data'. This distinguishes it from sibling tools like ozon_reviews and ozon_search, though it doesn't explicitly name them. The phrase 'via composer-api.bx' adds technical specificity but doesn't obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives such as ozon_reviews or ozon_search. The fallback and setup details describe internal operation, not tool selection context. Usage context is only implicitly conveyed by the resource name.
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 signal readOnly, idempotent, and non-destructive; the description adds concrete failure modes (BadRequestError, TransportDownError, ParserDriftError) and the exact response shape, which helps an agent anticipate what happens on bad input or site changes. This exceeds the annotation-only picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a one-line purpose followed by terse, structured Return/Error sections. It is slightly redundant with the existing output schema, but every line carries behavioral or format information, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool, the description covers the main action, return shape, and principal errors, which is sufficient given the annotations and output schema. It omits explicit usage guidance, but that is a minor gap at this simplicity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes product_url fully with format and example, giving 100% coverage. The description does not elaborate on the parameter beyond referencing product_id in the return format, so it adds no new parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' with the resource 'DNS-Shop product card', and the word 'one' clarifies it targets a single product rather than a search or listing. This distinguishes it from siblings like dns_search and dns_selfcheck, and the domain prefix separates it from other marketplaces' card tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over alternatives; it does not mention dns_search for finding products first or dns_selfcheck for health checks. The only implied context is that it takes a product URL, which appears in the schema rather than the description.
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 cover safety, but the description adds valuable behavior: it is rendered in the operator's Chrome, price_rub is None never 0, and specific error conditions (TransportDownError, ParserDriftError) are disclosed. This gives the agent realistic expectations beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized with clear Return Format and Error Format sections. Every sentence contributes useful information, and there is no filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool, the description covers the return shape, key data nuances, and failure modes. It is slightly incomplete only in that it omits any usage guidance relative to siblings, but the core calling context is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents 'query' with an example. The description adds no further parameter-level detail, so the baseline of 3 applies without needing the description to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states 'Search DNS-Shop', giving a specific verb and resource. The title and tool name reinforce this, and the resource is clearly distinct from sibling tools like dns_card or other marketplace searches, even without explicit contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use dns_search versus alternatives such as dns_card or compare_prices. There is no mention of what types of queries are appropriate or when to prefer another tool, leaving the agent to infer usage solely from the name.
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 cover readOnly, idempotent, openWorld, and non-destructive behavior, so the bar is lower. The description adds valuable context by documenting the exact return fields and three meaningful error modes: missing product id, transport/CDP/Qrator failures, and parser drift. This goes beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line purpose, a return format section, and an error format section. Every section earns its place, and the most important usage information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only fetch tool, the description is complete: it states what is returned, what can go wrong, and what input is expected. The presence of output schema details in the description also removes ambiguity about the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because product_url is fully documented with format and example. The tool description adds no new parameter-level meaning, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pairing: 'Fetch one Citilink product card.' The word 'one' and the resource type distinguish it clearly from sibling tools like citilink_search and the various self-check tools. An agent can immediately tell what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by 'Fetch one Citilink product card' and the requirement of a product_url, but the description does not explicitly state when to prefer this tool over citilink_search or other card tools. There is no direct alternative guidance or exclusion criteria.
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 cover readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond that: prices are returned in rubles, the selected fields are explicit, and the tool supports at most 100 SKUs. It does not contradict the annotations, and the additional details help set expectations without restating annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences with no filler or redundant restatement of schema/annotation fields. The primary action and return summary are front-loaded, and every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations, complete input schema, and presence of an output schema, the description covers the remaining operational facts needed to call the tool correctly: the API source, returned fields, currency, and batch limit. No critical information is missing for a read-only batch product-card lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter documentation, including the default dest value, region examples, and the 1..100 nmIds constraint. The description reinforces the 100-SKU limit and mentions ruble prices, but it does not add substantial parameter semantics 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch') and resource ('product card data from WB v4 API'), then enumerates the returned fields such as prices, brand, supplier, and ratings. This clearly distinguishes it from sibling tools like wb_search or wb_reviews by focusing on batch card lookups by nmIds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used when you need product card data for specific up-to-100 SKUs, and the 100-SKU cap signals batching. However, it does not explicitly state when to prefer this tool over wb_search, wb_reviews, or other WB siblings, nor does it mention prerequisites like how to obtain nmIds.
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 goes well beyond the annotations by revealing the internal endpoint, the exact response envelope, and the failure modes including firewall blocks, captcha/proxy guidance, and parser drift. This gives the agent useful operational behavior not derivable from annotations or the input 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, followed by clearly labeled Return Format and Error Format sections. Every section earns its place, and the most important operational details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, full input schema, and presence of an output schema, the description covers the essential extra context: return field semantics, error conditions, and the internal-API caveat. The only notable gap is explicit alternative-tool guidance, but that is a usage-guideline concern, not a completeness failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents query, page, category_id, and location_id. The description adds no additional parameter-level meaning, but because the schema already describes defaults, ranges, and nullability, a 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search Avito listings via the internal js/items API.' This clearly differentiates it from sibling card, seller, and selfcheck tools, and the name/title reinforce the same 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the description: it is the tool for searching Avito listings, as opposed to avito_card or avito_seller. However, it never explicitly states when to prefer this tool over alternatives, when not to use it, or what would be better for retrieving a single listing or seller details.
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 cover read-only, idempotent, and non-destructive behavior. The description adds concrete error behavior — empty input, 404, transport blocks, and parser drift — plus a high-level response envelope. This is useful operational context beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the core purpose front-loaded, followed by context and then return/error formats. Every section serves a clear role; the classifieds context sentence is slightly explanatory but earns its place by clarifying the tool's value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with full schema coverage, a rich output schema, and safety annotations, the description covers purpose, domain context, response shape, and error modes. Nothing essential for correct selection or invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, and the schema already describes seller_id_or_url as 'Seller id or profile URL from a card/search hit'. The description does not add parameter-specific semantics beyond framing the output as seller reputation data, so the baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Fetch an Avito seller profile', clearly identifying the action and resource. It then explains that the seller's rating, review count, and active-listing count are the relevant reputation signal for classifieds, which distinguishes this tool from per-item review or card tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when evaluating a seller's reputation in classifieds, since there is no per-item review pool. It does not explicitly name alternative tools or state when not to use it, but the domain context is strong enough to guide selection.
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 read-only, idempotent, and non-destructive. The description adds useful behavioral context: it's a real JSON endpoint with proper pagination and an upstream total, supports price inquiry without scraping, and documents the error format (ToolError with JSON message, error code, and retryability). 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence. The secondary reliability context and error format are in clearly separated short paragraphs. Every sentence 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with an output schema and fully documented parameters, the description covers purpose, reliability, pagination, and error behavior. It could mention how the region parameter affects price/stock behavior, but the schema and output schema already carry most of that burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all four parameters, so the baseline of 3 applies. The description reinforces pagination and total-count behavior but doesn't add field-level meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first line states a specific verb, resource, and output: 'List products in a Detsky Mir category, with the total match count.' This clearly differentiates it from sibling detmir_categories (which lists categories) and detmir_card (which fetches a product card), and the 'unlike text search' line separates it from search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts this tool with text search and frames it as 'the reliable way to enumerate the catalog,' with proper pagination and an upstream total. It doesn't name alternative sibling tools like detmir_categories or detmir_card, but the purpose statement and title make the distinction clear enough.
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 annotations (readOnlyHint, idempotentHint), the description discloses meaningful behavior: the curl_cffi-to-CDP fallback, that zero matching items is a healthy response rather than an error, and the specific error taxonomy (BadRequestError, TransportDownError, ParserDriftError). No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for return format and error format. It front-loads the core purpose before implementation details. The parser-widget detail is somewhat niche for an agent, but it is contextually relevant to explaining parser drift behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with the input schema, annotations, and output schema, the description fully covers what the agent needs: input requirements, output shape on success, zero-result behavior, error behavior, and the fallback execution tier. There are no significant gaps for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (query and page) are already documented in the input schema. The description adds no additional parameter-level semantics, such as query formatting guidance or page-specific behavior, but it does not need to because the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Search Ozon catalog' names a specific verb and resource, and the description further distinguishes this from sibling tools like ozon_card and ozon_reviews by stating it returns sku/title/price/rating per item. The tool's role as the Ozon search entry point is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for searching Ozon's catalog, and it documents the tiered execution path. However, it never explicitly states when to prefer this tool over alternatives such as ozon_card or wb_search, nor does it mention any exclusions or edge cases where another tool should be used.
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 readOnly/openWorld/idempotent annotations, the description discloses meaningful runtime behavior: the tool depends on Chrome/CDP, can hit a login wall requiring authentication in the scraping profile, and can fail with ParserDriftError when the DOM changes. These failure modes are valuable context for an agent deciding whether to invoke and how to react.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise summary followed by clearly separated Return Format and Error Format sections. It avoids fluff, though the Return Format section is somewhat redundant given that an output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search tool, the description is complete: it states the resource, the browser rendering dependency, authentication prerequisite, output item shape, and the two key error modes. Combined with the rich annotations and full schema coverage, an agent has everything needed to invoke and troubleshoot this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: query is documented with examples and length constraints, and page is documented with range and default. The description adds little to parameter semantics beyond the high-level 'search Taobao listings' statement, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search Taobao listings'. It also clarifies the execution context ('rendered in the operator's Chrome'), which distinguishes this from simple API-style searches and from sibling tools like taobao_card or taobao_selfcheck by function and marketplace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the main use case—keyword search over Taobao listings—and gives operational context via the 'rendered in the operator's Chrome' note and the login-wall retry instruction. However, it never explicitly states when to prefer taobao_search over sibling tools like taobao_card, or when not to use it.
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 read-only/idempotent annotations, the description discloses that the search runs in the operator's Chrome via CDP, that price_rub can be None but never 0, and that failures map to TransportDownError or ParserDriftError on zero product tiles. This gives an agent concrete expectations about execution context, edge cases, and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with clear 'Return Format' and 'Error Format' sections, and each sentence adds operational value. It front-loads the core purpose before the technical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, strong annotations, output schema, and the included return/error format notes, the description covers everything an agent needs to invoke the tool and interpret its results. No critical gaps remain for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single query parameter is already fully described in the schema with an example ('ноутбук lenovo'), and schema coverage is 100%. The tool description adds no additional meaning about the query parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the action 'Search' and the resource 'Citilink' directly, and the sibling list shows citilink_card/citilink_selfcheck, so the search-vs-detail distinction is clear. The return format with 'items[]' and 'product tiles' reinforces that this is a product-listing search, not a card lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage by naming the platform and action, but it never explicitly states when to choose it over citilink_card/citilink_selfcheck or other marketplace searches. No alternatives or exclusions are provided; usage must be inferred from the tool name and sibling naming convention.
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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: there is no working text search, nodes carry alias and products_count, and failures raise ToolError with a JSON message describing error code and retryability. This gives the agent practical expectations for discovery and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: purpose first, then usage context, then error format. Every sentence earns its place, and the markdown headers make it scannable. It is appropriately sized for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations, 100% parameter coverage, and the presence of an output schema, the description is complete. It explains the discovery workflow, what result fields to expect conceptually, and the error behavior. Nothing essential is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 semantics for limit, parent, or region beyond what the schema already provides. It reinforces that nodes carry alias and products_count, which helps contextualize results, but does not improve parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Browse the Detsky Mir catalog tree and get the aliases detmir_category needs.' It also explains the tool's distinct role as the discovery step, contrasting with direct product search which does not exist for this source. This clearly separates it from sibling tools like detmir_category and detmir_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: Detsky Mir has no working text search, so the way to find products is to walk the tree and list a category. It also mentions checking products_count before fetching a listing, implying the follow-up step. It could be stronger by explicitly saying 'use detmir_category after selecting a category,' but the context is clear enough.
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 already mark the tool read-only and idempotent, and the description adds meaningful behavior beyond that: it reveals the call is anonymous and tier 1, defines clear failure modes via ToolError variants, and documents that Lamoda has no ratings. There is no contradiction with 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-line purpose is front-loaded, followed by two clearly headed sections for return and error formats. Every section earns its place with diagnostic value, and there is no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description covers purpose, input expectations, output shape, endpoint characteristics, and failure modes. The output schema exists for detailed return fields, and annotations cover safety, so nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter sku_or_url is fully documented in the schema, including the accepted SKU format and a lamoda.ru URL example, so the description does not need to add much. It adds only the indirect hint that an input without an extractable SKU will fail with BadRequestError.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Fetch') and a concrete resource ('one Lamoda product card'), and the singular 'product card' phrasing clearly separates it from lamoda_search and lamoda_selfcheck. The mention of the anonymous GraphQL endpoint and tier 1 also makes the tool's scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the caller needs a SKU or product URL, and the note that Lamoda exposes no ratings suggests one exclusion, but it never explicitly says when to prefer this tool over lamoda_search or lamoda_selfcheck. Usage guidance is left mostly to inference rather than stated.
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 goes well beyond the readOnlyHint/idempotentHint annotations by specifying the exact response envelope (MegamarketCardResponse fields) and detailed error modes including BadRequestError, NotFoundError, TransportDownError, and ParserDriftError. No contradiction with annotations 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and uses clear Return Format / Error Format sections that add useful structure without redundancy. Every sentence contributes relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only card lookup, the description together with the schema and annotations is complete: it states what is returned, how failures surface, and what input is expected. Search and discovery concerns belong to sibling tools, so their absence is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single parameter with 100% coverage ('Goods id or megamarket.ru product URL'), so the description adds no additional parameter-level meaning. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Fetch one Megamarket product card.' The word 'one' clearly distinguishes this from the sibling megamarket_search tool, and the Megamarket qualifier distinguishes it from the many other marketplace card tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than explicit: the tool is for fetching a single known Megamarket product card, so an agent can infer it should be used when it already has an item id or URL. However, it does not explicitly say when not to use it or direct the agent to megamarket_search for discovery.
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 already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description goes beyond them by documenting return-format quirks ('price_rub is None when absent — never 0') and specific failure modes (TransportDownError, ParserDriftError), which is genuinely useful behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, followed by clearly labeled Return Format and Error Format sections. Every line earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter search tool with an output schema and rich annotations, the description is complete enough. It explains the response shape, critical edge cases, and failure modes without unnecessary elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter, query, with a description and an example. The tool description adds no additional parameter-level meaning, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search the Megamarket catalog via the mobile API.' It also gives environmental context ('inside the operator's Chrome') and the tool name clearly distinguishes it from sibling card and selfcheck tools like megamarket_card and megamarket_selfcheck.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the verb 'Search' and the catalog target, but there is no explicit when-to-use guidance, exclusions, or mention of alternative search tools such as yandex_search or wb_search. It meets the minimum viability bar but leaves selection reasoning to the agent.
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 read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond this: the data source (basket CDN), the variant-sharing semantic, the critical warning that reviews are indexed by imt_id rather than nmId, and a specific error format with retryability info. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: main action, return value, key semantic, and error behavior. The structure is front-loaded and the error format section is clearly separated with a heading. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with full schema coverage, an output schema, and safety annotations, the description is complete. It explains the purpose, the critical indexing caveat, and error handling; nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents nm_id. The description does not add extra parameter-level detail beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Fetch') and resource ('full card metadata from basket CDN'), then names the key output ('imt_id (root_id) for review pool'). The statement 'Reviews indexed by imt_id, NOT by nmId' clearly differentiates this from review-indexing tools like wb_reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: all variants share imt_id and reviews are indexed by imt_id, implying an agent should use this tool when it needs the imt_id before querying reviews. It does not explicitly name sibling alternatives or state 'when not to use', but the guidance is strong enough.
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 concrete behavior beyond the safety annotations: the exact endpoint used, that the raw results are just product IDs, that there is no PoW protection, that rate limits are high, and that results are enriched through wb_card. This gives the agent a realistic mental model of the call before invoking it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and followed by high-value endpoint/behavior details. No filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent search tool with a full output schema and complete parameter docs, this description covers the essential missing context: endpoint identity, response shape before enrichment, and rate-limit behavior. Nothing needed for a correct call is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters already carry their own documentation. The description adds no new parameter-level detail beyond reinforcing that the query is a text query, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific action and resource ('Search WB catalog by text query'), so an agent immediately knows what the tool does. The mention of the dedicated search endpoint and the subsequent wb_card enrichment clearly differentiates it from catalog-browsing and card-only sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context (lightweight endpoint, very high rate limit, returns IDs then enriches) that implies when it would be a convenient search tool, but it never explicitly states when to prefer wb_search over nearby alternatives such as wb_category_products or wb_card. Usage guidance is therefore implied rather than spelled out.
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 goes well beyond the annotations by explaining the precise drift criteria: 403 firewall blocks and CDP-down are inconclusive transport states, while only a reached-200 JSON body failing the parse smoke counts as drift. This is exactly the non-obvious behavioral context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loads the core purpose and tri-state result, with important edge-case semantics following. The return-format section is slightly redundant given an output schema exists, but it does not meaningfully bloat the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-input read-only diagnostic with output schema and safety annotations provided, the description covers everything material: what it probes, how to interpret success, drift, and inconclusive results, and a return-format summary. No critical operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the input schema is an empty closed object, so there is no parameter semantics burden. The description does not introduce any parameter-related ambiguity; the baseline for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: a structural drift canary for Avito that runs live probes against search, card, and seller endpoints. It also names the tri-state result, making it clearly distinguishable from data-fetching siblings like avito_search, avito_card, and avito_seller.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The selfcheck/canary framing implies when the tool should be used, and the probe targets are explicit. However, the description never directly says 'use this to verify Avito connector health instead of fetching marketplace data,' nor does it exclude scenarios or name alternatives.
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 already declare readOnly, openWorld, idempotent, and non-destructive behavior, and the description adds meaningful behavioral detail: the blackhole shard means no listable feed, errors are raised rather than empty lists returned, and the response shape matches wb_search and wb_card. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and each paragraph earns its place, especially the blackhole warning. The middle narrative about humidifiers and relevance ranking is slightly expansive, but it effectively conveys why the tool matters without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, the origin of its key parameters, the comparability of its output with related tools, and the critical blackhole failure mode. With a rich output schema and strong annotations present, nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all five parameters with examples and special values, including the blackhole meaning for shard and the WB selector format for query. The description reinforces that shard/query come from wb_categories, but with full schema coverage this adds only marginal parameter-level value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List the products in a catalog category, using the shard and query from wb_categories.' It also clearly distinguishes itself from siblings by explaining it 'closes the loop' that wb_categories opens and that items return in the same shape as wb_search and wb_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly positions this tool as the follow-up to wb_categories and explains when category browsing is preferable to inventing a search phrase. It stops short of explicitly saying 'use wb_search instead for these cases', so it lacks a full when-not-to-use statement.
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 goes well beyond the provided annotations by documenting the return format in detail, including the important edge case that price_rub is None when no price exists and never 0. It also enumerates the full error taxonomy: BadRequestError, NotFoundError, TransportDownError, and ParserDriftError, giving the agent clear expectations about failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized with clear sections for return format and error format. Every sentence carries useful information, and the most important information is front-loaded in the opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with a rich output schema and detailed annotations, the description covers return semantics and error handling thoroughly. Nothing essential is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter description 'Item id, slug path or full avito.ru URL' already capturing the accepted formats. The description reinforces this by mentioning 'by id or URL' and adds no confusion, though it does not need to add much beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fetch one Avito listing by id or URL.' This clearly distinguishes the tool from sibling tools like avito_search and avito_seller, which operate on search results or seller pages rather than a single listing card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you already have a listing id, slug, or URL, but it does not explicitly state when to prefer this over avito_search or avito_seller. Usage context is implied rather than spelled out, so guidance is adequate but not thorough.
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 readOnly/idempotent annotations, the description discloses that the tool performs a live CDP search, has an external transport dependency, and precisely defines the drift vs inconclusive judgment rules. It even explains environment expectations about Chrome challenge state. This is substantial behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is front-loaded with its core purpose, then uses short structured lines for verdict semantics and return format. Every sentence carries diagnostic value; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-input canary tool with an output schema, the description fully explains the operation, the meaning of each verdict class, the transport-vs-drift distinction, and the expected outcome on machines with an unmet Chrome challenge. An agent has enough context to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and schema coverage is complete, so there is nothing for the description to add about inputs. The baseline of 4 applies for a no-parameter tool; the description correctly spends no space on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific operation—'Posts one live search through CDP and checks items parse'—and frames it as a 'Structural drift canary for Megamarket (tri-state)' with a distinct verdict semantics. This distinguishes it from megamarket_search/megamarket_card and the other selfcheck tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case via 'drift canary' and clarifies when the verdict should be read as inconclusive, but it never explicitly says when to call this instead of alternatives such as megamarket_search or another selfcheck. There are no when-not-to-use or alternative-routing statements.
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 already mark it read-only and non-destructive. The description adds meaningful behavior beyond that: price_cny may be None on hidden/variant pricing and is never 0, and it enumerates specific error types including login-wall/CDP failures and parser drift. This gives an agent realistic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: purpose sentence first, then Return Format and Error Format sections. Every sentence carries information, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only card fetch with an output schema, the description covers purpose, return contract, price edge case, and failure modes. An agent has everything needed to call it correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents item_id_or_url as 'Item id or item.taobao.com URL'. The description adds no further 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fetch one Taobao item card.' It clearly distinguishes this from sibling tools like taobao_search and taobao_selfcheck by signaling a single item-card retrieval rather than a search or health check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Fetch one' plus the item_id_or_url parameter makes the direct-lookup use case clear. It does not explicitly name alternatives or state when not to use it, but the context is strong enough that an agent can select it appropriately.
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 already mark the operation as read-only and idempotent, and the description adds meaningful behavioral detail about error handling: it raises a ToolError with a JSON message describing the error code and retryability. It also clarifies what legal-entity data is returned, giving the agent a concrete picture of the call's result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then adds a crisp use-case ('who actually ships this?'), a workflow chaining hint, and a dedicated error-format note. Every sentence contributes information, and the overall length is appropriate for the behavioral detail it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only lookup with an output schema present, the description is complete: it covers when to call, where the parameter comes from, what is returned, and how failures surface. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the supplier_id property already documents the type, positive constraint, and source ('Get it from wb_card's supplier_id field'). The description repeats the chaining hint but adds no new parameter-level meaning, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Look up the registered legal entity behind a WB seller.' It clearly distinguishes the tool from siblings by explaining that it identifies who actually ships the product, using registered name, tax IDs, and legal address, rather than being a card, search, or review tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Chain from wb_card: its supplier_id field feeds straight into this tool.' This tells an agent when in the workflow to invoke it. It does not explicitly list exclusions or alternative tools for the same task, which prevents a perfect score.
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 already declare read-only, idempotent, non-destructive behavior, and the description adds meaningful context beyond that: price_rub vs price_with_plus semantics, the Yandex Plus requirement, the preference for price_rub when quoting to a person, the nuance that rating_count counts stars not written reviews, and the ToolError format with retryability. This substantially enriches behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized: purpose first, then market positioning, pricing semantics, rating-count caveat, and error format. Each section earns its place and the structure is front-loaded with the most important call behavior. It is detailed without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool that already has an output schema, the description covers the essential usage context, pricing nuance, rating-count interpretation, connection to yandex_card, and error behavior. An agent has enough information to invoke it correctly and interpret its results safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds a useful note that query should be free-text Russian and gives examples, but it does not need to compensate for any schema coverage gaps since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Search Yandex Market') and resource, and lists what is returned: prices, ratings, and sellers. It also differentiates this tool by noting Yandex Market is the best single source for current Russian-market pricing and carries goods Wildberries and Ozon do not, separating it clearly from sibling searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when to use it: 'best single source for what does this cost right now across the Russian market,' including goods WB/Ozon do not carry. It also points to yandex_card for written review counts. However, it does not explicitly say when not to use this tool or name alternative search siblings directly.
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 establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds useful behavior beyond annotations: it reports installation-level availability and distinguishes connector installation issues from marketplace refusals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences. The first states the core purpose directly; the second provides actionable guidance with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity: no parameters, output schema present, and safety annotations cover side effects. The description explains what it reports, when to call it, and what distinction it makes. The only minor gap is not explicitly contrasting it with the similarly named sibling 'marketplace_sources.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so there is no parameter semantics for the description to elaborate. Per the baseline for parameterless tools, this is a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete action ('Report') and a specific resource ('which marketplaces this installation can actually query'). It also distinguishes the tool's diagnostic role from the comparison tools by noting it separates a missing connector from a marketplace refusal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to call this tool: 'Call this first when a comparison comes back partial.' It also explains why that matters by naming the two distinct failure causes and noting they need 'completely different fixes.'
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 read-only/idempotent/non-destructive annotations, the description discloses how the probe classifies outcomes: tiered paths, inconclusive failure conditions, and the exact drift condition. This gives an agent important behavioral context it would otherwise have to infer. No contradiction with the annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, separating purpose, conditional behavior, and return summary into a clear structure. The 'Return Format' line is slightly redundant given an output schema exists, but it remains brief and does not bloat the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-input probe with annotations covering safety and an output schema covering the response, the description supplies the non-obvious semantics: what each tier checks, when failures are inconclusive, and what actually constitutes drift. This is sufficient for an agent to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and the schema is empty, so the description has nothing to add for parameter semantics. The zero-parameter baseline applies cleanly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description centers on a specific verb and resource: it 'Probes' Lamoda's GraphQL card path (tier 1) and CDP search path (tier 2) as a structural drift canary. This clearly distinguishes it from sibling tools like lamoda_search and lamoda_card, and from other marketplaces' selfchecks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use as a Lamoda drift/monitoring check is clear from the 'canary' framing and the enumerated probe paths. It provides strong interpretation guidance—such as GraphQL down being inconclusive and only a reached payload failing parse smoke counting as drift—though it does not explicitly name alternatives or state when not to use the tool.
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?
Even with readOnlyHint, idempotentHint, and openWorldHint annotations present, the description adds substantial behavioral detail: exact tri-state semantics, what counts as inconclusive vs drift, handling of Cloudflare 403 / CDP-down / non-200 / non-JSON, and the error contract. It also clarifies that inconclusive and drift_detected are valid normal responses, not errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every section earns its place: purpose, tri-state rules, return format, and error semantics are all behaviorally relevant. The main purpose is front-loaded and the structured headings make the detailed tri-state and error contracts easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter self-check tool with an output schema and read-only/idempotent annotations, the description covers everything an agent needs: what it checks, what each verdict means, how transport failures are classified, and when an error is actually raised. No critical gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is no parameter meaning to add. The description incidentally clarifies that the tool fetches live data and runs internal subchecks, which is useful context beyond the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a structural drift canary for Ozon with a tri-state outcome, naming the specific resources checked (live search, card, reviews, non-default reviews sort). It distinguishes itself from sibling review/search tools by emphasizing the canary's role in detecting vanished widgets before parsers break.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that this tool is a pre-emptive drift check rather than a data-fetching tool, and even notes that the reviews_sort subcheck exercises the path on which ozon_reviews pagination depends. It doesn't explicitly list alternative tools to use instead, but the purpose and positioning against siblings are clear enough.
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 goes well beyond annotations by explaining that it renders a live search page in the operator's Chrome, that CDP failures or login walls are inconclusive, and that only a rendered page yielding zero items counts as drift. It also discloses the tri-state semantics, which is critical for interpreting the tool's output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loads the core purpose and tri-state behavior. It is slightly wordy with the return format block, but every sentence provides useful information and the format is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a zero-parameter health-check tool: it explains what the tool does, how it operates, how to interpret the tri-state result, and what the response contains. The output schema and annotations cover the remaining structured details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema describes an empty object with 100% coverage, so there are no parameter semantics for the description to add. The baseline of 4 applies here because no parameter documentation burden exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a structural drift canary for Taobao, with a specific verb ('checks'), resource ('extractor'), and tri-state outcome. It differentiates itself from sibling search/card tools by focusing on health-check behavior rather than data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is a monitoring/health-check tool, not a search tool, and explains when results should be classified as inconclusive versus drift. It does not explicitly name alternative tools, but the canary purpose and sibling naming pattern make the intended usage unambiguous.
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 goes well beyond the annotations by explaining the tri-state result semantics and the critical distinction between transport-level inconclusive results and true drift. It also discloses that the tool opens a live page in the operator's Chrome and depends on CDP, which is valuable behavioral context not visible in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by essential interpretation rules and return format. Every section earns its place, and the formatting makes the key distinctions easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter health-check tool, the description covers purpose, execution environment, result interpretation, and return format. The presence of an output schema further reduces the need to explain return fields, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is effectively 100%, so there are no parameter semantics to explain. The description reasonably emphasizes what the tool does rather than adding parameter details, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a structural drift canary for Citilink, with the specific action of rendering one live search page and checking whether tiles extract. This makes its function distinct from sibling search/card tools and from other marketplaces' self-checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: use this as a canary for Citilink drift detection, and interpret transport failures like Qrator blocks or CDP-down as inconclusive rather than drift. It does not explicitly name alternatives or exclusions, but the self-check purpose is stated directly.
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 already mark this as read-only and idempotent, and the description adds substantial behavior beyond that: concurrent querying, per-source reporting, partial-result semantics when sources time out, exclusion of Yandex subscription pricing from ranking, and the guarantee that individual source failures do not raise errors. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized with clear sections, a front-loaded headline, and bolded caveats for important output fields. Every paragraph adds distinct information needed for correct interpretation, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers output semantics (cheapest, price_with_subscription_rub, source_outcomes, complete), error format, loose title matching, and the concurrent behavior. The output schema can carry return-value details, so nothing critical is missing for an agent to call and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with 100% coverage, so the description does not need to repeat parameter details. The description focuses instead on output interpretation and ranking semantics, which is appropriate; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Price one product across every configured Russian marketplace at once.' It also differentiates from per-marketplace search siblings by naming the ranking behavior and by framing the exact question it answers: 'where is X cheapest'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly identifies when to use this tool: 'This is the tool for "where is X cheapest"'. It also contrasts with the alternative (running per-marketplace search tools one at a time) and explains that the alternative is slower and lacks ranking.
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 already signal read-only, idempotent, non-destructive behavior, and the description adds valuable context beyond those: region overrides DETMIR_REGION for this call only, store_count varies dramatically by city with concrete examples, and errors are raised as ToolError with retryability info. This goes well beyond the structured 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded purpose statement, a context paragraph, a highlighted 'Region matters most here' section with concrete examples, and a separate error-format section. Every sentence adds useful information, and the formatting makes the most important caveat immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters, an output schema present, and rich annotations, the description covers everything else an agent needs: error behavior, region-override semantics, why store_count is city-dependent, and what makes this source different from general marketplace cards. There is no significant missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description adds meaningful depth: it explains that region is the most impactful parameter, how it interacts with the environment default, and why store_count depends on it. The product_id semantics are already well covered by the schema's URL-pattern hint, so the description's extra region guidance earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fetch price, rating, stock and seller for one Detsky Mir product.' It clearly scopes the tool to a single Detsky Mir product and distinguishes it from sibling marketplace cards by naming the retailer and the category coverage. Even without reading the schema, an agent knows exactly 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when this tool is valuable: 'Covers the kids-and-baby category that the general marketplaces cover unevenly' and distinguishes Detsky Mir's own stock from third-party sellers. It does not explicitly enumerate when not to use it or name alternative sibling tools, but the market-specific positioning and the 'for one product' scope make the appropriate use case reasonably clear.
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 readOnlyHint and idempotentHint, the description defines the full tri-state contract (success, drift_detected, inconclusive) including the important caveat that inconclusive says nothing about parser health. This is valuable behavioral disclosure not present in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main verb and scope are front-loaded, and each sentence adds meaning: state definitions, the drift consequence, the inconclusive caveat, and when to run it. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless self-check tool with a rich output schema and safety annotations, the description fully covers purpose, result interpretation, and timing. It leaves no gap an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so there is no parameter burden for the description to carry. The baseline for a no-parameter tool is 4; no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Probe every Detsky Mir endpoint family and report a tri-state verdict,' a specific verb and resource scope that clearly distinguishes it from data-fetching siblings like detmir_card and detmir_category. The self-check role is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit run-time guidance is given: 'Run it after install and whenever results look wrong.' It does not enumerate alternatives or when-not scenarios, but the no-argument diagnostic nature and marketplace-specific naming make the context clear.
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 readOnly/idempotent annotations, the description discloses critical runtime behavior: it uses the operator's Chrome via CDP, treats Qrator-blocked or CDP-down as inconclusive transport failures, and defines drift strictly as a rendered page yielding zero tiles. This substantially reduces the risk of misinterpreting transport errors as drift.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sections deliver the core purpose, the critical tri-state interpretation rule, and the return type with no filler. The description is front-loaded and every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool that already has an output schema and safety annotations, this description fully covers the important behavioral nuances and edge cases. Nothing essential for correct invocation or interpretation appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is no parameter ambiguity for the description to clarify. The baseline of 4 is appropriate because no schema gap needs compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-noun pair ('Structural drift canary') and names the target resource ('DNS-Shop'), then concretely states what it does: renders a live search page and checks tile extraction. This makes it clearly distinct from sibling tools like dns_search and the other *_selfcheck tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes this as a drift canary for DNS-Shop, which implies monitoring/health-check usage, and it gives explicit decision rules for interpreting inconclusive vs drift. It does not explicitly name alternatives or state when not to use it, but the intended context is clear enough for an agent to route correctly.
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 goes well beyond the annotations by disclosing the Tier-1/Tier-2 fallback strategy, automatic page walking, 30 reviews per page, deduplication by review UUID, a hard cap of 10 pages, and detailed partial-success semantics. It also explains exactly when errors are raised versus when failures degrade to partial results. This is exceptionally transparent and does not contradict the readOnly/idempotent 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: purpose, transport fallback, pagination behavior, return format, and error semantics are all directly relevant to invoking the tool correctly. The use of headings and front-loaded key information keeps it navigable despite its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is remarkably complete. It covers input normalization, pagination, dedupe, hard limits, exact return fields, partial success conditions, and error types. The presence of an output schema further reduces the need to describe return values, so nothing important is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters at 100% coverage, so a baseline of 3 is appropriate. The description adds real value by explaining how `limit` interacts with pagination: pages are walked until `limit` texts are collected, with deduplication and a hard page cap. This gives the agent a more accurate mental model of what `limit` means in practice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb and resource: 'Fetch Ozon product review texts + star distribution'. It clearly distinguishes itself from sibling tools like ozon_card or ozon_search by focusing on reviews plus the distribution, and it even references the same fetch path as ozon_card for technical context. An agent can understand exactly 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use case obvious: retrieving Ozon product review texts and star distributions. It also explains pagination behavior and partial-success semantics, which guide the agent when interpreting results. However, it does not explicitly state when to choose this tool over a sibling such as ozon_card or ozon_search, so the guidance is clear but not exhaustive.
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 already declare readOnly, idempotent, and non-destructive behavior. The description adds genuinely useful behavioral context beyond those hints: the live menu is ~800 KB, responses are always a bounded slice, and errors are raised as ToolError with a JSON message indicating retryability. This gives an agent a clear expectation for size and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the core purpose. Every sentence contributes: the use case, the contrast with search, the shard/query relevance, the size constraint, and the error format are all useful with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and rich annotations, the description is complete for an agent to select and call the tool correctly. It covers purpose, when to use it, how to navigate the large tree, response bounding, and error behavior. No critical operational detail appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the descriptions of root and max_depth already handle parameter meaning. The tool description adds strategic context by explaining why the bounded slice exists and recommending an iterative expand-from-top approach, which makes the parameters' intended usage clearer than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Browse') and resource ('the Wildberries catalog tree'), and clarifies its role versus wb_search by noting that wb_search needs a query string while this tool lets a shopper discover categories. It also explains that nodes expose shard/query selectors for pulling a category feed, distinguishing it from feed/product tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('before searching') and contrasts it with wb_search, which needs a query string. It also advises starting at 'top' and expanding the branch of interest. However, it does not explicitly mention the sibling wb_category_products as the follow-up tool for pulling a feed, though that is implied by mentioning shard/query selectors.
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 already mark this as read-only, idempotent, and non-destructive, so the bar is lower. The description adds important behavioral details beyond annotations: the endpoint returns a fixed ~1000-review pool, is newest-first, ignores server-side order params, and applies sort client-side. This materially affects how the agent should interpret results and is exactly the kind of disclosure that helps avoid misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then provides only high-value caveats in a compact sequence. Every sentence earns its place: pool indexing, fixed 1000-review pool, server-side order being ignored, client-side sort, and the 'worst' alias for complaint discovery. There is no filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, output schema, and annotations, the description covers the remaining behavioral context an agent needs: why imt_id matters, the bounded review pool, sort semantics, and the recommended way to find complaints. Nothing essential to calling this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the conceptual relationship between imt_id and nmId, clarifying that sort operates over the fixed returned pool rather than all feedbacks, and emphasizing that 'worst' reorders by lowest rating to surface complaints. These details go beyond the schema entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific action and resource: 'Fetch reviews by imt_id'. It also names the source of the id ('root_id from wb_root_info') and distinguishes this review pool from nmId-based lookups, which separates it from sibling tools like wb_card and wb_root_info. The purpose is immediately clear and not tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use imt_id, not nmId, because all variants share one review pool; and it explains how sort behaves given the endpoint's fixed pool. It does not explicitly name alternatives or say 'use wb_questions for questions instead', but the practical context is strong enough for an agent to know when this tool applies.
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 goes well beyond the readOnly/idempotent annotations by explaining the tri-state semantics: transport/OOS issues are inconclusive, only reached-200 bodies with missing anchors are drift. It also discloses the exact endpoint dependencies and why their failure would propagate to wb_search, wb_root_info, or wb_reviews.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The bullet-list structure is dense but every sentence earns its place: purpose, probed endpoints, dependent tools, failure interpretation, and invocation guidance. The most important tri-state result is frontloaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool takes no parameters and annotations already cover safety, the description is fully complete. It explains what is checks, how to interpret outcomes, and when to run it; an output schema can describe the technical return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the empty schema already covers parameter semantics completely. The description reinforces this by showing that the canary runs with no inputs and probes everything by itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: a 'structural drift canary' for WB with a tri-state result. It differentiates this diagnostic from functional WB tools by naming the endpoint families it probes and the dependent tools that would break on drift.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Run on demand before trusting a batch.' It does not explicitly name alternatives or exclusions, such as the other marketplace selfchecks, but the intended trigger scenario is clear.
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 already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds meaningful behavioral detail beyond annotations: reviews are capped at ~13 server-rendered items, the connector deliberately avoids the additional review-loading API, and errors follow a structured ToolError JSON with retryability information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently organized: main purpose first, then differentiators, then the cap/limitation, then error behavior. The bolded star distribution point and the review-cap paragraph earn their place because they guide correct interpretation of results, and the error format section is compact and valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema and clear annotations, the description covers the essential remaining gaps: unique data value, the review count limitation, and error/retry behavior. Nothing critical is missing for an agent to invoke the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description enriches the include_reviews parameter by explaining that reviews arrive with the card 'complete with pros, cons and helpfulness votes' and that the cap is ~13. This adds useful context not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action and resource — 'Fetch full detail for a Yandex Market product' — and enumerates the concrete contents: prices, rating breakdown, reviews. This clearly distinguishes the card tool from search and selfcheck siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: call this when you need detailed product information, star distribution, and reviews in a single request. It does not explicitly name alternatives or state when not to use it, but the context is unambiguous enough for an agent to route correctly.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond these by explaining the three possible verdicts, clarifying that 'inconclusive' means transport/geo/captcha issues rather than parser failure, and noting that SSR extraction is inherently coupled to front-end drift. This gives the agent useful behavioral context beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loads the core action, and uses concise bullet-style definitions for each verdict. The final sentence about SSR drift adds meaningful context without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, an output schema available, and annotations covering safety/idempotency, the description fully covers what an agent needs: the tool's purpose, the meaning of each result, and why drift is expected. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter documentation burden. The description reinforces that the tool needs no inputs and focuses on its verdict output. Baseline 4 is appropriate for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Probe Yandex Market's search and card pages' and 'report a tri-state verdict.' It clearly positions the tool as a health-check/probe rather than a data-fetching tool, distinguishing it from yandex_search and yandex_card and from other platform selfchecks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for detecting whether SSR extraction rules still parse Yandex Market pages, with verdict meanings explained. It does not explicitly name alternative tools or state when not to use it, but the probe/verdict framing makes the intended use reasonably obvious.
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 readOnly and idempotent annotations, the description discloses meaningful behavior: questions are pooled across variants by imt_id, an nmId returns an empty pool without an error, and seller answers are often the only public statement of a product fact. This helps the agent interpret empty results and choose the correct key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action is front-loaded in the first sentence, and later paragraphs earn their place by explaining purpose, keying, and a common failure mode. A few illustrative examples make the description slightly longer than strictly necessary but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a rich output schema, full parameter coverage, and safety annotations, so the description only needs to add selection context and keying behavior. It covers the prerequisite (wb_root_info), the wrong-key failure mode, and the distinction from reviews, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds value by emphasizing that imt_id is the root id from wb_root_info and that a wrong key produces an empty pool rather than an error. This reinforces the correct use of the imt_id parameter beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource: "Fetch buyer questions and seller answers by imt_id." It also distinguishes the tool from wb_reviews by explaining that reviews describe the ownership experience while questions clarify what the product actually is, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: resolve imt_id via wb_root_info first, do not pass an nmId, and expect an empty pool if you do. It also positions the tool against wb_reviews, clarifying when questions are more useful than reviews.
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 annotations indicating a read-only, idempotent operation, the description reveals the defensive import behavior and the semantic meaning of the 'skipped' field: a missing dependency removes a marketplace rather than crashing the server, and skipped entries were never queried. This context is not derivable from the annotations and is critical for interpreting results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then uses two clearly labeled sections ('Why this exists' and 'Return Format') that each add necessary context. Every sentence serves a purpose, and the markdown structure makes it easy for an agent to scan for the key trigger and return semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only diagnostic tool with a rich output schema and safety annotations, the description covers everything an agent needs: what it lists, why missing marketplaces appear, when to invoke it, and what the skipped mapping means. No important operational detail is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so there is no parameter semantic burden on the description. With an empty input schema and 100% schema coverage, a baseline of 4 is appropriate; the description cannot and need not add parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List which connectors this unified server actually mounted.' This clearly distinguishes the tool from the sibling marketplace search/card tools, which query individual marketplaces, by focusing on what is loaded on the server. The title 'Which Marketplaces Are Loaded' reinforces the same purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger: 'Call this before concluding a marketplace has no results — if it is in ``skipped``, it was never queried at all.' It explains the failure mode where absent tools look identical to empty results, which tells the agent exactly when this diagnostic is needed. This is a clear, directive usage guideline.
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

Kettu Marketplace Intelligence MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Kettu Marketplace Intelligence MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/neuratechcompany-ops/kettu-marketplace-mcp/badges/card.svg)](https://glama.ai/mcp/servers/neuratechcompany-ops/kettu-marketplace-mcp)

Score Badge

Copy to your README.md:

[![Kettu Marketplace Intelligence MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/neuratechcompany-ops/kettu-marketplace-mcp/badges/score.svg)](https://glama.ai/mcp/servers/neuratechcompany-ops/kettu-marketplace-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/neuratechcompany-ops/kettu-marketplace-mcp'

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