Primary Sources

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real value beyond them: the free/no-key access model, licensing, and an explicit scope boundary (snapshot only, no officers, shareholders or financials). That scope limitation is exactly the kind of negative information an agent 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?

Two tight sentences with the source, access model, lookup modes, return fields and scope limit front-loaded. Every clause carries information and nothing repeats the tool name.

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, yet the description still summarizes them helpfully. Combined with the access model and the explicit exclusion of officers/shareholders/financials, an agent has everything needed to decide and call correctly.

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 already documents uen, name and limit precisely, so the baseline is 3. The description restates the name-vs-exact-UEN distinction but adds no new format, syntax or matching semantics (e.g. partial vs exact match behavior) 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?

States a specific verb (Search) plus resource (Singapore's ACRA corporate-entity registry via data.gov.sg) and enumerates what is returned. An agent can immediately distinguish this from sibling registry tools like companies_house_company or sec_edgar_company by jurisdiction and source.

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?

Explains the two access modes (entity name vs exact UEN) and pre-empts misuse by declaring the data is free, keyless and licence-covered. It does not explicitly name alternative registries for other jurisdictions, but the Singapore scoping makes the selection condition clear enough.

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, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond that: 'free, no key' signals no auth needed, and it discloses return fields (titles, abstracts, authors, dates, PDF links). Solid but not exhaustive.

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: purpose first, then return contents, then routing guidance. 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?

For a two-parameter search tool with full schema coverage, complete annotations, and an output schema, the definition covers everything an agent needs to select and invoke it correctly. Listing return fields is mildly redundant against the output schema but not harmful.

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 both parameters documented (query syntax examples, limit range). The description adds no parameter-level meaning beyond the schema, 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 (Search) and resource (arXiv preprints) plus the domain scope. It explicitly distinguishes itself from the sibling pubmed_search, so an agent can route 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?

Gives both the when-to-use condition (preprints in physics, math, CS and related fields) and the explicit alternative (use pubmed_search for biomedical literature). Nothing is left to inference.

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, openWorld, idempotent and non-destructive, so the safety profile is covered. The description adds a genuinely useful operational fact not in the annotations: it is free and requires no API key, and it enumerates the exact portal domains. It could still mention rate limits or result pagination, so it stops 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 tight sentences, front-loaded with what the tool does, then constraining details, then the alternative. Every sentence carries information and none is 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?

Given an output schema exists, the description need not explain returns, yet it still briefly summarizes them. Combined with the auth note, portal enumeration and sibling routing, an agent has everything needed to call it correctly.

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 every parameter (query, rows, portal) is already documented in the schema with defaults and limits. The description only restates the portals and names their domains (data.gov.uk/data.gov.au), a marginal addition over the enum, so 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 and resource (search a national CKAN open-data portal), names supported portals (uk/au), and explicitly distinguishes itself from the sibling hk_open_data_search. An agent can route between the CKAN and Hong Kong tools 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?

Gives both the positive condition ('use for government datasets by country') and the exclusion/alternative ('use hk_open_data_search for Hong Kong'). Nothing about tool selection is left to inference.

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 needs no restating. The description adds one genuinely useful behavioral fact beyond that — no API key required — but says nothing about rate limits, pagination across the 100-result cap, or result freshness.

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, front-loaded sentences with no filler; purpose leads and usage follows. The enumeration of return fields is somewhat redundant given an output schema exists, which keeps it just below 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 two-parameter search tool with an output schema and full annotation coverage, the description supplies everything needed to invoke it correctly: source, auth requirement, and use case. Only explicit sibling routing and pagination/rate-limit notes are 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%, so both parameters (query, limit) are already documented with examples and a default/max. The description adds no additional syntax guidance, so the baseline 3 for schema-driven parameters 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 and resource ("Search ClinicalTrials.gov studies") and names the exact registry, which cleanly separates it from the many literature siblings such as pubmed_search, europepmc_search and semantic_scholar_works. The return contents (NCT ids, brief titles, status, start date, study URLs) further pin down what an agent gets back.

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 for registered clinical trial records" gives a clear selection context, and "(free, no key)" signals it is safe to call without credentials. It does not explicitly name an alternative (e.g. pubmed_search for journal articles) or state when not to use it, so it stops short of full routing guidance.

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 real operational context beyond them: the COMPANIES_HOUSE_API_KEY requirement (auth) and that a free key suffices, which an agent needs before calling.

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 resource, then the return shape, then sequencing. Minor redundancy: the key requirement is stated twice ('requires COMPANIES_HOUSE_API_KEY' and 'Free key required'), which is a small waste of an otherwise tight three-sentence block.

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 spelled out, and the annotations cover the safety profile. The description still supplies the auth requirement and the search-then-fetch workflow, leaving nothing an agent needs in order to invoke it correctly.

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 fully documented with an example (09446231), so the schema carries the load. The description adds only the phrase 'by company number', which restates the schema rather than adding syntax or format nuance. 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 (Fetch) and resource (one UK company record) with an explicit identifying key (company number). It is clearly distinguishable from the sibling companies_house_search, which lists rather than fetches a single entity.

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 names the prerequisite/sequencing: 'Use after companies_house_search', which routes the agent from search to detail. It stops short of stating when NOT to use it or naming any alternative detail source, so it is clear context rather than full when/when-not guidance.

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, open-world, so the safety profile is covered. The description adds genuinely useful context beyond them: it requires a COMPANIES_HOUSE_API_KEY and states that a free key suffices, which is auth guidance an agent needs before calling. It does not cover rate limits or result caps, 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 dense, front-loaded sentences with the core purpose first. Slightly marred by redundancy: the API key requirement is stated twice ('requires COMPANIES_HOUSE_API_KEY' and 'Free key required').

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, yet the description still usefully summarizes the returned fields (company number, status, type, address, URL). Combined with auth requirements and sibling routing, nothing needed to invoke 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?

Only one parameter with 100% schema description coverage ('Company name or partial name'). The description's 'by name' adds nothing beyond the schema, 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 (Search) and resource (UK Companies House register by name), and explicitly distinguishes itself from the sibling companies_house_company. An agent can select it 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?

Names the condition ('Use for UK entity existence/status') and the explicit alternative for the other case ('use companies_house_company to fetch one record by number'). This is a textbook when-to-use/when-to-use-something-else instruction.

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 readOnly/openWorld/idempotent/non-destructive, so the safety profile is handled. The description adds genuinely useful context the annotations do not carry: 'free, no key' (auth requirement) and the shape of the return (DOIs with title, authors, publication date, container, URL). It does not mention rate limits or pagination behavior, keeping it out of the top band.

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 waste: capability and return shape first, routing second. 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 an output schema present, the description needn't detail return values, and it is complete for selecting and invoking the tool. Minor gap: no note on result limits/rate behavior beyond the schema's rows cap, but nothing essential 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% — both query and rows are documented in the schema with defaults and max. The description adds no syntax, format, or query-construction guidance beyond that, 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+resource (search Crossref for scholarly works) and immediately names the sibling it competes with (openalex_works). An agent can distinguish it from the many other bibliographic tools in the sibling list 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?

Explicitly routes: 'Use for DOI/citation metadata discovery; use openalex_works for citation counts and richer metadata.' Both the when and the when-not are stated with a named alternative.

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, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new operational context with 'free, no key' (no auth/API-key requirement), which is not derivable from the annotations.

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 clauses: what it searches, what it returns, and how to route. Purpose and the sibling alternative are front-loaded with 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 structure need not be detailed, yet the description still previews the key fields. For a simple two-parameter search tool, purpose, auth model, and sibling routing are all covered.

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%, including limit bounds ('max 100') and a query example, so the schema carries the parameter burden. The description adds only an implicit sense of free-text querying and 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?

States a specific verb and resource ('Search DataCite for research-data DOIs') and immediately scopes it to datasets rather than articles. It also names the exact sibling to use for articles, so an agent can disambiguate 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?

Explicitly gives the use case ('find citable datasets and their metadata') and routes the competing case to an alternative ('use crossref_works for articles'). The when-to-use and when-to-use-something-else conditions are both present.

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 safety is covered. The description adds value the annotations cannot: 'free, no key' tells the agent no credentials are needed, which is genuine invocation-relevant context. It stops short of rate-limit or pagination behavior, so not 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: purpose first, then output fields, then the routing rule. Zero filler and the disambiguation is placed where the agent will see it.

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, return values need not be detailed, yet the description still previews them. Purpose, auth requirement, and sibling disambiguation together cover everything needed to call this correctly.

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 (query, limit) are already documented in-schema with defaults and max. The description adds no additional parameter semantics, 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 and resource ('Search the data.europa.eu EU open-data catalogue') and adds scope detail (EU-wide open datasets) that separates it from the other catalogue siblings. The listed return fields (identifiers, titles, descriptions, countries) further pin down what the tool is for.

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 names the selection condition ('Use for EU-wide open datasets') and routes the agent to the alternative ('use ckan_search for UK/Australia'), which matches a real sibling in the tool list. An agent can choose without opening either schema.

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, openWorld, non-destructive), so the bar is lower. The description adds genuinely useful context not in annotations: 'free, no key' discloses the auth requirement, and it notes the return contents (codes, names, dimensions, values).

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 action and scope. The provider list is informative rather than padding, though it is slightly verbose.

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 and full parameter coverage, the description only needs to handle routing and context, which it does well. Complete enough for an agent to call correctly, with minor room to name alternative tools for single-provider cases.

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 five parameters including defaults and limits. The description restates 'provider and dataset codes plus an optional query' without adding format details beyond what the schema provides, 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 resource (series in a DBnomics dataset) and immediately names the scope. The 'single entry point for multi-provider macro data' framing distinguishes it from single-provider siblings like fred_series, ecb_series, and world_bank_indicator.

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 clear context for use ('single entry point for multi-provider macro data') and explains the multi-provider aggregation rationale. It stops short of explicitly naming the sibling tools to use instead for single-provider queries, so no full when-not guidance.

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, covering the safety profile. The description adds useful auth context ('free, no key') and a return-field summary, but omits rate limits, pagination behavior, or result ordering.

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 front-loaded sentences with no filler; the first two carry the essential purpose and return shape. The final sentence partially restates the OA/permissive scope already implied, a minor redundancy.

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, full parameter descriptions, and rich annotations, the description covers what the agent needs to select and call the tool. It could mention pagination or result limits, 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%, so both parameters (query, limit) are fully documented in the schema. The description adds no syntax or semantic detail beyond that, making the baseline 3 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?

Names a specific resource (Directory of Open Access Journals) and action (search), and scopes the output to OA articles with permissive reuse. It is distinguishable from general scholarly search tools by its OA-only focus, though it does not explicitly name siblings like openalex_works or crossref_works.

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?

Provides a usage cue ('Use for OA scholarly articles with permissive reuse') but does not state when not to use it or name alternative tools for paywalled/general scholarly search. The context is implied rather than enumerated.

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 genuinely useful context beyond that: 'free, no key' (auth not required) and 'bounded in size' (result cap). It stops short of naming rate limits or the exact bound, hence a 4.

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, front-loaded with the action and format, then guidance and the sibling alternative. Every clause carries information; nothing is 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 needn't detail return values, and it usefully notes the SDMX header/datasets shape. The 'bounded in size' claim is vague (no concrete cap or pagination note), which is the only remaining 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%, so all three parameters (flow, key, lastNObservations) are documented in the schema with examples and defaults. The description only restates 'Provide an ECB flow and key' and adds no syntax or format detail beyond that; 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?

Specific verb+resource: fetches an ECB Data Portal time series in SDMX-JSON. It states the required inputs (flow, key) and names the sibling it is not (dbnomics_series), so an agent can distinguish it 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: 'Use for euro-area monetary/financial series; use dbnomics_series for other providers.' This gives both the when-to-use condition and the named alternative.

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 and non-destructive, so the safety profile is covered. The description adds genuinely new context: no API key is required and the tool is free, plus it enumerates the returned fields (PMIDs, DOIs, titles, journals, years, authors).

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, and the scope/coverage claim is front-loaded before the sibling comparison. Nothing redundant.

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-value detail is not required, and the description covers auth (no key), scope, and sibling routing. What remains thin is query syntax guidance and pagination semantics, which is a minor gap for a search 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?

Schema description coverage is 100%, with both query and limit (default 10, max 100) documented inline plus a query example. The description adds no parameter-level syntax or format guidance beyond the schema, 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 (Search) and resource (Europe PMC life-science literature) and immediately names the sibling it overlaps with, pubmed_search. An agent can distinguish the two without inspecting 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?

Explicitly frames the tool as an alternative/complement to pubmed_search and gives a reason to prefer it (Europe PMC's broader indexing). It stops short of stating when NOT to use it or which sibling wins in a tie, but the routing signal is clear.

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, open-world, non-destructive behavior. The description adds genuinely useful context beyond them: the FRED_API_KEY requirement and that observations are returned newest first, which is a real behavioral trait. It stops short of discussing rate limits or error 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, front-loaded with the core action and return format, followed by routing and the auth prerequisite. 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?

With an output schema present and rich annotations, the description only needs to add the auth requirement, ordering, and sibling routing — all of which it does. Nothing an agent needs to invoke this 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 both parameters (seriesId with examples, limit with default) are documented in the schema itself. The description adds no parameter-level meaning, 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 (Fetch) and resource (observations for a St. Louis Fed FRED economic series), and names the scope of the data. It explicitly contrasts with world_bank_indicator, letting an agent distinguish it from a sibling 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?

Gives clear usage context ('US and international economic time series (rates, CPI, GDP)') and an explicit alternative with its selection condition (world_bank_indicator for cross-country development data). It does not address other overlapping siblings like dbnomics_series or ecb_series, so routing is clear but not exhaustive.

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/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful non-annotation context: the service is "free, no key," which tells the agent no auth setup is needed. It omits rate limits or pagination behavior, so not 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 with zero filler: identity, return payload, and use case, in that order. Nothing is repeated from the schema and the purpose 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 read-only, open-world search with an output schema present, the description covers purpose, returns, auth posture and use case. The only modest gap is fuzzy-match behavior and result handling, which the output schema partly absorbs.

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 (query, limit) are documented in the schema, including the default and cap of 100. The description adds no syntax or format detail 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 (Search) and a precise resource (the GBIF taxonomic backbone), then enumerates the returned fields (scientific names, canonical names, rank, status, kingdom). No sibling covers biodiversity/species taxonomy, so the agent can confidently route here.

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 for biodiversity/species name resolution" gives a clear intended context, and the lack of near-alternatives in the sibling list makes this sufficient. It stops short of stating exclusions (e.g., occurrence records vs. taxonomy) or a fallback when no match is found.

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, openWorld, idempotent and non-destructive, so the safety profile is covered. The description adds useful auth context ('free, no key') and notes the two return shapes (article list vs. volume timeline) beyond the annotation set, though it omits rate-limit or pagination 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 sentences, front-loaded with purpose and return shape, then the sibling routing. Every clause earns its place with no redundancy.

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 a rich annotation set, 100% schema coverage, and an output schema that handles return values, the description covers what remains: purpose, return modes, auth note, and sibling disambiguation. Nothing an agent needs 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 coverage is 100%, so all four parameters are documented in the schema itself. The description only lightly reflects the mode parameter ('or a volume timeline') and adds no syntax or format detail beyond what the schema provides, so the 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 (Search) and resource (GDELT DOC 2.0 global news), and explicitly contrasts itself with the sibling hn_search for tech-community discussion. An agent can distinguish it from other news/search siblings 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?

Gives explicit usage scenarios ('news-volume trends and cross-outlet coverage') and names an alternative tool with the condition that selects it ('use hn_search for tech-community discussion'). Nothing is left to inference for tool selection.

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 genuinely new operational context: it is free, requires no API key, and data is CC0 — relevant for auth and licensing decisions. It also enumerates returned fields, which is helpful though partly redundant with the output schema.

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 dense sentences that front-load the resource and access model before the mode and return details. No wasted clauses, though the trailing field enumeration is slightly redundant given an output schema exists.

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?

Covers identity, access conditions, both call modes, and expected fields for a zero-required-param lookup tool. Since an output schema exists, the return-value listing is a bonus rather than a necessity, and nothing an agent needs to invoke it correctly appears to be 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 all three parameters are documented there, including LEI precedence over legalName and the limit default/max. The description restates the two lookup modes but adds no syntax, format, or constraint detail beyond the schema, 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 and resource ('Look up Legal Entity Identifier (LEI) records from GLEIF') and explicitly covers both operating modes: name search and exact LEI fetch. An agent can distinguish this from sibling entity tools like sec_edgar_company or companies_house_company without opening any 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?

Provides purpose context ('Use to identify legal entities and ownership/issuer identifiers across jurisdictions') which implies when it's relevant, but names no alternatives or exclusions despite many sibling tools covering entity/company data. Usage is suggested rather than routed.

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 and non-destructive. The description adds genuinely new context beyond that: the service is free and requires no API key, and it enumerates the returned fields. No pagination/rate-limit detail, but meaningful added value over the annotations.

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 capability statement is front-loaded and the usage hint follows. Slight redundancy between the return-fields list and the output schema, but no wasted 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?

For a simple two-parameter search tool with full schema coverage and an output schema, the description covers source, cost/access model, and return contents. The main omission is disambiguation from other book/text search tools.

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 parameters (query and limit) are already documented with examples and bounds in the schema. The description adds nothing about parameter semantics, 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 and resource ("Search Project Gutenberg's public-domain catalogue via Gutendex") and names the intermediary API, which lets an agent distinguish it from generic book-search siblings. It stops short of explicitly contrasting with overlapping tools like open_library_search or internet_archive_search.

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 to find free public-domain texts and their formats" implies the use case but gives no when-not guidance and names no alternative tool. Usage is inferable rather than explicit.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the description is free to add operational detail instead. It discloses that no API key is required ('free, no key'), the resolution step, the titleSearch servlet, and that each result carries a direct PDF link. It does not mention rate limits or pagination, which keeps 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?

Front-loaded with the core action and key attributes ('free, no key') before moving to resolution mechanics and sibling routing. Three sentences, all earning their place; the category enumeration is the only part that could be trimmed or moved.

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 6-param read-only search tool with full schema coverage, annotations, and an output schema, the description covers domain, resolution path, output shape ('metadata plus a direct PDF link'), and sibling differentiation. Nothing an agent needs 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 coverage is 100%, so the schema already documents all six parameters including defaults and the stockCode format. The description adds category-code meaning ('10000 Announcements, 20000 Circulars, 40000 Financial Statements/ESG…'), which is genuinely useful context beyond the schema's 'e.g. 10000 or 40000'. Baseline 3 is appropriate given 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?

The description gives a specific verb and resource ('List Hong Kong listed-company announcements from HKEXnews'), explains the resolution mechanism (5-digit code or company name to internal stockId, titleSearch servlet), and explicitly distinguishes itself from the sibling sec_edgar_fulltext ('use sec_edgar_fulltext for US filings'). An agent can select it immediately.

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 states the intended domain ('HKEX/SEHK primary disclosures') and names the alternative for the adjacent use case (US filings), providing explicit when-to-use and when-to-use-something-else guidance. The category code list also tells the agent which categories exist for filtering.

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, so safety is covered. The description adds genuinely useful context beyond that: 'free, no key' plus exactly what is returned (stockId, code, name, filings URL, headline category taxonomy, 25 recent filings) and the 25-item recency bound.

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 purpose before return values and the routing alternative. 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?

An output schema exists, yet the description still communicates scope (25 most recent), the resolve-then-drill workflow, and the sibling boundary. For a one-parameter lookup tool this is fully sufficient.

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% for the single stockCode parameter, including examples ('00700 or Tencent'), so the schema does the heavy lifting. The description adds no syntax or format detail beyond it; 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: 'Resolve a Hong Kong listed company and show its recent HKEXnews filings.' It even names the sibling it is not (hkex_announcements), so the agent can distinguish it without opening schemas.

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 states when to use it ('identify/resolve an HK issuer before drilling into a filing') and names the alternative plus the condition that selects it ('use hkex_announcements to filter by date or category'). Nothing is left to inference.

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 and non-destructive, so the safety profile is covered. The description adds genuinely new context that annotations cannot express: the API is free and requires no key, which affects how the agent should handle auth failures. It does not discuss rate limits or error 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 compact sentences, zero filler, with the core action and the routing alternative both front-loaded. 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 needn't explain return values, and it notes the response is JSON. Annotations plus schema plus the no-key note cover most of what an agent needs; only edge-case behavior (invalid paths, rate limits) is unaddressed.

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 (path, params) are already documented with an example path. The description restates that a path must be passed but adds no format, encoding, or query-parameter syntax beyond the schema. Baseline 3 applies when the schema carries the load.

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 (call) and resource (Hong Kong Monetary Authority public API) and names the data scope (monetary, banking, market statistics as JSON). It explicitly differentiates itself from world_bank_indicator, so an agent can route 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?

Gives clear context ('Use for HK monetary/liquidity data') and names an alternative with the condition that selects it ('use world_bank_indicator for development indicators'). Lacks explicit when-not-to-use guidance beyond that single contrast, but the routing signal 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and idempotency profile is covered. The description adds the 'free, no key' auth context, which is useful. Beyond that it doesn't disclose error behavior, filter operator semantics, or pagination mechanics, so with annotations carrying the load this is a fair 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?

Three tight sentences: purpose with scoping, parameter source and format, and intended use. No repetition or filler; every sentence 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 a read-only, idempotent, open-world query tool that has an output schema, the description covers purpose, the required parameter's source, and the filter format. What's missing is operator vocabulary for filters and any note on paging (the `section` parameter is undocumented in text), but the output schema and annotations reduce the burden.

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 all three parameters are documented in the schema. The description restates the filter triple format ([column, operator, values]) already present in the schema. It adds the workflow origin of `resource` (from hk_open_data_search), which is marginal value beyond the schema's own 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 states a specific verb (Query) and resource (a DATA.GOV.HK dataset resource) with explicit scoping to structured filters. It names its sibling hk_open_data_search as the source of the required `resource` parameter, letting an agent place it in the workflow 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?

It provides clear context: use to extract rows from a specific HK dataset, and explicitly points back to hk_open_data_search for the resource URL. It also notes 'free, no key' removing auth friction. It lacks an explicit when-not-to-use (e.g., when a dataset has no filterable columns), but the intended context is clear.

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/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds non-obvious operational context — free, no API key required — and enumerates the returned fields. It does not mention rate limits or pagination behavior, so it falls 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 clauses with zero waste: what it is, what it returns, and when to prefer the sibling. Scoping information is front-loaded and the routing hint comes last.

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-value explanation is optional and the brief field list is a bonus. Coverage of source, cost, return shape, and the alternative tool is sufficient for an agent to call this correctly.

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 parameters (query, rows) are already documented with examples and defaults in the schema. The description adds no parameter-level detail beyond that, making the baseline 3 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 (Search) and resource (Hong Kong government open-data catalogue DATA.GOV.HK) and names the sibling it is not (hk_open_data_filter). An agent can distinguish it from the ~48 other search tools 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 gives both sides: use this to discover HK datasets, use hk_open_data_filter to query a resource. The condition that selects the alternative is stated, not 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond annotations: it states the service is 'free, no key' (no auth needed) and lists returned fields and sorting behavior. It does not mention rate limits or pagination, but the output schema reduces that burden.

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 tightly written sentences with no filler. The purpose and return fields are front-loaded, followed immediately by the sibling routing guidance, making every sentence earn 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 annotations covering safety and an output schema present, the description needs only to state purpose, usage, and routing. It does all three, plus notes that no API key is required, leaving no critical gap for correct 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 100%, so the schema already documents all four parameters including the sort enum and limit bounds. The description reinforces 'sorted by relevance or date' and implicitly references stories/comments, but it adds no syntax or format details 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 states a specific verb and resource: 'Search Hacker News stories and comments via Algolia'. It also explicitly distinguishes itself from a sibling by naming gdelt_news for mainstream news coverage, so an agent can route between them 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 description gives explicit when-to-use guidance ('Use for tech-community signal and discussion') and names the alternative with its own use case ('use gdelt_news for mainstream news coverage'). This is a clear routing rule rather than vague implied usage.

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 safety is covered. The description adds context annotations cannot express: 'free, no key' discloses the authentication requirement, and the enumerated return fields set expectations for output shape. No rate-limit or pagination-behavior detail is given.

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 core action and immediately followed by return values and use cases. Every sentence carries information; there is no filler or repetition of structured fields.

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 low-complexity two-parameter search tool, the definition covers purpose, source scope, content types, return fields, and the no-key/free access model, while annotations carry the safety profile and an output schema exists for return detail. Nothing needed to invoke 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 schema already documents both 'query' (with an example) and 'limit' (default 10, max 100). The description adds nothing beyond that, so the baseline of 3 applies for a fully schema-documented parameter set.

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 Internet Archive') and enumerates what is returned: identifiers, titles, years, creators, media types with item URLs. This clearly separates it from sibling search tools like arxiv_search, pubmed_search, or open_library_search by source and content scope.

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 for public-domain texts, audio, video and archived web materials' gives clear positive context for selecting this tool over domain-specific siblings. However, it names no explicit exclusions or alternative tools for cases where another archive/database would be better.

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 carry readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds genuinely new context: free tier with no key, and a concrete output cap of 40,000 characters, which the agent cannot infer from annotations.

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 tightly packed sentences with zero filler. The core action is front-loaded, the fallback guidance follows, and the output-length caveat is appended efficiently.

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-value detail is unnecessary, and annotations cover the safety profile. The description complements these with the 40k character limit and no-key access, though it could note any failure modes for unreachable or JS-heavy pages.

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?

Only one parameter with 100% schema description coverage ('Absolute URL to read, e.g. https://example.com'), so the schema carries the semantics. The description adds nothing about the url parameter beyond what the schema already documents; 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 (fetch) plus resource (any URL as clean markdown) and names the mechanism (Jina Reader). The 'free tier, no key' detail lets an agent distinguish it from the many structured-data siblings 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?

Explicitly frames usage as 'an extraction fallback when a page is not available as structured data,' which routes the agent away from the structured siblings when data is missing. It stops short of naming a specific alternative tool, so it's clear context rather than a full when/when-not/alternative breakdown.

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 and non-destructive, so the safety profile is covered. The description adds genuinely non-structured context: the registry is 'free, no key' (no auth setup required) and it enumerates what the results contain. It does not discuss pagination or result limits beyond the schema default.

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: what it searches, what it returns, when to use it. Front-loaded with the action and resource, no filler, nothing repeated.

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 (2 optional params), an output schema exists so return values need not be explained, and annotations cover safety. The description still covers source, cost/auth, and return shape – more than sufficient for correct 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 100% (both 'limit' and 'query' are documented in-schema, with an example). The description adds nothing about parameter behavior, so the baseline of 3 applies – the schema does all the parameter work.

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 a specific resource (the official MCP Registry for installable MCP servers), and names the scope constraint (installable servers). It is immediately distinguishable from every sibling, all of which query unrelated data sources.

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 states the use case: 'Use to discover MCP servers by capability.' That gives a clear trigger condition. It stops short of naming when not to use it or pointing at an alternative, but no sibling competes for this job, so the omission is minor.

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 cover read-only, idempotent, open-world, and non-destructive hints. The description adds valuable context about authentication and rate-limiting ('free; uses NASA_API_KEY or the shared DEMO_KEY which is heavily rate-limited'), which is not in the annotations. It also mentions return fields, though output schema exists. Missing details like error handling or caching 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 front-loaded sentences that are dense with useful information and contain no wasted words. Authentication, rate limit, return fields, and use case are all stated efficiently.

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 only 2 optional parameters, full schema coverage, and an output schema, the description is nearly complete. It covers purpose, auth, rate limit, and return fields. Minor gap: no mention of pagination or date range limits, but these may not apply given the simple parameter set.

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% and descriptions for date and count are clear. The tool description adds no parameter-specific semantics beyond what the schema already provides, so 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 ('Fetch NASA Astronomy Picture of the Day entries') and clarifies the returned content ('date, title, explanation and media URL'). It clearly distinguishes itself from siblings like arxiv_search or wikimedia_pageviews by naming the exact dataset and use case.

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?

Provides clear context ('Use for NASA APOD imagery and captions') and notes authentication ('free; uses NASA_API_KEY or the shared DEMO_KEY which is heavily rate-limited'). However, it does not explicitly state when to avoid this tool or list alternatives for astronomical imagery, though none are obvious in the sibling list.

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=true, idempotent=true, openWorld=true and destructive=false, so the safety profile is covered. The description adds genuinely new operational context: free/no-key, a required valid User-Agent, and a 1 request/second rate cap. The User-Agent requirement is slightly awkward since no header parameter exists, but the rate limit is valuable disclosure.

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?

Compact and front-loaded: purpose first, then constraints, then return shape, then usage cue. Only mild redundancy in listing return fields when an output schema exists. Zero 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?

With an output schema present the return values need not be enumerated, and the annotations carry the safety profile, so the remaining need is operational context - which the rate-limit/no-key note supplies. Only gap is that the User-Agent requirement offers no actionable path for the agent.

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% - both query and limit are documented with defaults and examples in the schema itself. The description restates that a place/address is geocoded but adds no syntax, format, or limit semantics beyond the schema, 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 (geocode) and resource (place name) and names the exact provider, OpenStreetMap Nominatim. Among a sibling set of mostly data-search tools, there is no overlapping geocoder, so the purpose is 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?

"Use for address/place coordinates" gives a clear positive trigger for when to reach for this tool. It does not name an alternative or an exclusion condition, but no sibling overlaps this capability, so guidance is effectively complete.

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 (readOnlyHint, idempotent, openWorld, non-destructive), so the bar is lower. The description adds non-annotation context: it's free, requires no key, and uses the polite pool, which tells the agent about rate/access behavior not encoded anywhere else. It doesn't mention throttling specifics or pagination, keeping it a notch below top marks.

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 clauses with zero waste, front-loading the action and access model before the sibling-routing note. 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?

An output schema exists, so return-value explanation isn't needed, and the description still summarizes key result fields. Combined with full annotation coverage and a complete schema, it's nearly self-sufficient; only minor operational details (pagination, rate limits) are absent.

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 parameters (query, limit) are fully documented in the schema including the default and max for limit. The description adds no parameter syntax or format detail, so baseline 3 is correct when the schema does all the work.

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 ('Search OpenAlex scholarly works') and enumerates the returned fields (titles, years, DOIs, citation counts, authors). It also explicitly distinguishes itself from a sibling ('use crossref_works for canonical DOI metadata'), so the agent can separate it from the many scholarly-search siblings 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?

Gives explicit routing: 'Use for literature discovery and citation signal' and names the alternative (crossref_works) with the condition that selects it (canonical DOI metadata). This is exactly the when-to-use/when-to-use-something-else guidance the dimension asks for.

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 and non-destructive, so the safety profile is covered. The description adds a genuinely useful behavioral fact not in structured data: "free, no key" (access/auth requirement). It stops short of rate limits or result-size/pagination behavior, which matters for a public API.

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, front-loaded with the action and resource, then returns, then usage. Every clause 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 explained yet are helpfully summarized; access cost ("free, no key") is disclosed. The remaining gap is operational detail (rate limits, pagination/caps beyond the schema's max 100) for a high-volume public API.

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 (limit, query) are documented in the schema, including a syntax example. The description adds no parameter-level meaning 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: query openFDA drug adverse-event reports, and even names the source (FDA FAERS). It also lists the returned fields, which makes the scope unambiguous against siblings like pubchem_compound or clinicaltrials_study. It never explicitly names an alternative tool, so it falls short of 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?

"Use for pharmacovigilance signals from the FDA FAERS data" gives a clear use context, but there is no when-not guidance and no named alternative for overlapping queries (e.g., drug identity vs. adverse events). Usage is implied rather than routed.

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 and non-destructive, so the safety profile is covered. The description adds meaningful context beyond that: 'free, no key' tells the agent no authentication is required, which is not in the annotations. The list of returned fields is useful but partly redundant with the existing output schema, keeping this 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?

Two sentences, both front-loaded: capability and return shape first, then the sibling routing. No filler and nothing buried.

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 two-parameter read-only search with an output schema present, the description covers purpose, auth cost, return shape, and alternative routing. 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%, so both parameters (query, limit with default/max) are already documented in the schema. The description adds no syntax, format, or example detail beyond that, 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+resource ('Search Open Library for books') plus the data returned (titles, authors, first-publish year, ISBNs, URLs). It explicitly differentiates from the sibling gutendex_books, so an agent can route between them 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?

Gives explicit when-to-use ('bibliographic/book metadata') and a named alternative with its own condition ('use gutendex_books for full public-domain texts'). That is the when/when-not/alternative triad in a single sentence.

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 read-only, idempotent, open-world safety profile, so the description's addition of 'free, no key' supplies genuinely new auth context an agent needs. It also previews the returned fields, though an output schema exists so that part is redundant rather than harmful.

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 with the core purpose front-loaded, then the return payload, then the disambiguation. Nothing is wasted or buried.

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 point-weather fetch with a full output schema and rich annotations, the description covers purpose, auth model, and routing adequately. Nothing an agent needs in order to invoke 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%, so all four parameters are already documented in the schema. The description only refers generally to 'a coordinate' and the default variables, adding no syntax or format detail beyond the structured fields. 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 (Fetch) and resource (current weather) with the data source named (Open-Meteo), and it explicitly distinguishes itself from usgs_earthquakes. An agent can identify the tool's function 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?

Gives clear usage context ('use for point weather data') and names an alternative, usgs_earthquakes. However the alternative named is a seismic-events tool rather than a competing weather source, so the routing guidance is somewhat shallow, and no explicit when-not-to-use conditions are stated.

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/openWorld/idempotent/non-destructive, so safety is covered. The description adds genuine value beyond them by noting the API is 'free, no key,' which is auth/access context an agent needs. It stops short of mentioning rate limits or not-found behavior, so it doesn't reach 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?

Two compact sentences, front-loaded with what the tool is and where the data comes from, followed by the return payload and usage scope. No filler or repetition of the tool name.

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 an output schema present, the description is sufficient — return values need not be explained, and the listed fields are a helpful preview rather than a necessity. Only the lack of any sibling differentiation keeps it from being fully 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 coverage is 100% for the single 'name' parameter, so the schema already carries the semantics and baseline is 3. The description adds nothing about accepted identifier forms (synonyms, CAS numbers, formulas) that would help beyond 'name, e.g. aspirin'.

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 ('look up'), a specific resource ('chemical compound'), and the backing source ('PubChem'), then enumerates the returned fields. An agent can distinguish this from openfda_drug or wikidata_search without opening any 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 closing sentence 'Use for chemical/compound reference data' gives implied usage scope, but the description never names alternatives (e.g. openfda_drug for FDA drug labeling) or states when-not to use it. Adequate but leaves routing entirely to inference.

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/openWorld/idempotent, so the safety profile is covered. The description adds real operational context beyond that: the service is free, an optional NCBI_API_KEY raises rate limits, and the call performs a resolve-then-fetch sequence. It stops short of stating concrete rate-limit thresholds or 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?

Three sentences, zero filler, and the purpose is front-loaded before the routing guidance. Every clause carries information 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?

For a two-parameter read-only search with full schema coverage and an output schema, nothing an agent needs to invoke it correctly is missing: purpose, cost/auth model, execution shape, and sibling routing are all present.

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 parameters (query syntax example, limit default 10 / max 50) are fully documented in the schema. The description adds no parameter-level detail, 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 and resource ('Search PubMed biomedical literature via NCBI E-utilities') and discloses the two-stage mechanism (resolve PMIDs, then fetch summaries). It explicitly differentiates itself from the two most confusable siblings, arxiv_search and europepmc_search.

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 when-to-use ('biomedical/clinical citations') and names the alternatives with the condition that selects each: arxiv_search for preprints, europepmc_search for a European mirror with full-text links. Routing 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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description still adds real behavior: it is free and keyless, it resolves tickers through EDGAR company_tickers.json, and it caps results at the 25 most recent filings. It does not cover error behavior for an unknown ticker, which keeps it off 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 tight sentences: identity/returns first, then the resolution mechanism, then the routing rule. Every clause earns its place and nothing is buried.

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?

A one-parameter lookup with rich annotations and an output schema; the description needn't detail return shapes, and it already names the returned fields and the sibling route. Nothing required for correct invocation 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 fully documented ('Ticker or CIK, e.g. AAPL or 320193'), so the schema carries the semantics. The description only restates the same alternative, adding no format or edge-case detail. Baseline 3 for near-zero marginal value.

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 ('US SEC registrant profile plus recent filings') with the exact input key (ticker or CIK), and explicitly names the sibling it is not: sec_edgar_fulltext. An agent can distinguish it from the other company-lookup siblings without opening any 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?

Gives an explicit selection rule ('Use when you know the ticker or CIK') plus the alternative for the opposite case ('use sec_edgar_fulltext for phrase search'). When-to-use and when-to-use-something-else are both covered.

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 and non-destructive, so the safety profile is covered. The description adds genuinely new context beyond that: it is free with no key required, which matters for an agent deciding whether it can call it. It does not mention rate limits, but for a well-annotated read-only search this is a solid disclosure.

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 tightly written sentences, front-loaded with purpose, then capability, then routing. Every sentence earns its place and none repeats structured data.

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 covering return values, full parameter coverage, and rich annotations, the description supplies exactly the extra context needed: cost/auth ('free, no key') and sibling routing. Nothing required to select or call the tool 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%, so all three parameters (query, forms, dateRange) are already documented in the schema. The description adds no syntax or format detail beyond it, so the 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?

The description states a specific verb and resource ('Full-text search US SEC EDGAR filings') plus the index searched, and explicitly distinguishes itself from the sibling 'sec_edgar_company'. An agent can identify the tool's function and scope 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?

It gives the exact usage condition ('when you have a phrase or company name but not a ticker') and names the alternative with its own condition ('For a known ticker or CIK, prefer sec_edgar_company'). This is explicit routing with no inference required.

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?

Goes well beyond the annotations (readOnly/idempotent/openWorld) by disclosing the keyless rate-limit profile, the concrete HTTP 429 failure mode, the retry remedy, and the option to supply a key. This is exactly the operational context an agent needs before invoking a flaky network 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?

Front-loaded with purpose and followed by auth/rate-limit, return, and usage notes in that order. The em-dash parenthetical is somewhat dense but each sentence carries actionable 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 an output schema covering return fields and annotations covering the safety profile, the description supplies the remaining essentials: scope, citation-count rationale, and rate-limit behavior. Nothing needed 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%, so 'query' and 'limit' (default 10, max 100) are already fully documented. The description adds no parameter-level detail, 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+resource (search Semantic Scholar papers) and flags the distinguishing attribute 'citation counts'. The closing 'Use when citation counts matter' implicitly separates it from citation-less siblings like arxiv_search, but 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?

'Use when citation counts matter' gives a clear selection condition, and the rate-limit note tells the agent when to supply a key. It stops short of naming alternatives or stating when NOT to use this over crossref_works/openalex_works.

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, and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond annotations: the API is free and needs no key, and it returns records for a fiscal-service endpoint. It does not mention rate limits or pagination 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 tight sentences, front-loaded with what the tool is, then what it returns, then how to invoke it. No filler; each sentence carries distinct 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 a 100%-covered schema, rich annotations, and an existing output schema, the description need not define return values or safety. It supplies enough for correct invocation (endpoint + filter, no key needed). Minor gaps: no guidance on which endpoint paths exist beyond the default example.

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 endpoint, filter, and limit. The description restates that an endpoint path and optional OData filter are provided but adds no syntax or format detail beyond the schema's own example. 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 and resource — querying the US Treasury Fiscal Data API — and clarifies the domain (US federal fiscal/accounting primary data). It is easily distinguishable from financial siblings like fred_series or ecb_series by resource, though it does not name any sibling 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?

"Use for US federal fiscal/accounting primary data" gives clear usage context, and the sentence about providing an endpoint path plus optional OData filter tells the agent how to drive it. It stops short of naming alternatives or stating when NOT to use it (e.g. vs. fred_series for other US data).

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 and non-destructive behavior. The description adds genuinely useful operational context beyond that: it is a free, key-less 'preview endpoint', which warns the agent that results may be a limited subset rather than the full UN Comtrade dataset. It does not discuss rate limits or result truncation specifics, but the preview caveat is real value.

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, front-loaded with the verb and resource, with the access caveat and usage note following. No filler or redundancy; every sentence 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?

An output schema exists, so return-value explanation is unnecessary, and the description still conveys access model, data scope, and intended use. The main omissions are the meaning of the 'preview' limitation and the defaults (limit 20, cmdCode TOTAL, flowCode X), which rest on the schema.

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 five parameters (limit, period, cmdCode, flowCode, reporterCode) in detail. The description only loosely reinforces these by mentioning annual periods, commodity code, reporter, and import/export flows; it adds no syntax or format detail the schema lacks. 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 and resource ('Fetch UN Comtrade annual trade data for a reporter') and names the return content ('import/export records by commodity code'). It is clearly distinguishable from generic search siblings, though it does not explicitly contrast itself with adjacent statistical tools like un_sdg or world_bank_indicator.

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 for official bilateral merchandise-trade statistics' gives an implied usage context, and 'free, no key' hints at when it is convenient. But there is no when-not guidance and no reference to an alternative tool for trade data, leaving the agent to infer boundaries itself.

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 readOnly, openWorld, idempotent and non-destructive, so the safety profile is set. The description adds genuinely useful context beyond that: 'free, no key' communicates the auth requirement, and the conditional series behavior tells the agent what each call shape returns.

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 with no filler; the resource and auth note are front-loaded, the dual-mode behavior follows, and the usage scope closes. 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?

An output schema exists so return values need no explanation, and the description covers auth, mode-switching, and domain scope for a simple read-only tool. Minor gaps remain — e.g., no hint on where to obtain valid series codes or how results are paginated beyond the limit.

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. The description adds value by explaining that the 'series' parameter switches the tool between catalogue listing and data retrieval, and that 'query' filters the catalogue — context not spelled out in the schema itself.

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 (UN Sustainable Development Goal indicators) and describes the dual-mode behavior (catalogue listing vs series data). It is clear what the tool does, though it does not explicitly name or differentiate from sibling indicator tools like world_bank_indicator or who_gho.

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 conditional guidance: no series code means list/filter the catalogue, a series code returns that series' data. 'Use for official UN SDG statistics' scopes the domain, but no alternative sibling tool is named for comparison.

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 and non-destructive. The description adds genuinely new operational context — the source is free and requires no API key — which is exactly the kind of auth/access fact annotations don't carry. It stops short of covering rate limits or default date windows.

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 capability front-loaded followed by the return payload and the intended use. Nothing is wasted, though the return-field list mildly overlaps the output 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?

Output schema exists so return values need no prose, all three params are documented, and annotations cover the safety profile. What remains thin is query ergonomics — no mention of sort order, default time window, or result ceilings beyond the schema's max 500.

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% (limit, startTime, minMagnitude all documented with defaults and format). The description adds no parameter syntax or interaction detail, so the schema carries the full burden; 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 (Query) and resource (USGS earthquake catalogue) and enumerates what comes back (magnitude, place, time, coordinates, event URL). No sibling covers seismic events, so an agent can route to it unambiguously.

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 for seismic-event primary data" implies the intended context but gives no when-not guidance, no alternatives, and no indication of how broad/global the query is. Usage is inferable rather than stated.

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 and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: it is free, needs no key, and returns validity plus registered trader name and address. It omits operational caveats like VIES availability/rate limits, keeping it out of the top score.

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 action and source front-loaded, followed by the usage boundary. Every clause carries information; nothing is redundant.

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 detailed, and the description still sketches them (validity, name, address). Combined with annotations and a fully documented two-parameter schema, an agent has enough to invoke it correctly; only external-service caveats (outages, rate limits) are 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 both parameters carry clear examples (e.g. '6388047V', 'IE'), so the schema does the heavy lifting. The description adds no parameter-level detail such as format constraints or case sensitivity, 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 (validate) and resource (EU VAT number) and names the authoritative source (European Commission VIES service). It is clearly distinguishable from company-register siblings like gleif_lei or companies_house_company.

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 use case ('verify an EU business VAT identity') plus an explicit exclusion ('not a full company register'), which helps route the agent away from it for broader company data. It does not, however, name the specific sibling to use instead (e.g., gleif_lei), so it stops short of full alternative routing.

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 still adds meaningful operational context that annotations cannot convey: the source is free and requires no API key, which lowers the barrier to invocation.

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 what the tool queries, followed by the mode explanation and a usage note. Efficient and free of filler, though the opening clause and the closing usage sentence partially overlap in intent.

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-shape explanation is unnecessary, and all three optional parameters are documented in the schema. The description covers both invocation modes and the no-key access model, leaving only minor gaps like pagination or result-volume expectations.

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 each parameter (limit, query, indicator) already carries its own explanation and format hints. The description restates the indicator-code retrieval behavior but adds no syntax or default detail beyond the schema, 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 and resource (query the WHO Global Health Observatory) and explains the two operating modes: list/filter indicators, or pass an indicator code to retrieve data values. This cleanly distinguishes it from statistics siblings such as world_bank_indicator and un_sdg.

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 clear context with 'Use for official global health statistics', and the dual-mode sentence tells the agent which mode to pick based on whether an indicator code is known. It names no explicit alternative or exclusion (e.g., when to prefer world_bank_indicator), so it stops short 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, open-world and non-destructive, so the safety profile is covered. The description adds real operational value on top by disclosing that the source is free, requires no API key, and is CC0-licensed, which matters for credential and licensing decisions. It omits rate limits and pagination/truncation behavior beyond the schema's max of 50.

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 action and resource, then the return contract, then the use case. Zero filler, and 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?

An output schema exists, so return-value structure need not be explained, yet the description still summarizes the key returned fields. With full schema coverage, an unambiguous purpose, license/auth context, and a stated use case, the agent has everything needed to select and call this three-parameter tool correctly.

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, limit (default 10, max 50) and language (default en) are all documented in the schema with defaults and bounds. The description adds no parameter-level detail such as language-code format or what a broad/narrow query text yields, so this is the baseline 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 and resource ('Search Wikidata entities by label') and names the return shape (Q-IDs with labels, descriptions, entity URLs). It is immediately distinguishable from siblings like wikipedia_summary or wikimedia_pageviews.

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 to resolve people, organizations, places and concepts to stable identifiers' gives a clear task context and tells the agent what class of problem this solves. It does not, however, name an alternative tool or state when a different sibling (e.g., wikipedia_summary) should be preferred, so it falls short 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 readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context the annotations cannot: the data is free, needs no key, and is CC0-licensed, which tells the agent there is no auth or cost concern. Rate limits and quota behavior are not mentioned.

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, both load-bearing: the first states the verb and licensing/auth posture, the second states the return shape and the motivating use case. No filler, and the critical point (what it fetches) 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. The only shortfall is the claim of 'daily' counts when the granularity parameter also supports monthly, a minor imprecision rather than a real 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%, so all seven parameters are already documented with defaults. The description restates the date-range and project/article concept but adds no format, enum or default detail beyond the schema, 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 and resource — 'Fetch Wikimedia pageview metrics for an article' — and specifies the returned data shape (daily view counts between two dates for a project/article). It is clearly distinct from wikipedia_summary by resource, but never names a sibling tool to route against.

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 to gauge public attention or topic momentum' gives one positive use case, so usage is implied rather than spelled out. There is no when-not guidance and no mention of the sibling wikipedia_summary, so an agent must infer the boundary 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds meaningful context beyond annotations: it is free with no key required, and the content is CC BY-SA with attribution required, which an agent should know when reusing output.

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, front-loaded with the purpose and licensing caveat, then the return contents and usage note. 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?

With a full output schema and rich annotations, the description needn't explain return values, yet it still signals the return shape and licensing. Nothing an agent needs to invoke this 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% with two well-documented parameters (title with example, language with default), so the schema does the heavy lifting. The description adds no parameter-level detail beyond what the schema provides, matching the baseline 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?

Specific verb+resource: 'Fetch a Wikipedia article summary' clearly identifies the action and data source. It is easily distinguishable from siblings like wikidata_search and wikimedia_pageviews by resource, though it does not name those alternatives 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?

'Use for a quick encyclopedic overview and to bridge to Wikidata' gives clear positive context for when to reach for this tool. There is no explicit statement of when NOT to use it or which sibling to prefer instead, so it stops short 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuine context beyond them: "free, no key" tells the agent no authentication/credential setup is required. It does not discuss caching, rate limits or freshness, which is minor for static reference data.

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. The purpose and returned fields come first, and the disambiguation from the sibling tool is placed at the end — well front-loaded and appropriately sized.

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; the description still sketches them briefly. With one well-documented required param, rich annotations and a clear sibling disambiguation, an agent has everything needed to call this correctly.

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 already documents accepted formats (ISO2/ISO3 or World Bank id, with examples). The description adds no syntax or format detail beyond the schema, 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 and resource ("look up country reference metadata from the World Bank") and enumerates the returned fields (ISO codes, name, region, income level, lending type, capital/lat-long). It also explicitly contrasts itself with the sibling world_bank_indicator, so an agent can distinguish them without opening schemas.

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 for canonical country/region metadata; use world_bank_indicator for time-series indicators" gives an explicit when-to-use plus a named alternative with the condition that selects it. Nothing is left to inference.

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 and non-destructive, so safety is covered. The description adds genuinely useful context beyond them: the source requires no API key ('free, no key') and the return format is year/value observations. It stops short of mentioning pagination behavior despite a perPage parameter, so it is not fully rich.

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 action and resource, then the return shape, then the routing rule. Every sentence carries distinct information with no waste.

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 a fully documented schema, an output schema, and annotations covering the safety profile, the description only needed to add purpose, auth context, and sibling routing — all of which it does. An agent has everything required to call it correctly.

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 all four parameters (date range, ISO country code, perPage, indicator code) are already documented. The description reinforces scope ('for one country', 'an indicator such as GDP or population') but adds no syntax or format detail beyond the schema. 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 and resource ('Fetch a World Bank development-indicator time series for one country') plus the shape of the result ('year/value observations'). It also names the sibling fred_series as the contrasting tool, so an agent can distinguish them 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?

Explicitly says when to use it ('long-run country macro data') and names the alternative plus the condition that selects it ('use fred_series for US/global economic series'). Nothing is left to inference.

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 readOnly, idempotent, openWorld. The description adds that no key is required, but says nothing about pagination, rate limits, result ordering, or how the 100-record cap interacts with paging. For a search tool with an output schema, it adds little beyond the annotations.

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, front-loaded with what it searches, then return fields, then use cases. 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 explained, and annotations cover the safety profile. However, the description omits pagination behavior, sorting, and any routing hint among the many similar scholarly-search siblings, leaving real gaps for a tool in a crowded field.

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 fully documented in the schema. The description adds no syntax, operators, or format guidance 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 resource (Zenodo research outputs), plus names the concrete record types (datasets, software, papers). It does not differentiate from siblings like datacite_dois, crossref_works, or openalex_works, but the purpose is unambiguously clear.

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 useful context ('deposited in Zenodo', 'free, no key'), which implies when to use it, but never states when to prefer a different sibling repository or when not to use it. Usage is implied, not explicit.

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