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

No annotations exist, so the description must carry the burden. It discloses the fields returned per product, which is a read-only listing operation, but omits rate limits, scraping fragility, error behavior for bad marketplaces/categories, and how many products per request are actually supported.

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 dense sentences, front-loaded with the resource and scope, with no filler. The heavy parenthetical enumeration of examples is slightly list-like but each item earns its place by teaching value formats.

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 listing return fields is somewhat redundant, and the description still leaves max_products semantics, pagination, and error handling undocumented for a 4-parameter tool with zero schema coverage and no annotations. Adequate but with clear holes.

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 0%, so the description must compensate, and it does for 'marketplace' (domain suffix with concrete examples) and 'categories' (URL slugs with examples like electronics, kitchen). However, 'max_products' is never explained and the 'ranking' narrative omits the 'most-wished-for' value present in the enum, leaving gaps.

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 specific resources (Amazon Best Sellers, New Releases, Movers & Shakers rankings), the scope (21 marketplaces), and the returned data shape. An agent can distinguish this from siblings like noon_products (a different retailer) without opening the 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?

Usage is implied (fetch Amazon ranking lists) and the description gives practical formatting guidance for marketplace and category values, but it never states when to prefer this over alternatives or any exclusions/prerequisites. No explicit when/when-not.

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?

With no annotations, the description carries the full burden and does well: it discloses the data source (dubailand.gov.ae), that output is pre-aggregated rather than raw records, the aggregation dimensions, the bilingual naming, and the date format. It omits freshness/data-lag and error behavior for invalid ranges, but the core behavioral profile is clear.

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?

One dense but front-loaded paragraph that leads with the source and scope before listing dimensions and metrics; every clause carries information. The long enumeration of metrics is slightly list-like but not padded.

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 explanation is unnecessary, and the description already names the aggregation keys and metrics. The remaining gap is the unmentioned transaction_type option and data-freshness expectations for a public-data source.

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 0%, so the description must compensate: it clarifies that from_date/to_date are YYYY-MM-DD and define the reporting range, and that results are grouped by sale-vs-resale. However, the transaction_type enum (sales/mortgages/gifts) and its default of 'sales' are never mentioned, leaving one of three parameters semantically undocumented.

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 resource (DLD-registered property transactions), scope (date range), and the exact aggregation grain and metrics returned. Sibling tools are in unrelated domains, so no differentiation is required for the agent to identify this correctly.

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 implies when to use it (needing aggregated Dubai property transaction statistics over a date range) and gives the required date format, but offers no explicit exclusions, caveats about aggregation limits (no per-transaction drilldown), or guidance on choosing values for transaction_type.

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?

No annotations exist, so the description carries the full behavioral burden, and it does disclose the data provenance (COMEX futures plus live FX) and what the returned number represents. That is meaningful. It says nothing about rate limits, caching/freshness guarantees, or failure behavior for unsupported currency codes, which matters for a live-quote tool with zero annotation coverage.

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 sentences, all load-bearing: what it returns, where the numbers come from, and the optional history add-on. The core resource and currency format are front-loaded, and there is no filler or repetition.

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 structure needn't be described, and all three parameters are optional, lowering the risk of a wrong call. Coverage of currency format, units, karats, provenance and history is solid; the only real gap is the semantics of the history_range enum and the default behavior when currencies is omitted.

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 0%, so the description must compensate. It does add real meaning for `currencies` by specifying ISO codes and giving examples (AED, INR, SAR, PKR, USD), and "optional daily history" implies the include_history/history_range pair. It never explains the history_range enum values, the default currency set, or whether multiple currencies return a combined payload, so compensation is partial.

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 a specific resource and scope: live gold and silver prices in any ISO currency, across ounce/gram/kilo/tola/10-gram units and five karat grades. That is far more precise than a title restatement. It does not explicitly differentiate from siblings, but no sibling (jobs, property transactions, product listings, web search) overlaps, so differentiation is moot rather than missing.

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 parenthetical "market price, before jewellers' making charges" is a genuine exclusion that tells the agent this is not retail jewellery pricing, which is the most likely misuse. "Optional daily history" signals when to reach for the history parameters. No explicit when-to-use or alternative tool is named, keeping it below 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?

With no annotations, the description does real work: it discloses the four upstream sources, that duplicates are merged, and that Bayt and GulfTalent are 'best effort' — an important reliability caveat an agent can use to temper confidence. It stops short of disclosing rate limits, latency, or what happens when a source fails entirely.

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 sources, then the return shape, then the caveat — good ordering with no filler. The field enumeration in sentence two partly duplicates the output schema, which costs a little space but aids scanning.

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?

The output schema covers return values, so the description need not explain them. However, for a three-parameter aggregation tool with zero schema descriptions, the lack of any parameter guidance (especially max_jobs_per_source) leaves a meaningful gap an agent must guess at.

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 0% for three parameters. The description implies a country scope ('in a Gulf country') and a keyword search, but never explains what 'keywords' does (all-terms vs any-term, matching fields) or what 'max_jobs_per_source' controls beyond its default of 20 — a volume knob an agent would likely want to tune.

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 a specific resource (current job listings in a Gulf country), the four boards aggregated, and the dedupe behavior, so an agent knows exactly what this tool returns. No sibling overlaps in domain (property transactions, gold price, retail products, web search), so differentiation is implicit but unambiguous.

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 phrase 'in one search', which suggests using this instead of querying each board separately. There is no explicit statement of when to prefer it over the web_search sibling, no note on country coverage limits, and 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?

No annotations are provided, so the description carries the full burden; it does disclose the shape of the result set (title, brand, price, discount, rating, seller, URL), which signals a read-only catalog search. It says nothing about rate limits, data freshness, failure modes, or pagination/result-cap behavior, leaving meaningful gaps for a scraping-backed search tool.

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?

A single front-loaded sentence with the marketplace and geography stated before the field list. The enumerated return fields are somewhat redundant given an output schema exists, but nothing is wasted.

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 spell out return values, and the read-only nature of a search is inferable. However, for a 3-parameter tool with 0% schema coverage and no annotations, the missing guidance on country selection and result limits leaves it only minimally adequate.

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 0%, so the description must compensate. It only hints at the query parameter and lists the three countries that happen to match the country enum, but never explains how country changes results or what max_products (default 20) controls.

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 (search) and resource (Noon marketplace products) and scopes it to three countries, with the returned fields enumerated. It implicitly separates itself from amazon_best_sellers and web_search by naming the marketplace, but never explicitly contrasts 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: 'for a search query' tells the agent this is a keyword product lookup on Noon. There is no statement of when to prefer this over amazon_best_sellers or web_search, and no prerequisites or 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?

With no annotations, the description carries the full load and does it reasonably well: it names the backend (DuckDuckGo), discloses that page text is conditional on fetch_page_content, and that content is trimmed to max_chars_per_page. It omits the behavioral cost of the default — fetching N pages of body text per query is slow and heavy — which an agent choosing parameter values would benefit from knowing.

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, no filler, with the resource and result shape front-loaded before the conditional behavior and the usage rationale. Slightly dense in the first sentence but every clause corresponds to something an agent needs.

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 no explaining, and the description covers the query path, the conditional fetch, and trimming against a 0%-coverage schema. What is missing is cost/latency guidance given fetch_page_content defaults to true — the one decision an agent is most likely to get wrong here.

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 0%, so the description must compensate, and it explains three of the four parameters: query (implicit in "Search the web"), fetch_page_content (page text included only when true), and max_chars_per_page (trimming). max_results is only obliquely covered by "ranked results", so it does not quite earn a 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?

States a specific verb and resource (search the web via DuckDuckGo) plus the exact shape of the result: title, URL, snippet, date, and optional page body as Markdown. The one gap is sibling differentiation — web_to_markdown is clearly adjacent, and nothing in the description tells the agent which to pick for a known URL.

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 it to ground answers in current sources and cite them" gives a real use case, so the usage is implied clearly enough. But there is no when-not and no named alternative — an agent holding a single URL has no signal to route to web_to_markdown instead.

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?

With no annotations, the description carries the burden and delivers substantial context: content cleaning (navigation, ads, cookie banners removed), JavaScript rendering, extracted metadata (title, date, token count), and crawl behavior. It omits auth/rate-limit details, but those are minor for this read-only conversion tool.

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 sentences, front-loaded with the core purpose, followed by behavioral details and crawl guidance. No wasted words; slightly over-specifies output fields that the output schema already covers, but this is minor.

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?

The output schema exists, so return values needn't be described. However, with 0% schema coverage on four parameters, the unexplained max_chars_per_page and missing auth/rate-limit details leave gaps for fully safe 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?

Schema description coverage is 0%, so the description must compensate. It meaningfully explains crawl_site (follow same-domain links) and max_pages (cap on crawled pages), but max_chars_per_page is left unexplained (default 0 is ambiguous) and urls is only implied by the tool name.

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 'Convert' and resource 'web pages to clean, LLM-ready Markdown', with parenthetical clarification of what is removed. Clearly distinct from all siblings, especially web_search which searches rather than converts.

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 implied usage through parameter guidance: 'Set crawl_site to follow same-domain links (capped by max_pages)'. However, it offers no explicit when-to-use versus alternatives (e.g., web_search) and no exclusions or prerequisites.

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