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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds real behavioral content beyond them: counts are live, results are ordered biggest-first, and output shape varies by mode. It stops short of noting combination behavior (e.g. query plus category) or rate/latency characteristics.

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 sentences, front-loaded with the resource, then the mode-to-argument mapping. No filler, no repetition of the title or schema.

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 2-parameter read-only browser with a full output schema, the description covers all primary invocation paths and need not explain return fields. The only gap is the undefined interaction when query and category are supplied together, which an agent might reasonably attempt.

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 both parameters are already documented and the baseline would be 3. The description goes further by tying each parameter (or its absence) to a distinct result mode and stating the sort order for the query case, which is meaning the schema itself does not convey.

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 concrete resource (999.md category tree with live ad counts) and spells out three operating modes keyed to the arguments supplied. It is clearly distinct from search/ad-lookup siblings, though it never names an alternative tool, which keeps it short of the top mark.

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 explicit trigger conditions: no arguments for top-level categories, a category for its subcategories, a query to find where matching ads live. It does not say when NOT to use it or route the agent to search/get_filters instead, so it lacks the exclusion/alternative half of 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 declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds real beyond-schema insight: photo links are text only and the media must be fetched via another tool. It does not disclose rate limits or auth requirements, but nothing is contradicted.

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 returned payload is front-loaded in the first sentence and the important caveat about photos comes last. The comma-separated enumeration of fields is slightly list-heavy, but every clause carries information and there is 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?

With an output schema present, the description does not need to restate return values, and the safety profile is handled by annotations. The remaining need for an agent is knowing what the tool yields and how to actually view photos, both of which are addressed.

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 'ad' parameter already documents both accepted forms (numeric id or 999.md link). The description adds no further parameter meaning, so the baseline of 3 for a well-documented single-parameter schema 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 (get) plus resource (ad) and enumerates the payload it returns: description, characteristics, amenities, exact location with coordinates, seller contacts, media links and dates. It also distinguishes itself from the sibling 'photos' tool, so an agent can separate the two without opening a 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?

Explicitly routes the agent to the alternative for image viewing ('to actually look at the photos use the photos tool'), which is the most likely confusion point. It does not give broader when-to-use guidance relative to 'search' or 'seller_ads', so it falls short of full when/when-not coverage.

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, so the safety profile is covered. The description adds real domain behavior beyond that: the shape of returned filters, the three kind semantics, and the dependency rule that forces a follow-up call to get_options. It doesn't mention pagination or max_options truncation 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?

Three compact lines, front-loaded with the primary deliverable, then the kind mechanics, then the dependency caveat. Every sentence carries distinct information 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?

An output schema exists, so the description is not obligated to document return values, yet it supplies the domain conventions (kind variants, depends_on_feature) that an agent needs to interpret them and chain into get_options. Complete for its complexity, with only minor omissions like truncation 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?

Schema description coverage is 100%, so both inputs (category, max_options) are already documented in the schema and the description adds nothing about them. The field names discussed (option_ids, feature_id, min/max, unit) are output-side concepts, not input parameters, so per the baseline this is a 3.

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 — filters available in a subcategory — and names the concrete payload (feature ids and option ids) the agent will retrieve. It also distinguishes itself from the sibling get_options by calling out dependent features (city after region, model after brand), so an agent can route correctly without opening either 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?

The kind='options'/'range'/'flag' breakdown explains how each returned filter variant is consumed, and the depends_on_feature note routes the agent to get_options. It stops short of stating when to call get_filters versus categories or search in the first place, but the guidance present is concrete and actionable.

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 the safety profile is covered. The description adds the genuinely useful trait that the feature is 'typically a dependent one', warning the agent that results are scoped by a parent selection, but says nothing about result volume, pagination, or empty-result behavior.

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, no filler, with the core concept and the downstream usage front-loaded. Slightly terse given it omits the query parameter entirely, but 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?

With an output schema present, the description need not explain return values, and annotations carry the safety profile. It supplies the one thing structured fields lack — the dependent/hierarchical nature of the options — leaving only minor gaps around result sizing and the query filter.

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 schema itself carries rich examples (feature_id 590 = phone model, parent_option_id 12900 = Chișinău mun.). The description's hierarchy framing reinforces the parent/child relationship behind parent_option_id but adds no syntax or format detail beyond 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?

The description names the resource ('options of one feature') and conveys the retrieval action, with concrete examples (cities of a region, sectors of a city, models of a brand) that make the concept unambiguous. It separates itself reasonably from flat-search siblings, though it never names an alternative explicitly.

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 one actionable usage directive — 'Use the returned ids in search filters' — which implies this is a lookup/enumeration step feeding other tools. However, it never states when to prefer get_options over get_filters or search, nor any exclusions or prerequisites.

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 only cover the read-only/idempotent safety profile; the description adds the expensive bits they can't: ~550 vs ~1500 tokens per image, images persisting in conversation context, and the paging strategy. This is exactly the context an agent needs before an irreversible context-cost commitment.

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 'EXPENSIVE' and its cost figures, then conditions, then paging advice. Dense but every sentence carries actionable content; the multi-clause second sentence runs long without losing 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?

With no output schema, the description fully covers what comes back (images, resolution, token footprint, persistence) plus selection and paging behavior. An agent has everything needed to call this correctly and sparingly.

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 genuine strategy beyond the schema: page with offset rather than raising limit, and reserve full_resolution for explicit quality requests or unreadable detail. Only the ad-id format is left entirely to 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?

States a specific verb and resource: returns the ad's photos as viewable images, at two resolution/token tiers. It is clearly distinguishable from get_ad, which it names as the text-based alternative.

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?

Explicit when-to-use triggers (renovation/condition, body damage, what is being sold), an explicit when-not (not for every ad of a search page), and a workflow rule (pick 1-3 finalists first). Rival tool get_ad is named as the thing to prefer when text suffices.

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 (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real value by disclosing that this is 999.md's own estimate rather than a computed figure, and warns that min/max/average are skewed by mistyped prices — a behavioral caveat not present in any structured field.

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, the output contents stated first and the median-preference caveat second. Every sentence earns its place 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?

An output schema exists, so return values need not be described. The description is complete enough for a read-only stats tool, though it omits any pointer to how options map to get_filters and gives no usage context against siblings.

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 67% and the schema itself explains category, options (with get_filters/filter narrowing) and currency. The description adds no parameter-level meaning, so it neither compensates for the coverage gap nor extends the schema. 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 ('999.md's own price estimate over matching ads') and enumerates exactly what is returned: median, average, min, max and sample size. An agent can immediately tell this is a statistical aggregation tool, distinct from siblings like search or get_ad which return individual listings.

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 offers analytical guidance ('Prefer the median') but no operational when-to-use guidance: it never says when to call price_stats instead of search, or what prerequisites (e.g. category/options) are needed. The one alternative it hints at is a statistical measure, not a sibling 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful return-shape context (ad card fields, total count, paging info), though an output schema exists and duplicates much of that. Nothing is contradicted.

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 sentences, front-loaded with the verb and resource, followed by the return contents. Every clause carries information; 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?

With 9 optional params and an output schema, the definition covers the essentials: what is searched and what comes back, including paging. Minor gaps remain around sorting semantics and the dependency on get_filters for filter ids, but the schema compensates for most of 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?

Schema description coverage is 78%, so the schema largely documents parameters on its own. The description mentions text, category and filters but adds no syntax, default, or interactive guidance beyond what the schema already states, so the baseline 3 is correct.

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 ('Search 999.md ads') and enumerates the search dimensions (text, category, filters), which maps cleanly onto the query/category/filters params. It stops short of differentiating itself from siblings like seller_ads or get_ad, so it lands below 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 implied by the purpose statement, but there is no explicit when-to-use guidance and no routing to alternatives such as get_ad for a single listing or get_filters for obtaining filter ids. The agent must infer the tool's place in the workflow.

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, destructiveHint=false and openWorldHint, so the safety and mutation profile is fully covered elsewhere. The description adds only the shape of the payload (profile fields + active ads), with nothing about pagination behavior or how many ads come back.

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 filler, and the payload contents are front-loaded ahead of the use case. It is appropriately sized for a simple lookup 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 explained, and the description covers what data arrives. However, for a tool with a free-text ad search and limit/offset paging, the description never mentions pagination or how the query parameter scopes results, and it never positions itself against siblings.

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 only 50%: login and query are documented in the schema, while limit and offset carry no description anywhere. The prose says nothing about parameters, so the pagination controls are left entirely to convention with no compensation from the description.

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 names the resource precisely — a seller's profile (registered since, verified, business plan) plus their active ads — which is far more informative than the bare tool name. It lacks an explicit verb and never differentiates itself from siblings like get_ad or search, which is the only thing separating it 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?

'Handy to tell a private person from an agency or reseller' gives one concrete intended use, so usage is implied rather than absent. There is no guidance on when to prefer this over get_ad or search, and no exclusions or preconditions are stated.

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