Citeerbaar

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld=false, so the safety profile is covered. The description adds genuine non-annotation context: it only searches questions that are visibly answered on the site and returns the answer together with its source page, which tells the agent the knowledge scope is a curated published set rather than free-form retrieval.

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, zero filler: the capability and its scope come first, then the usage condition. Every clause 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 no output schema, the description usefully states what comes back (the answer with its source page). Combined with the annotations and full schema coverage, an agent has enough to call this correctly; only the absence of sibling disambiguation keeps it from being 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 both parameters (question, limit with default 5 and 1-20 range) are fully documented in the schema. The description adds no format hints or query-phrasing guidance beyond that, so the baseline of 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: searching the questions that are visibly answered on citeerbaar.nl, and returning the answer plus its source page. The scope (only published/visible answered questions) meaningfully separates it from generic siblings like search or search_site, though no sibling is named 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?

'Gebruik dit voor concrete vragen over AI-vindbaarheid, GEO, de pakketten of de werkwijze' gives clear topical conditions for use, which is real routing guidance among eleven siblings. It stops short of stating when NOT to use it or naming the alternative (e.g. get_facts, search_site) for related-but-different needs.

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 false, and destructiveHint false, covering the safety profile. The description adds only that the return is the full page text in Markdown format; it does not mention auth requirements, rate limits, or error behavior. With annotations carrying the safety burden, this is adequate but thin → 3.

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 with no waste: the first states the tool's output, the second gives the input instruction and an example. Front-loaded and appropriately sized → 4.

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 tool is simple (one required parameter) and the description, annotations, and output schema together cover what an agent needs to call it: the id source and format. It leaves the distinction from get_page implicit, but for this low-complexity read-only fetch the description is complete enough → 4.

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 id parameter; the schema itself documents 'Het id uit search, oftewel het pad van de pagina.' The description's 'Geef het id dat search teruggaf, bijvoorbeeld /pakketten/scan/' is largely redundant, though the example clarifies the expected format. Baseline 3 is appropriate when 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: returns the full text of a page from citeerbaar.nl as Markdown. However, it does not differentiate from sibling get_page, which also retrieves page content. Clear purpose but no sibling differentiation → 4.

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 tells the agent to use the id returned by search, implying use after search, but gives no explicit when/when-not guidance or comparison to alternatives like get_page. Implied usage only → 3.

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=false, so the safety profile is fully covered. The description adds that the output includes claims paired with their source, a useful content-level detail, but says nothing further about behavior, freshness, or auth needs.

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 that names the resource first and then the contents. The enumeration is long but each item is informative, so little 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 no output schema and no parameters, the description carries the burden of describing the return payload, and it does so by listing the fact categories. For a simple read-only overview tool this is largely sufficient, with only routing guidance 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, which is the baseline-4 case; there is nothing for the description to clarify beyond the schema. No parameter-level gap exists.

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 ('Geeft') and resource ('het feitenoverzicht') and enumerates the exact contents (organisatie, registratienummers, pakketten, garantie, meetplatformen, beweringen met bron), so the agent knows precisely what comes back. It stops short of distinguishing itself from siblings like get_pricing or answer_question, which overlap with 'pakketten' and general facts.

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 statement of when to use this tool versus the many siblings; get_pricing overlaps with 'pakketten' and answer_question could plausibly cover the same ground, yet neither is mentioned. Usage can only be inferred from the enumerated content, and no exclusions or prerequisites are given.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely useful context beyond that: the return format is Markdown and the content is the full page text, which the annotations do not 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?

Two tight sentences with the core behavior front-loaded and the input guidance second. No filler, though the example path could arguably be trimmed.

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 simple single-parameter read tool whose annotations already carry the safety profile, the description covers what the agent needs: input form, output format, and scope. The missing sibling differentiation is a minor gap rather than an incomplete 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 description coverage is 100% with a single documented parameter, so the baseline is 3. The description reinforces the 'URL or path' semantics and adds a concrete example path (/pakketten/scan/), but contributes no syntax 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 states a clear verb and resource: it returns the full text of a single page as Markdown, with the domain (citeerbaar.nl) and scope (one page) specified. This distinguishes it somewhat from multi-result siblings like search, but it does not differentiate from the overlapping 'fetch' or 'search_site' 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?

It explains how to invoke the tool (give the URL or path) but gives no guidance on when to prefer it over the close siblings 'fetch', 'search', or 'search_site'. The agent must infer the selection criteria on its own.

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 closed-world scope, so the safety profile is covered. The description still adds real domain context: the amounts are exclusive of VAT, and it enumerates the secondary data (verrekenregel, terugbetalingsregeling, betaalvoorwaarden) an agent might not expect from a tool named 'get_pricing'.

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 delivering the resource first and the qualifiers second, plus a short caveat sentence about VAT. No filler, no restatement of the title.

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 input parameters and no output schema, the description carries the return-value burden and does so by enumerating every field group returned. An agent knows what it will get and in what currency terms without calling the 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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is closed with additionalProperties=false and needs no elaboration.

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 ('Geeft alle pakketten') and enumerates exactly what comes back: prijs, doorlooptijd, inhoud, verrekenregel, terugbetalingsregeling, betaalvoorwaarden. It is clearly distinguishable from search/lookup siblings, though it never names or contrasts with them.

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 narrow subject matter — an agent can infer this is the pricing/package reference tool. There is no explicit when-to-use, no exclusions, and no routing away from lookup_term or get_facts, which could plausibly also surface pricing-adjacent content.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the tool is gated on a secret token, and guessable/public identifiers are deliberately rejected, which tells the agent this is a privacy-scoped lookup and what to do if it lacks the token.

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 purpose, then the requirement, then the exclusion rationale. Nothing is redundant and the security justification in the final sentence prevents a realistic misuse.

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 one required parameter, no nested objects, and no output schema, the description carries the burden of describing the return content — it does so by naming registration state, arrival time, and check progress — and fully covers the auth prerequisite. Nothing an agent needs in order 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 description coverage is 100% and the single parameter is already documented as the 24-character token from the request response. The description largely restates that and adds only the provenance link to request_quick_check, so the baseline of 3 for high-coverage schemas 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 states a specific verb (report status) plus the exact resource (a previously submitted Quick Check request) and even enumerates what is reported: registration, arrival time, and progress of the automatic check. It is clearly distinguishable from the sibling request_quick_check, which submits rather than queries.

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 names the prerequisite (the 24-character statustoken returned by request_quick_check) and explicitly rules out alternatives that an agent might otherwise try: a reference number or e-mail address gives no access. That is an explicit when-not plus a pointer to the sibling that produces the required token.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context that results are ordered newest-first and include both newly published and updated items, but says nothing about result size or format.

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 compact sentence with the ordering constraint front-loaded at the end. No filler, though it is terse enough to be slightly under-informative rather than maximally efficient.

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 simple, read-only, single-optional-parameter list tool with full annotation coverage and a documented schema, the description covers what an agent needs. The absence of an output schema means return-shape details are unstated, but this is minor for a listing endpoint.

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 'limit' parameter (min 1, max 50, default 10) is fully documented in the schema. The description adds no parameter detail, so the baseline of 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 (geeft) and resource (recent published/updated items on citeerbaar.nl) with a clear scope. It is distinguishable from siblings like search or get_page, though it does not explicitly name any of them.

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?

No guidance on when to use this versus search, search_site, or get_page for discovering content. The 'newest first' ordering implies a recency-checking use case but that is left for the agent to infer.

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 establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description goes further by disclosing what comes back — the definition plus Wikipedia/Wikidata cross-links when available — which is the only source of return-value information since no output schema exists.

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 sentence carrying purpose, data source, and return contents with no padding; the key information is front-loaded in the opening clause.

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 lookup with no output schema, the description adequately covers what the tool does and what it returns (definition plus external identifier links). Minor gaps remain around exact-match vs fuzzy matching behavior, but nothing critical 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% and the single 'term' parameter is documented with concrete examples ("GEO", "llms.txt"). The description adds no format or matching guidance beyond 'een begrip', 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 ('Geeft de definitie') and resource ('een begrip uit de begrippenlijst van citeerbaar.nl'), which clearly identifies a glossary lookup. It is distinguishable from generic siblings like get_facts or search, though it never names or contrasts them 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?

Usage is implied: use it to resolve a term to its glossary definition. There is no when-to-use statement, no exclusion, and no pointer to alternatives such as get_facts or search when a definition is not the desired result.

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?

Despite annotations already declaring openWorldHint, not read-only, not idempotent, and not destructive, the description adds critical operational context beyond them. It discloses the exact data sent (name, email, website URL), the cost (free), the response timeline (email within 2 working days), the human review aspect, the concrete limits (5 per hour per IP, 60 per hour overall), and the 429 Retry-After behavior. That is far richer than the structured hints alone.

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 tightly packed with useful information, front-loading the core purpose before moving to prerequisites, expected outcome, limits, and alternatives. Every sentence earns its place with no redundant filler; the structure is highly efficient.

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 a mutation tool with no output schema, the description covers all essential aspects: required preconditions (user data and consent), the exact information transmitted, the cost, the expected result and turnaround time, rate limits and error handling, and when not to use the tool. It is complete enough for an agent to invoke it correctly without further information.

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 documents all four parameters well, setting the baseline at 3. The description still adds useful semantics by specifying what data is sent to Citeerbaar (name, email, website URL) and by providing consent guidance for the optional 'aanleiding' parameter. It adds enough beyond the schema to merit a 4, though it does not fully elaborate on every parameter's format beyond what the schema provides.

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 specifies a concrete verb and resource in a single clear phrase: submitting a request for the free Citeerbaar Quick Check on behalf of the user. It explicitly distinguishes this from the paid Scan of 295 euro and other siblings by stating it is 'niet de betaalde Scan van 295 euro'. The purpose is unambiguous and can be distinguished from all listed sibling 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?

Explicit when-to-use rules are given: first ask the user for their name, email and website URL and obtain consent, only then call the tool. It also tells when not to use it by naming alternatives, 'Niet geschikt om de verbinding te testen: gebruik daarvoor search of get_facts.' This covers both required preconditions and exclusions with 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 this a safe, idempotent, closed-world read, so the safety profile is covered. The description usefully adds the indexed corpus and the returned fields, but says nothing about result limits, pagination, or ranking 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?

Three short sentences with no waste: scope, return shape, and next step, in that order. Every sentence earns its place and the actionable routing comes last where it is easy to spot.

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 brief mention of returned fields is a bonus rather than a necessity. For a one-parameter read tool this is nearly complete; only the ambiguity against search_site and answer_question keeps it from full marks.

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 with concrete examples ('llms.txt', 'wat kost een scan'). The description adds no syntax, phrase, or matching-semantics detail beyond the schema, so 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 (search) and the exact corpus it covers (public pages, knowledge base articles, packages, cases), plus the shape of each hit (id, title, URL). It does not differentiate itself from the closely-named sibling search_site or from answer_question, which an agent would need to choose between.

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 workflow rule: search first, then retrieve full text via fetch using the returned id. It does not state when to prefer this over search_site, answer_question or lookup_term, so the sibling-selection guidance is incomplete.

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/openWorld=false, so the safety profile is covered. The description adds useful behavior beyond that: which content classes are searched and what each hit contains (title, URL, summary) — valuable since there is no output schema. It says nothing about ranking or pagination, 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?

Three short sentences: scope first, then return shape, then the usage condition. No filler, nothing repeated from the schema, and the most decision-relevant information is front-loaded.

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 tool with full schema coverage and safety annotations, the description supplies the missing pieces: content scope and return fields. Only ranking/pagination behavior is left unstated, a minor gap.

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% — query semantics, example values, and the limit default/max are all documented in the schema. The description adds no additional parameter meaning, 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 gives a specific verb ("Zoek") and enumerates the resource scope precisely: public pages, knowledge-base articles, packages and cases of citeerbaar.nl. It does not, however, name or contrast with the ambiguous sibling "search" or with get_page/fetch, so sibling differentiation is only implied.

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?

"Gebruik dit als je niet weet op welke pagina het antwoord staat" states a clear selection condition and implicitly contrasts with the page-oriented siblings (get_page, fetch), but no alternative is named explicitly and no exclusion is given.

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