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

Annotations already cover read-only and open-world, but the description adds material context they cannot: default ordering is newest-first, the price is $0.002 in USDC per successful call, payment runs over x402 on Base/Solana/Arc, and failed calls are not charged. That billing-on-success semantics is exactly the kind of trait an agent needs before invoking. Rate limits or result-stability guarantees are absent, keeping it short of 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?

Purpose and country coverage are front-loaded, then field inventory, then sibling routing, then pricing — a sensible order with no filler sentences. The long enumeration of returned fields is somewhat redundant given an output schema exists, which is the main thing keeping it from a 5.

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 paid, multi-country search tool with seven parameters and an output schema, the definition covers purpose, scope, default ordering, billing model, and alternatives — enough to call it correctly. It leaves out freshness/realtime behavior and how paging interacts with the max-1000 offset, but those are secondary.

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 every one of the seven parameters is already documented in the schema. The description adds only the currency context ('price with currency') and the default sort order, both of which the schema already states. Baseline 3 is appropriate since the schema does the heavy lifting.

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 ('OLX classified listings search') plus the exact source ('OLX's public listing API') and the covered country set, so the agent knows precisely what corpus is being queried. It also names what comes back (title, price, city, seller type, promotion flags, total ad count), which further pins down the resource.

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 explicitly routes away from two siblings ('social_carsandbids when you need Live Cars & Bids auctions', 'social_instagram when you need engagement snapshot'), giving clear contrast. What it does not state is a when-not-to-use condition for the OLX case itself, e.g. that countries outside pl/ro/pt/ua/bg/kz/uz are unsupported — that is only inferable from the enumerated list.

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