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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real context beyond them: the card is rendered through the operator's live Chrome instance, review texts are deliberately omitted due to an anti-bot challenge, and price_rub returns None rather than 0 when no price is stated — a null-semantics detail an agent would otherwise misread.

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

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

The core action is front-loaded in the first sentence, followed by two short caveats and a pointer to a guide resource for the full field list and error codes. Every sentence carries information; the only mild inefficiency is that the guide pointer defers detail an agent must fetch separately.

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

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

An output schema exists, so return values need not be enumerated, and the description correctly limits itself to the two non-obvious output behaviors (missing reviews, None price). Error codes and the full field list are offloaded to guide://aliexpress/aliexpress_card, which is an acceptable completeness strategy for a single-parameter read tool.

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

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

The single parameter has 100% schema description coverage including the id format and an example URL, so the schema does the heavy lifting and the baseline applies. The description adds no further meaning about item_id_or_url beyond what the schema already states.

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

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

"Fetch one AliExpress product card, rendered in the operator's Chrome" gives a specific verb (fetch) and resource (single product card) and scopes it to one item, which implicitly separates it from aliexpress_search. It stops short of naming the sibling search tool explicitly, so the differentiation is inferable rather than stated.

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

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

There is an implicit exclusion: review texts are not available here because they require the x5sec-challenged review tab, which tells an agent not to reach for this tool when reviews are needed. However, no positive when-to-use condition or explicit alternative (aliexpress_search, compare_prices) is named, so routing is left to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: results come from a live Chrome render, prices can be absent (None, never 0), and zero tiles without a challenge indicates parser drift rather than an empty catalog. That last point is a real failure-mode disclosure an agent could not get from the schema or annotations.

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

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

Three short sentences, front-loaded with the core action, and no filler. The price_rub/parser-drift sentence is dense and slightly cryptic in isolation, but it earns its place by covering an important failure mode. Nothing is redundant with the structured fields.

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

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

An output schema exists, so return values need not be enumerated, and the description wisely points to guide://aliexpress/aliexpress_search for the full field list and error codes. It covers the most dangerous ambiguity for this tool (empty result vs. parser drift) and notes the browser-rendered dependency. It leaves pagination, rate limiting, and challenge-handling behavior unstated, but the linked guide resource mitigates that.

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

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

There is a single parameter with 100% schema description coverage (including an example query in Russian), so the schema already carries the meaning. The description says nothing additional about the query string, such as language handling or whether it maps to AliExpress's own search syntax. Baseline 3 is correct when the schema does the work.

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

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

"Search AliExpress, rendered in the operator's Chrome" names a specific verb and resource and implies the distinction from aliexpress_card without spelling it out. The added note that rendering happens in the operator's browser is a meaningful qualifier about how the search is executed. It stops short of explicitly differentiating itself from the sibling card tool or other *_search tools.

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

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

There is no explicit statement of when to use this versus aliexpress_card or the other marketplace search tools. The second and third sentences are about interpreting results rather than about when to invoke the tool or what prerequisites (browser session, auth) must be in place. Guidance must be inferred from the name alone.

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

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

Annotations already cover readOnly/idempotent/openWorld, and the description adds real behavior beyond them: the JSON-LD-then-DOM extraction order, the path-normalization/redirect behavior, and the None semantics for price, location, posted_at, views and seller. It stops short of describing latency, rate limits, or failure conditions, which is why it is not a 5.

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

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

Front-loaded with the core operation, then input handling, then output semantics, then a pointer to the guide resource. The URL-parsing sentence is dense and slightly over-detailed for a tool description, but every sentence carries information.

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

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

With an output schema present, the description wisely does not enumerate return values, yet still flags the important null semantics (price never 0). Full field list and error codes are deferred to a guide resource, which is an appropriate boundary for a single-parameter read tool.

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

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

Schema coverage is 100% and there is only one parameter, so the baseline is already met; the description nonetheless adds concrete meaning the schema does not — which URL forms are valid, that query/fragment is stripped, and that numeric/slug input is rewritten to /{id}. That is genuine added value over the schema's terse 'Item id, slug path or full avito.ru URL'.

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

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

The description states a specific verb and resource ('Read an Avito item over CDP') and even names the extraction strategy (JSON-LD first, DOM fallback). It is clearly distinguishable from avito_search and avito_seller by being item-scoped, though it never explicitly contrasts itself with those siblings.

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

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

Usage is only implied: supply an item id or URL and the card is fetched. The accepted URL shapes (item path, slug path, city/category path) give useful input context, but there is no explicit when-to-use versus avito_search, no stated prerequisites, and no note on when the DOM fallback triggers.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds two genuinely non-obvious behaviors beyond that: price_rub being null rather than 0 for unpriced ads, and a pointer to the guide resource for error codes and the full field list. It does not disclose rate limits or pagination-cap behavior, which keeps it off a 5.

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

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

Three short sentences with the core action front-loaded and zero filler. The middle sentence about price_rub is a null-handling caveat that arguably belongs with return values, but it is short enough not to hurt scanability.

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

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

With an output schema present and full schema coverage, the description need not restate fields; it correctly outsources the details to guide://avito/avito_search. What is missing is the one thing structured fields cannot convey: the relationship to avito_card and avito_seller in a multi-tool workflow.

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

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

Schema description coverage is 100%, so the schema already explains query, page, category_id and location_id (including the Moscow default). The description adds no parameter-level meaning of its own, so the baseline 3 applies.

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

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

The description opens with a specific verb+resource ("Search Avito listings") and names the backing endpoint, so the agent immediately knows this is a listing search. It does not explicitly contrast itself with the lookalike siblings avito_card and avito_seller, which is the only thing separating a 4 from a 5.

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

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

Usage is only implied: it is a search tool, so the agent can infer "start here, then use avito_card for details". There is no statement of when to prefer it over avito_card/avito_seller or of any prerequisites, so it stays at minimum-viable guidance.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description adds genuinely new behavior: paced allowlisted CDP, query/fragment stripping, and that active_items is None by design while unknown reputation fields are None rather than 0. That None-vs-zero rule is exactly the kind of nuance annotations cannot carry. It does not mention rate-limit backoff or failure/error semantics inline, deferring those to the guide resource.

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

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

Front-loaded with the core action, then progressively narrower detail (input forms, then known-data caveats, then a pointer to the guide). Dense and telegraphic in places, but every line carries operational information; nothing is filler.

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

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

Output schema exists, so return values need not be spelled out, and the description correctly defers full field lists and error codes to guide://avito/avito_seller. The None-by-design notes cover the main output gotcha. A brief note on failure modes (e.g., what happens on an invalid path) would make it complete.

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

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

Schema coverage is already 100%, yet the description still adds real semantics: the two accepted URL families, that only a bare 32-hex hash builds /brands/<id> while other bare ids build /user/<id>/profile, and that query/fragment are stripped. This is dispatch logic an agent could not infer from the schema alone.

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

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

States a specific verb and resource ('Read an Avito seller's rendered profile page') plus the transport ('paced, allowlisted CDP'). This is clearly separable from the sibling avito_card (item-level) and avito_search tools, so an agent knows this targets seller entities.

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

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

Gives concrete guidance on which inputs are valid and which path each input shape maps to, plus a negative hint that /web/1/js/items cannot identify sellers (routing the agent away from a dead end). It never explicitly says 'use this instead of avito_card when…', so it stops short of naming alternatives.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds real behavioral context beyond them: price_rub is None rather than 0 when no price is stated, and price_unit disambiguates 'total'/'month'/'day', which prevents a common misinterpretation.

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

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

Three short paragraphs, front-loaded with what the card returns, followed by the two highest-risk semantic caveats and a doc pointer. Nothing is redundant with the schema or annotations.

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

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

Output schema exists, so return-value detail is unnecessary, and the description still flags the price/unit traps and points to guide://cian/cian_card for the full field list and error codes. Only the sibling routing advice is missing.

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

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

Schema coverage is 100% and the single parameter already documents the accepted id-or-URL form, so the description adds no new input syntax. The value it adds (price nullability and unit meaning) concerns output interpretation rather than parameters.

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

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

"Read one Cian offer" states a specific verb and single-resource scope, then enumerates the returned content (price/history, layout, building, address, metro, description, publisher). This clearly separates it from the sibling cian_search, which returns lists rather than one card.

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

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

The singular-object framing implies you call it once you have an offer id or URL, and the parameter description reinforces that. However, it never explicitly says when to prefer cian_search or compare_prices instead, nor what to do when the id is unknown.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered; the description instead adds data-shape behavior an agent could not infer — pages never mix deal markets, price_rub is None rather than 0 when absent, and price_unit governs comparability. It also points to guide://cian/cian_search for the full field list and error codes, which is genuinely useful context.

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

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

Front-loaded with the core purpose and the no-free-text constraint, followed by two short paragraphs on the two most common mistakes. Slight redundancy: the price_unit caveat appears in both the prose and the `deal`/`price_max` schema descriptions, so a little text is duplicated rather than earned.

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

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

With 100% schema coverage and an output schema, the description need not re-document fields or return values, and it correctly delegates full details to the guide resource. However, for a nine-parameter open-world search tool it says nothing about pagination limits in prose or about what the result set contains, leaving those entirely to structured fields.

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

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

Schema coverage is 100%, so the schema already documents all nine parameters, and the description's notes on deal/price_unit largely restate the enum description on `deal`. Baseline 3 is appropriate — the description reinforces the most error-prone parameter but adds little that is not already in the schema.

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

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

"Search Cian offers by filters" names a specific verb and resource, and "there is no free-text search" immediately separates it from the query-driven *_search siblings. It stops short of naming cian_card as the tool for a single known offer, so the sibling routing is only partly done.

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

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

The description gives a clear constraint (filters only, no free-text) and explains that rent and daily are separate markets whose prices cannot be compared in one pass. That is interpretive guidance rather than when-to-use guidance: it never says when to pick cian_search over cian_card, nor any prerequisite about region defaults.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered structurally. The description adds genuinely non-derivable semantics: price_rub and old_price_rub are None when the card states no price, never 0 — a real footgun-prevention note. It also routes to an external guide for error codes, though it doesn't summarize them inline.

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

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

Three short lines, front-loaded with the verb and resource, then the price-null semantics, then the reference link. No filler sentences and nothing an agent must wade through to call the tool.

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

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

An output schema exists, so return fields needn't be enumerated, and the description correctly defers them to the guide resource. For a single-parameter read tool this is nearly complete; the only shortfall is that error codes are pointed at externally rather than characterized.

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

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

Schema coverage is 100% and the single product_url parameter is fully documented with format, length bounds and an example path. The description adds nothing about the parameter itself; its only extra content concerns output fields, so the baseline 3 applies.

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

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

"Fetch one Citilink product card" gives a specific verb (fetch) and a bounded resource (one product card), which distinguishes it from the listing-oriented citilink_search sibling. It stops short of naming the sibling explicitly, so the differentiation relies on the agent inferring 'one card' vs 'search'.

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

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

Use is implied by the name and the single required product_url: fetch details for one already-known Citilink product. There is no explicit statement of when to prefer this over citilink_search or compare_prices, and no prerequisite guidance beyond the URL constraint the schema already supplies.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds real context beyond them: the result is 'rendered in the operator's Chrome,' signaling browser-rendering latency/fragility, and the price_rub=None caveat shows a null-vs-zero semantic quirk on a search surface.

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

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

Three tight lines, front-loaded with purpose, then a return-value caveat, then a pointer to the guide resource. No wasted wording and each sentence earns its place.

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

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

An output schema exists so return fields needn't be spelled out, and the guide:// pointer offloads field/error-code detail. Still, the description is thin for a search tool, omitting pagination, result-count behavior, and how to follow up with citilink_card.

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

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

Schema coverage is 100% for the single query parameter (including an example value), so the schema carries the burden and the description adds no parameter meaning. Baseline 3 is appropriate given one fully documented param.

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

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

States a specific verb+resource ('Search Citilink') and, by naming the Citilink source, implicitly distinguishes it from the other marketplace searches (ozon_search, wb_search) and from its own citilink_card detail sibling. It stops short of explicit sibling differentiation in the text itself.

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

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

Implied usage only: as a 'search' verb the when-to-use is reasonably inferable, and the pairing with citilink_card is discoverable from the sibling list. But there is no explicit 'use this to find items, then citilink_card for details' routing or any exclusion guidance.

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

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

Beyond the annotations (readOnly/openWorld/non-destructive), it discloses the return shape (JPEG plus capture time, dimensions, operation, origin), the payload size band (25-54 KB), the layered delivery policy (include_image x COMPARE_SNAPSHOT_IMAGES x client vision hint), and the graceful-degradation fields (image_delivered, image_omitted_reason). The privacy warning that page content is untrusted and may contain session personal data is a genuinely useful behavior note that annotations cannot express.

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

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

Front-loaded with purpose, then prerequisites, then return, then the delivery-decision nuance, with a pointer to guide://compare/compare_browser_snapshot for the full field list and error codes. It is information-dense with little filler, though the delivery-policy paragraph is heavier than it needs to be for a two-parameter tool.

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

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

An output schema exists, so return values need not be enumerated, yet the description still names the key fields and the failure-mode reporting. Combined with annotations and the guide resource reference, an agent has everything needed to call it correctly and interpret an image-less response.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning: it justifies the image-size tradeoff that makes include_image consequential and explains that omitting the image still yields full metadata plus a reason code. The rest of the include_image explanation largely restates the schema description, so it does not reach 5.

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

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

The opening sentence gives a specific verb and resource: 'Return a retained page's viewport as an MCP image.' The followed-up clause 'Captures only that owned page' further scopes it to a handoff-bound session page, which no sibling (wb_card, ozon_search, compare_verify_offer, etc.) does. It stops short of 5 because it never names a sibling or states the boundary explicitly in comparative terms.

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

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

It states the prerequisite ('Requires an unexpired same-session handoff'), the client-side condition ('Use only when the client/model supports images'), and an explicit negative list of what it will not do ('does not navigate, extend expiry, solve a challenge, or call another model'). An agent knows both when to call it and when not to.

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

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

Beyond the read-only, idempotent, open-world annotations, the description explains important output behavior: ranking excludes Yandex Plus subscription prices, source_outcomes and complete distinguish partial comparisons from absent products, and loose title matching plus size checks affect cheapest_comparable. This gives the agent meaningful context about what the results do and do not mean.

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

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

The description is front-loaded with purpose and usage, then uses short labeled bullets for the two output caveats, followed by a matching caveat and a guide reference. Despite its length, every passage carries actionable information for a multi-marketplace comparison tool.

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

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

Given the tool's complexity, annotations, and output schema, the description covers the key ambiguities an agent needs: partial results, subscription-price exclusion, loose matching, and size verification. It also points to the guide for the full field list and error codes, so nothing essential is missing.

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

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, but the description adds meaningful query semantics: titles are matched loosely and storage or memory sizes in the query are checked against result titles. It does not add detail for sources, in_stock_only, or per_source_limit beyond what the schema already documents.

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

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

The description states a specific verb and resource: price one product across every configured Russian marketplace at once, returning a ranked list and per-source report. It also explicitly distinguishes this from running per-marketplace search tools one at a time, so an agent can separate it from siblings like wb_search or ozon_search.

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

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

It gives clear usage guidance with the phrase "This is the tool for 'where is X cheapest'" and contrasts it with per-marketplace search tools that are slower and lack ranking. It does not explicitly name when not to use it or point to specific siblings like compare_verify_offer or compare_sources, so it falls short of the fully explicit when/when-not/alternatives bar.

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

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

The annotations already declare readOnly, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The description adds genuine behavioral value by framing the tool as a diagnostic that disambiguates two failure classes and pointing to a guide for error codes. It doesn't say what the report looks like beyond the output schema, which is acceptable here.

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

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

Three short sentences, front-loaded with the core purpose, followed by the triggering condition and a pointer to deeper documentation. Nothing is repeated and no sentence is redundant.

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

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

An output schema exists, so return values need not be described, and the error-code guide reference covers deeper detail. What's missing is the relationship to the near-identical sibling tools marketplace_sources and marketplace_health, which an agent would need in order to choose correctly.

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

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

The tool takes zero parameters, so there are no parameter semantics to document and the baseline of 4 applies. The description correctly avoids inventing arguments and notes the guide reference instead.

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

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

The description gives a concrete verb and resource: report which marketplaces this installation can actually query. That resolves the ambiguity of the opaque name 'compare_sources' and the broad title. It does not name the very similar sibling tools (marketplace_sources, marketplace_health), so it stops short of full differentiation.

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

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

It states a clear trigger: call this first when a comparison comes back partial, and explains why (distinguishing a missing connector from a marketplace refusal). That is actionable context. However, it never mentions what to use otherwise or how it differs from marketplace_sources and marketplace_health, which appear to overlap heavily with this tool.

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

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

Annotations already cover readOnly, idempotent and openWorld, so the safety profile is settled. The description adds genuinely useful context beyond them: the returned card is source-native and retains fields the comparison layer normalises away, and it is the low-cost follow-up. It omits rate limits, auth and error behaviour, deferring errors to a guide URI.

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

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

Three short sentences with the core action and the cost/scope trade-off front-loaded. No filler, though the guide reference occupies space without adding explanatory content.

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

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

Output schema exists and the input schema is fully documented, so return values and parameters needn't be restated. What the description lacks is any inline error or mismatch behaviour, which it offloads entirely to the guide URI rather than summarising the key cases.

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

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

Schema description coverage is 100%, so the schema already explains source, product_id_or_url, expected_identity, expected_price_rub and expected_variant_id. The description adds no per-parameter meaning, only a pointer to `guide://compare/compare_verify_offer` for the full field list. Baseline 3 applies.

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

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

States a specific verb and resource ('Verify one compared offer') and explains it goes 'through its marketplace card tool', which is a concrete mechanism. It is distinguishable from compare_prices by the 'cheap compare-server follow-up' framing, though it doesn't explicitly name the sibling card tools it wraps.

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

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

Gives a clear use condition: confirm the raw search price, stock and seller 'without enabling the full unified mount', which implicitly contrasts with the heavier path. It stops short of stating when NOT to use it (e.g. when you already have the source card tool or need normalised comparison fields).

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds real value beyond that: region is a per-call override of an environment default rather than a persisted setting, store_count is a count of physical shops that varies sharply by city, and price_rub is None (never 0) when no price is stated — a null-handling rule that prevents misreading results.

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

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

Front-loaded with a one-line summary of what is returned, then progressively deeper detail on region and edge cases. The bold emphasis line and re-verification anecdote are slightly decorative but earn their place by justifying the region guidance; nothing is redundant.

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

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

For a two-parameter, idempotent read with an output schema, this covers what an agent needs: scope, region override behavior, null price semantics, and a pointer to guide://detmir/detmir_card for the full field list and error codes. Deferring error codes to a guide is acceptable given a return schema already exists.

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

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

Schema description coverage is 100%, so baseline is 3, but the description goes further by explaining the consequence of region (it drives both online price and offline stock counts, with a concrete 152/37/2 city spread) and the override semantics. product_id is the only parameter left to the schema, which documents it adequately.

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

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

States a specific verb (fetch) and resource (one Detsky Mir product card) plus the exact fields returned: price, rating, stock, seller. It also positions itself against the sibling family by scoping to a single product rather than a category listing (detmir_category).

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

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

Gives concrete guidance for the region parameter — pass it to ask about a specific city, and it overrides DETMIR_REGION for this call only, enabling city comparisons in one session. It also implies the intended niche (kids-and-baby coverage the general marketplaces handle unevenly), but never explicitly says when to prefer detmir_category or compare_prices over this tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: each node carries `alias` and `products_count`, letting the agent gauge inventory depth before fetching a listing, and it points to a separate guide for error codes. It omits pagination behavior for the `limit` cap.

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

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

Front-loads the action and the payoff in the first sentence, then the rationale in a short paragraph. No filler sentences. The reference to a module docstring is slightly informal but costs little space.

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

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

With annotations covering safety, a full-schema parameter set, and an output schema in place, the description only needs to explain workflow placement and node contents, which it does. The reference to an external guide for full fields and error codes is acceptable but means some detail lives outside the description.

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

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

Schema description coverage is 100%, so all three parameters (limit, parent, region) are already documented in the schema. The description adds only indirect meaning, mentioning that aliases and products_count appear per node but not clarifying parameter syntax. Baseline 3 is appropriate.

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

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

States a specific verb+resource: browse the Detsky Mir catalog tree and obtain the aliases that `detmir_category` requires. It also names the sibling it feeds into, which distinguishes it from detmir_category itself. It stops short of differentiating from the other marketplace category tools (wb_categories), but the marketplace prefix makes that reasonably clear.

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

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

Explains the workflow context explicitly: since Detsky Mir has no working text search, the agent must walk the tree here first and then list a category via detmir_category. That is clear when-to-use guidance. It does not state when-not to use it (e.g. if you already have an alias), so it misses the top score.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint already declare a safe, repeatable read), the description discloses behavioral traits the agent could not infer: proper pagination with an upstream total count, JSON output rather than scraping, and the non-obvious rule that an empty page is not an error but surfaces via meta.warnings. That last point is genuinely valuable for error handling; only auth/rate-limit context is absent.

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

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

Front-loaded with the core verb and resource, then the differentiator, then the edge-case warning, then a pointer to the guide resource — a sensible ordering. The middle sentence is slightly discursive ("so it supports 'what's available and how much does it cost' without scraping") but each sentence still carries distinct information.

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

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

An output schema exists, so the description correctly avoids explaining return shapes, yet it still flags the two things an agent most needs to know about the response: the upstream total and the meta.warnings channel for empty pages. With full schema coverage and a guide:// resource for field lists and error codes, this is close to complete for a four-parameter read tool.

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

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

Schema description coverage is 100%, so alias, limit, offset and region are all documented in the schema itself, setting the baseline at 3. The description adds only an indirect hint about pagination behavior and never elaborates on alias format, the region default source, or limit ceilings, so it adds little meaning beyond the structured fields.

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

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

States a specific verb and resource ("List products in a Detsky Mir category") plus a scope note about the total match count, which immediately separates it from detmir_card and detmir_categories. It implicitly contrasts itself with text search but never names an actual sibling tool such as detmir_categories or a detmir_search equivalent, so the differentiation is generic rather than explicit.

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

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

Gives a clear positive selection rule: use this instead of text search to enumerate the catalog with real pagination and an upstream total, framed around the "what's available and how much does it cost" use case. It stops short of stating exclusions (e.g. when to prefer detmir_categories to find the alias first, or when a card lookup is better), so the routing 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.

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine value beyond that by disclosing a data-semantics rule (price fields are None when absent, never 0) and pointing to a guide resource for error codes. It stops short of describing failure behavior or rate limits inline.

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

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

Three short, front-loaded lines with zero filler: the action first, then the one non-obvious data rule, then a pointer for deeper detail. Every sentence earns its place.

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

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

An output schema exists, so return fields need not be enumerated, and error codes are deliberately delegated to the referenced guide resource. For a single-parameter read-only fetch this is essentially complete; the only soft spot is that the critical error information lives outside the definition.

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

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

Schema coverage is 100%, and the product_url parameter already carries a format constraint plus an example, so the schema does the heavy lifting. The description adds no meaning about the parameter itself, which is the expected baseline of 3 when the schema is complete.

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

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

The description gives a specific verb and resource ("Fetch one DNS-Shop product card") and names the marketplace, which separates it from the many sibling *_card tools for other sites. It does not explicitly contrast with dns_search, but the singular-card scope is clear from the wording.

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

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

Usage is only implied: an agent can infer this is the tool for a single known product page, with dns_search presumably for discovery. There is no explicit when-to-use statement, no prerequisites, and no named alternative for agents that have a product ID rather than a URL.

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

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 that results are rendered in the operator's Chrome and that price_rub is null rather than 0 when no price is shown, plus a guide link for error codes. This is meaningful behavioral context beyond the annotations, though it does not detail failure modes inline.

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

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

The description is three short lines, front-loads the search purpose, and each line adds useful information: execution context, price null semantics, and a reference link. There is no wasted wording.

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

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

For a one-parameter search tool with rich annotations and an output schema, the description covers purpose, browser rendering, and a notable output caveat. It omits explicit sibling routing, but the store-specific name and guide reference make it largely complete.

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

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

Schema description coverage is 100% and the single query parameter is documented in the schema with an example. The description does not add syntax or filtering semantics for query, so it meets the baseline for fully documented schema but adds no extra meaning.

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

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

The description states a specific verb 'Search' and a specific resource 'DNS-Shop', so the agent knows it is a store-search tool. It does not explicitly name dns_card or another sibling, but the 'search' vs 'card' naming and store name make the distinction reasonably clear.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no named alternative such as dns_card for product details. The store name and verb imply its use for product discovery on DNS-Shop, so usage is only implied.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine behavioral context by disclosing a two-stage retrieval strategy (GraphQL over HTTPS, then an in-page Chrome POST fallback), which hints at latency and possible browser dependence, but it never says what triggers the fallback, what failure looks like, or where the error codes live beyond a URI reference.

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

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

Two tight sentences with no padding, and the pointer to the guide is an efficient way to offload field and error detail. The structure is slightly off-target, though: it front-loads implementation mechanics instead of the outcome the agent cares about.

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

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

An output schema exists, so return values need not be restated, and the guide URI covers field lists and error codes. Still, for a single-SKU lookup tool the description leaves the agent guessing about scope relative to the sibling search tools and about fallback conditions, which is a real gap for correct invocation.

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

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

Only one parameter exists and schema coverage is 100%, with the property description already explaining the SKU-versus-URL forms and an example. The description adds no further meaning such as accepted URL variants or behavior for malformed identifiers, so the baseline 3 applies.

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

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

"Fetch a GraphQL card" gives a verb and an object, but "card" is internal shorthand and the sentence emphasizes transport (HTTPS, POST fallback) over what the tool actually returns, namely product-card data for a given Lamoda SKU or URL. It does not distinguish itself from the sibling lamoda_search beyond its name, so an agent must infer the split.

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

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

There is no when-to-use guidance at all: nothing says to call this for a single known product versus lamoda_search for discovery, and no prerequisites (valid SKU, reachable lamoda.ru URL) are stated. The only routing hint is the guide URI, which pushes the decision to an external resource.

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

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

Annotations already declare read-only, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds real context beyond that: results come from a browser render in the operator's Chrome, category discovery is unavailable, and price_rub is None (never 0) when absent while ratings do not exist — all of which prevent misreading of results.

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

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

Three short, front-loaded lines with no filler; the operational constraint comes first and the data caveats second. The phrase "discovery is blocked tier 1" is terse to the point of being cryptic for an outside reader.

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

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, the description covers the essentials: how results are produced, what is not available, and how to interpret missing price values. It also points to a guide resource for the full field list and error codes, so remaining gaps are deliberately delegated.

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

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

Only one parameter, and the schema already documents it at 100% coverage with an example query. The description adds nothing about query syntax, language, or transliteration handling, so the baseline 3 applies.

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

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

States a specific verb+resource ("Search Lamoda") and adds a runtime detail that shapes expectations (rendered in the operator's Chrome). It does not name lamoda_card or explain how this differs from fetching a single product, so sibling differentiation is left implicit.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no routing to lamoda_card for product details or to the other marketplace *_search siblings. The parenthetical "discovery is blocked tier 1" hints at a limitation but is unexplained jargon rather than actionable guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, but the description adds behaviour they cannot express: it reads only local state, performs no navigation, and does not autostart, open, or close Chrome. That is real added value for an agent deciding whether this is safe to call mid-fan-out. It stops short of describing how cooldown or challenge state is reported, which is left to the guide and output schema, so a 4 rather than a 5.

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

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

The core claim is front-loaded in the first sentence, and the enumerated questions are each informative rather than filler. The negations are slightly redundant — 'spending no navigation' is immediately re-specified as 'no autostart, nothing opened, nothing closed' — which makes the block denser than strictly necessary, though not wasteful.

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

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

With zero params, full annotation coverage, and a dedicated output schema, the description only needs to explain purpose, timing, and safety, all of which it does, while deferring field-level and error-code detail to the named guide resource. Nothing an agent needs in order to decide to call this is missing.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the schema carries no semantic burden; the baseline for a no-param tool applies. The description correctly says nothing about inputs and instead points to the guide for the full field list of what comes back.

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

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

States a specific verb and resource ('Report transport health from local state, spending no navigation') and then enumerates exactly what the report covers: Chrome reachability, breaker cooldown hosts and durations, retained challenge pages, and the unblock page per mounted source. This cleanly separates it from every sibling, which are all marketplace content fetchers, and the 'pre-flight that replaces finding a dead Chrome by failing' framing makes the role unmistakable.

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

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

Gives an explicit trigger ('before a fan-out') and an explicit boundary ('It cannot prove a marketplace is up — only a call can'), which effectively names the alternative behaviour: use an actual wb_*/ozon_*/etc. call to verify a marketplace. It also frames the tool as a cheaper substitute for discovering a dead Chrome through failure, so both when and why-not are covered.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's added value is the failure-mode explanation: defensive imports drop a marketplace, and config-less sources are omitted because they would only yield auth_missing. The crucial disclosure that 'if it is in skipped, it was never queried at all' is genuinely useful context an agent cannot derive from annotations or schema. Deductions apply because it does not describe the response shape it returns (mounted vs. skipped vs. failed) and defers field/error-code detail to an external guide URI rather than synthesizing it.

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

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

The core statement is front-loaded, and the 'Why this exists' block is short and earns its place by explaining the absent-vs-empty ambiguity. The section heading is slightly heavier than needed for three sentences of rationale, but there is no filler content.

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

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

A zero-parameter read tool with a full output schema and clear annotations needs little more. The description supplies the one thing structured fields cannot: the operational caveat that a missing marketplace is silent, plus a pointer to the guide resource for field-level detail.

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

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

The tool takes zero parameters, so there is no parameter meaning to add and the baseline is 4. The description correctly avoids inventing input semantics and instead spends its words on result interpretation.

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

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

The first line states a specific verb and resource: 'List which connectors this unified server actually mounted.' That is concrete and distinguishable from data-query siblings like wb_search or ozon_card. It does not explicitly contrast with diagnostic siblings such as marketplace_health or compare_sources, so an agent must infer that distinction rather than being told.

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

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

Gives an explicit trigger condition: 'Call this before concluding a marketplace has no results.' That is a clear, actionable when-to-use rule tied to a real ambiguity (empty vs. never queried). It stops short of naming an alternative tool or when-not-to-call, so it lands at 4 rather than 5.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral value beyond them: the explicit contract that price_rub and old_price_rub are None (never 0) when a card omits a price, which prevents a common agent misinterpretation, plus a pointer to the guide resource for error codes.

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

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

Three short lines: purpose first, then the most easily misread output nuance, then the reference pointer for detail. Nothing is padded and the ordering puts the actionable information up front.

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

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

An output schema exists, so return-field enumeration is unnecessary, and the price-null caveat plus the guide:// reference cover the remaining ambiguity for a one-parameter read tool. The only shortfall is that it never states the prerequisite that an item id or URL must first be obtained, nor what the guide contains beyond error codes.

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

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

The single parameter is fully documented in the schema ("Goods id or megamarket.ru product URL"), including length bounds, so coverage is 100% and the baseline applies. The description adds nothing about accepted id formats or what happens when a URL from another marketplace is passed, so it neither compensates nor detracts.

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

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

"Fetch one Megamarket product card" gives a specific verb and resource, and the word "one" signals single-item detail rather than listing. It implicitly contrasts with the many *_search siblings, but never names megamarket_search as the alternative, so differentiation is inferred rather than stated.

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

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

The verb "fetch ... card" implies this is the single-product lookup step, but there is no explicit when-to-use statement, no exclusion of search flows, and no mention of prerequisites such as needing an item id discovered via megamarket_search. Usage is only implied by the tool name and title.

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

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

Beyond the annotations (which already declare read-only, idempotent, non-destructive, open-world), the description discloses the address-resolution rule, warns that enabling the profile-address path reads a private account endpoint, explains how _meta.warnings and _meta.healthy behave, and identifies which warning kinds flip healthy to false. It even clarifies that a missing price is None rather than 0, which preempts a common misinterpretation.

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

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

The core action is front-loaded in the first sentence, followed by address semantics and then health/warning semantics in a logical order. The middle paragraphs are dense and lean on internal jargon ('shape drift', '_meta.healthy'), but nearly every clause carries operational information rather than filler.

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

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

An output schema exists, so return values need not be enumerated, and the description still calls out the two fields agents most often misread (price_rub and _meta.warnings). It also points to guide://megamarket/megamarket_search for the full field list and error codes, covering the remaining depth without bloating the text; what it omits is any statement of result count or page behavior.

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

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

Only one parameter, documented in the schema at 100% coverage with an example, so the baseline is 3. The description adds no syntax or format guidance for 'query' beyond the schema, and its extra detail concerns environment-driven address context rather than the parameter itself.

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

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

States a specific verb and resource ('Search the Megamarket catalog') plus the transport ('mobile API, inside the operator's Chrome'), which tells an agent this is a real-browser-backed catalog search. It does not explicitly contrast itself with the sibling megamarket_card or the other *_search tools, so sibling differentiation is left to naming convention rather than stated.

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

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

Usage is implied by 'Search the Megamarket catalog' and the tool name, and the description gives useful configuration context (default city-level address vs MEGAMARKET_USE_PROFILE_ADDRESS=1). However, it never says when to prefer this over megamarket_card, compare_prices, or the other marketplace search tools, and names no exclusions.

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

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

Annotations already cover read-only, idempotent, non-destructive and open-world, and the description still adds substantive behavior: a Tier-1 curl_cffi attempt with a Tier-2 Chrome CDP fallback on 403, the hard prerequisite of running scripts/start_chrome_cdp.*, and two non-obvious data contracts (missing fields are None, never 0; an empty payload is healthy, not an error). That is exactly the context structured fields cannot convey.

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

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

Front-loaded with purpose, then the fallback chain, then the data-contract caveats, then a pointer to the guide resource. The cross-platform script paths are a bit verbose for a description, but each sentence carries operational meaning.

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

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

For a one-parameter read tool with an output schema and full annotations, this covers what remains: failure modes (403), the prerequisite for the fallback path, interpretation of missing/empty data, and a guide:// resource for the full field list and error codes. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the single parameter's description already covers the accepted forms (SKU string, full URL, /product/<digits>/ path) and SSRF rejection. The tool description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb and resource: "Fetch Ozon product card data via composer-api.bx". An agent can tell it apart from ozon_search and ozon_reviews by the 'product card' framing, but the description never explicitly names those siblings as alternatives, so differentiation is inferred rather than stated.

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

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

The guidance given is operational (tiered fetch, Cloudflare 403 fallback, Chrome CDP prerequisite) rather than selection guidance. There is no explicit statement of when to prefer this over ozon_search or ozon_reviews, so usage is implied by the tool name alone.

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

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

Well beyond the annotations: it discloses the Tier-1 curl_cffi / Tier-2 Chrome CDP fallback, 30-per-page auto-walking, dedupe by review uuid, a hard 10-page cap, and that a failed later page yields partial=True with stop_reason instead of an error. Annotations already cover readOnly/idempotent/openWorld, and the description adds operational behaviour an agent could not otherwise infer.

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

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

Front-loaded with the core action, then structured under a clear heading for the pool caveat and a bulleted note on partial success. Dense and mostly justified, though the prose is wordy in places (the pool explanation runs long).

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

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

For a paginated, fallback-driven scraping tool with an output schema, the description covers the risks an agent must know: shared review pools per card family, item_id versus requested_item_id, own_reviews and pool_variants, partial success, and a pointer to guide://ozon/ozon_reviews for full fields and error codes. Nothing material is missing.

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

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 real meaning: limit governs how many review texts are collected while distribution and total stay full, and paging continues until limit texts are gathered or pages run out. Sort behaviour is left entirely to the schema, which is a minor gap.

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

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

Names a specific verb and resource ('Fetch Ozon product review texts + star distribution'), states the data source (composer-api.bx), and enumerates returned fields and the pagination mechanism. An agent can distinguish it from ozon_card and ozon_search without opening any schema.

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

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

Gives clear conditional guidance: filter by item_id before concluding anything about a product, and flag when own_reviews is 0 because ratings may be borrowed from neighbouring variants. It also defines when a run is a partial success rather than an error. It stops short of explicitly naming a sibling alternative to use instead for card-level metadata, so it's a strong 4 rather than a 5.

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

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

Annotations already cover read-only, open-world, idempotent, and non-destructive behavior, so the bar is lower, yet the description still adds real operational context: a two-tier fetch strategy (curl_cffi then CDP fallback), the shape of each returned item, and the critical semantic that count=0 is a warning rather than a failure. The parser-internals line about tileGridDesktop-* widgets and mainState atoms is more implementation trivia than actionable behavior, keeping it from a 5.

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

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

The purpose and return shape are front-loaded in the first two lines, followed by the important zero-result caveat and a pointer to the guide resource. The middle line about Nov 2026 tileGridDesktop widgets is dense jargon that consumes space without helping an agent decide or invoke, which is the only real waste.

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

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

An output schema exists, so the description needn't enumerate return fields, and it correctly limits itself to a summary plus the non-obvious empty-result semantics and a deep-link to guide://ozon/ozon_search for full fields and error codes. For a two-parameter search tool this is close to complete; only the routing versus ozon_card/ozon_reviews is unaddressed.

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

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

Schema description coverage is 100% with only two parameters (query, page), and the schema already documents the Russian-language requirement and the 1..10 page range. The description adds nothing about query syntax, transliteration, or paging limits beyond the schema, so the baseline 3 applies.

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

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 Ozon catalog") and names the return fields (sku/title/price/rating), so the agent knows this is a keyword-search tool rather than a product-detail lookup. It does not explicitly distinguish itself from siblings like ozon_card or ozon_reviews, so it falls short of a 5.

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

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

Usage is only implied by the tool name and the sibling set; nothing states when to prefer this over ozon_card (single item) or ozon_reviews (reviews). The one genuinely useful usage rule it does give is that zero parsed items is not an error but surfaces a no_items warning with meta.healthy=false, which tells the agent how to interpret an empty result rather than when to call the tool.

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

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

Beyond the read-only/idempotent annotations, it discloses important result semantics: price_cny is None rather than 0 when hidden or variant-priced. It also discloses the Tmall limitation and points to a guide for fields and error codes.

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

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

The description is short and front-loaded: purpose first, then key caveats, then a pointer to the guide. Every sentence adds operational value with no filler.

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

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 and rich annotations, the description supplies the missing operational context: price None handling, platform limitation, and an alternative for Tmall. Nothing essential for correct invocation is absent.

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

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

Schema coverage is already 100% for item_id_or_url, so the baseline is 3. The description adds a meaningful constraint by warning that a Tmall detail URL is not readable by this card, effectively narrowing acceptable URL inputs.

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

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 Taobao item card') and implies the one-item scope. It distinguishes the card from the Tmall/search-row path for Tmall listings, but does not explicitly compare it with the taobao_search sibling for general Taobao use.

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

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

It gives a concrete when-not rule: Tmall detail.tmall.com listings cannot be read and should use the search row instead. It does not spell out the general choice between card lookup and taobao_search discovery, so guidance is clear but not complete.

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