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

With no annotations, the description carries the burden and does well: it discloses that the call is expensive against Superbuy's rate limit and that it exposes 'lokprijzen' (bait prices) hidden at search level. Missing are auth/permission requirements and any indication of response size or latency, which are relevant for a heavy call.

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 id provenance, then the rate-limit warning last, which is a sensible ordering. The middle clause is dense with comma-separated return fields but each item adds meaning; no filler sentences.

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 re-explained, yet the description still prioritizes the fields that matter for comparison shopping. The rate-limit constraint and id provenance are both covered; permission requirements and error behavior are the only notable gaps.

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% for the single 'id' parameter, so the description must compensate — and it does, specifying the id comes from search() and follows the 'tb:123' pattern. That is enough to construct a valid call, though nothing is said about invalid-id behavior.

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 ('Productdetails van een item'), names the source tool (search()), gives the id format ('tb:123'), and enumerates what is returned (variants, shipping, stock, store scores, warnings), which cleanly separates it from the sibling search tool.

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 constrains usage — 'alleen voor serieuze kandidaten gebruiken' — because of the rate-limit cost, which is actionable selection guidance. It does not positively name alternatives or spell out a full decision tree, but the when-not condition is unambiguous.

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, so the description carries the full burden. It does disclose a useful behavioral trait — price/photo/links are enriched from the cache rather than supplied by the caller — and hints at update-vs-create via session_id, but it never states side effects, whether an existing results page is overwritten, or any permission/auth requirements for a write-like operation.

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 compact per-parameter notes. Slightly dense and telegraphic (mixed inline pseudo-formatting), but no sentence 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?

An output schema exists, so return values need not be explained. Still, for a mutation-style tool with no annotations, the definition omits what happens on republish, whether items replace or merge, and what title/summary are for — gaps an agent would notice at call time.

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 does well for items (field names, verdict enum values, score 0-10, id provenance), request, queries and session_id. However, two of the six parameters — title and summary — get no explanation at all, leaving a clear 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?

The opening sentence states a specific verb and target: publish a curated selection to the results page. Combined with the items/verdict structure it is clear what the tool produces, but it never contrasts itself with siblings like search or details beyond the implicit 'id zoals uit search()' sequencing.

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?

Guidance is implied rather than stated: ids must come from search(), and session_id is 'meegeven om een bestaande sessie bij te werken' (pass to update an existing session). There is no explicit when-to-use/when-not-to-use or precondition statement, so the calling workflow must be inferred.

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 well: it discloses the affiliate/search-engine data source and its noise, the translation side-effect when Chinese terms are used, and the compact line-based output shape. Gaps remain on pagination limits, rate limiting, and failure 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?

Front-loaded with the action and platform options, then the extra/field hint, then the return format. Compact and information-dense, though the multi-line dump reads like terse pseudocode rather than cleanly structured prose.

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 needn't be explained (they are anyway), and the description covers platform choice, keyword language, and the escape hatch for advanced filters. Only the page/pagination parameter and any auth or limit constraints are left unexplained.

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 three of four parameters: platform values and their trade-offs, extra as overflow form fields with a pointer to superbuy_captures(grep='crawler'), and keyword implied via the Chinese-terms note. The page parameter is never mentioned, leaving one 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?

"Zoek op Superbuy" plus an enumeration of the three supported platforms (tb, 1688, xianyu) states a concrete verb and resource with scope. It also references the sibling superbuy_captures for form-field discovery, though it does not distinguish itself from siblings like details or superbuy_fetch.

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 actionable selection guidance: which platform fits which need (tb = noisy affiliate engine, 1688 = better relevance, xianyu = second-hand) and the tip that Chinese keywords work best because translation is skipped. No explicit when-not-to-use or routing to superbuy_fetch/details is provided.

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, and it says nothing about whether this is a pure read, whether it performs an active probe against a live bridge, whether it can fail or time out, or what authorization it needs. A single noun phrase cannot substitute for a safety/behavior profile on an unannotated 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?

It is a single short clause with no waste and the resource is front-loaded, but the brevity is under-specification rather than efficiency — the sentence omits the verb entirely. Also note the description is in Dutch while all sibling tool names are English, which is a minor friction for query matching.

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, but the description does not explain what the tool actually checks, what a healthy vs. unhealthy result implies, or when an agent should call it before or after the superbuy_* tools. For a no-param tool this is nearly adequate, yet still leaves the agent without a reason to invoke it.

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 for the description to disambiguate; baseline 4 applies. The empty schema is self-explanatory.

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?

"Status van bridge en Firefox-extensie" identifies the resources reported on (bridge and Firefox extension) but uses no verb and never says what "status" means here — health check, connection state, version info? It also gives no differentiation from the sibling tools (search, details, publish, etc.), so an agent can only infer this is a diagnostic read.

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 guidance at all on when to call this versus the siblings, no prerequisites, and no indication of what triggers the check or whether calling it has side effects. The agent must guess that this is the first-call smoke test / connectivity probe.

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 behavioral burden and does disclose that traffic was captured passively by the extension and that output shows the request and beginning of the response. However, it omits permissions, whether the operation is read-only, pagination behavior, and how captures are retained.

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 short sentences with no filler, front-loading the resource and source before describing the output. Every phrase contributes to the tool's purpose.

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 need not be explained. Still, with no annotations and 0% schema description coverage, the description should say more about usage boundaries, pagination/limit behavior, and whether this is a safe read operation.

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 explains 'grep' as a URL-regex filter and implies response truncation via 'begin van response', but 'limit' is not addressed and max_chars is only indirectly suggested.

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 ('Toont') and resource ('API-verkeer') and clarifies the source as traffic passively seen by the extension, filtered by a URL-regex grep. It clearly describes a retrieval tool for captured requests and partial responses, though it does not explicitly name a sibling 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?

The description implies a use case (inspecting passively captured API traffic) but gives no explicit guidance on when to choose this over siblings such as superbuy_fetch or search. There are no exclusions, prerequisites, or alternative-selection rules.

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 burden, yet it only discloses the domain restriction. It never says that method/body allow non-GET requests, whether auth/cookies are supplied automatically, whether responses are truncated (max_chars), or how errors surface — all critical for a tool that can mutate state.

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 short sentence with the domain restriction front-loaded and no filler. It is efficiently sized, though the brevity is partly under-specification rather than economy.

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 needn't be explained, but for a five-parameter HTTP tool with zero annotation coverage the description omits too much: write capability, authentication, truncation and error behavior are all unstated. The domain restriction alone is insufficient context to call it safely.

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% across five parameters, and the description only constrains the url host. Nothing explains method defaulting to GET, what body/content_type expect, or that max_chars truncates the returned payload, so the description fails to compensate for the schema 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?

States a specific action (raw fetch) and the resource scope (Superbuy tab, restricted to *.superbuy.com), which separates it from siblings like superbuy_captures, search or details that presumably return structured data. It is clear enough to identify the tool, though 'raw fetch' is never spelled out as an HTTP request.

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?

'voor API-verkenning' (for API exploration) hints at the intended context, so an agent can infer this is the exploratory/low-level option versus the structured siblings. However it names no alternative and gives no when-not conditions, leaving the choice of this tool vs superbuy_captures to inference.

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