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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description does add genuinely non-obvious auth context: the API key comes from a declared credential reference (env://) and is never a tool argument, which prevents a wasted argument attempt. It says nothing about rate limits, query syntax, 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 short sentences with no filler, and the core purpose is front-loaded ahead of the credential caveat. The docstring-style line breaks are slightly awkward but do not hurt length or ordering.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be explained, and the auth note covers a hidden dependency. Still missing for a search tool: what `query` accepts, how pagination works, and whether results are ranked — all undocumented at 0% schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for all three parameters, so the description carries the full burden and does not meet it. It never explains what `query` matches against, or how `page_size`/`page_number` behave beyond raw defaults.

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 USDA FoodData Central) plus a hint of the result content (nutrient amounts). It is clearly distinct from the taxonomy/GBIF/iNaturalist/weather siblings by resource, though it never explicitly says so.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this over the other search tools, no prerequisites, no exclusions. The only implied usage is 'search food data', which the name already conveys.

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 openWorldHint, so the safety profile is covered. The description adds nothing beyond that: no mention of result volume, pagination behavior, rate limits, or what a call actually returns in the context of a remote open-world 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?

A single efficient sentence with the primary filter front-loaded and no filler. It is appropriately short, though its brevity comes at the cost of the missing details noted elsewhere.

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 the single required parameter is named. However, for a paginated, open-world search endpoint, the absence of any paging or result-size guidance leaves the definition only minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, yet it only restates scientific_name. The limit and offset parameters — critical for controlling result volume and paging — are completely unaddressed, leaving the agent to guess at their semantics beyond defaults.

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 ('GBIF-mediated organism occurrence records') plus the key filter ('scientific name'). It is distinguishable from taxonomy_gbif_search by emphasizing occurrence records rather than taxonomy, though the distinction is only implicit.

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 no guidance on when to use this versus siblings such as taxonomy_gbif_search or inaturalist_observation_search. No exclusions, prerequisites, or conditions are stated; the agent must infer the choice from the name alone.

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 openWorldHint, so the safety profile is covered. The description adds that these are 'community' (crowd-sourced) observations, which is useful context, but it says nothing about pagination behavior or result volume despite page/per_page params.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single efficient sentence with the key information front-loaded. It is appropriately terse, though the terseness contributes to the gaps elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values needn't be explained, but the pagination parameters and the choice against sibling occurrence/taxonomy tools are essential gaps for a search tool with 0% schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the burden, yet it only implies taxon_name's meaning and says nothing about page or per_page. Two of three parameters are left undocumented anywhere.

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 (search) and resource (iNaturalist community observations) with the key filter (taxon name). It is clear what the tool does, though it doesn't explicitly differentiate itself from the sibling gbif_occurrence_search or the taxonomy_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to choose this over gbif_occurrence_search or the taxonomy lookup tools, and no prerequisites or exclusions are mentioned. The agent must infer usage from the name alone.

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 and openWorld, so the safety profile is covered. The description adds genuinely non-derivable context: the API token is resolved from a declared credential reference (`WORLD_REFERENCE_NOAA_TOKEN`, `env://` by default) and is never a tool argument, which prevents an agent from trying to pass auth. It does not mention rate limits, error modes, or pagination termination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short paragraphs, purpose front-loaded, no filler. The credential sentence is somewhat verbose with its backticked env-var names but each sentence conveys needed 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 values need not be explained, and auth is handled. But for a tool with three required string parameters at 0% schema coverage, the description should at minimum pin down station identifier and date formats; without that an agent can easily construct an invalid call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across five parameters, so the description carries the full burden and adds almost nothing. It never states the expected station_id format (e.g. USC00306362) or the date format for start_date/end_date, and limit/offset are only obliquely implied by 'a page'.

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 page of NOAA GHCND daily station observations. It is clear what data comes back, but it offers no differentiation from the nearest sibling, open_meteo_weather_observation, so an agent choosing between weather-observation sources gets no help.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to prefer this source over open_meteo_weather_observation or the other search tools, and no prerequisites or exclusions. The word 'page' hints at pagination but gives no guidance on how to size or walk pages.

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

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

Annotations already establish read-only, open-world, and idempotent behavior. The description adds useful context beyond the annotations by disclosing keyless access, the bounded-window model, and the resumption-cursor pattern.

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 the core operation front-loaded and no wasted wording. The cursor behavior and default window are 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 an output schema and annotations present, return values and safety traits do not need explanation here. The description covers the key invocation pattern, though it could say more about window_days and units or date semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It explains start_date well as a resumption cursor, but leaves latitude, longitude, and window_days to bare schema names and defaults, with only an implicit hint about the bounded window.

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: fetching a bounded window of daily historical weather for one place. The scope is clear, but it does not differentiate itself from the similar noaa_ghcnd_daily sibling.

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 cursor usage: pass the previous call's next_cursor to continue a sweep, or omit start_date to begin about 30 days back. It also notes the tool is keyless, but provides no guidance on when to use this instead of the related NOAA or observation siblings.

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 and openWorld, so safety is covered; the description adds that the upstream is a remote service (EBI OLS4) and that results come one page at a time. It does not disclose rate limits, page ordering, total-count behavior, or what happens with an invalid ontology id — meaningful gaps for a remote paginated read.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action is front-loaded in one sentence and the parameter note follows. The `:data:`world_reference_mcp.config...`` reference is documentation-syntax leakage that means little to an agent, a minor 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?

An output schema is present, so return values need not be described here. Given a simple three-parameter paginated list, the description supplies the action, the upstream, and the ontology id domain — enough to call the tool correctly, with only paging semantics thin.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden and covers only `ontology`, with a concrete value list plus a pointer to the config module. `page` and `size` are left entirely unexplained beyond their schema defaults, so two of three parameters get no semantics from either source.

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: list one page of one OBO ontology's terms, sourced from EBI OLS4. The scope (one ontology, paginated) is explicit and the name is distinctive against the sibling search tools, though it never says how it differs from them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the parameter note enumerates valid ontology ids (go, uberon, envo, pato, chebi, foodon), which tells the agent what to pass but not when to prefer this tool over a search sibling or when to page through results. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds only the notion of a 'backbone' (an authoritative name-resolution source rather than raw occurrences), and says nothing about pagination behavior, result ordering, or how matching/fuzzy name resolution works.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with no filler, which is efficient. However, the brevity is achieved by omission rather than by precision — the size is appropriate but the content is thin for a 4-parameter search tool.

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 the one required parameter is covered. Still missing are rank's accepted values and any mention of limit/offset semantics, which matter for an open-world search that can return many matches.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden but only covers two of four parameters: 'query' (a name) and 'rank'. The 'limit' and 'offset' pagination parameters are never mentioned, and valid rank values are not listed even though the field has no enum.

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 (GBIF taxonomic backbone) with the key filter (rank). Naming GBIF implicitly distinguishes it from taxonomy_ncbi_search, but it never explicitly contrasts the two sibling backbones, leaving the agent to infer which authority to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus taxonomy_ncbi_search, gbif_occurrence_search, or wikidata_alignment_search. The word 'optionally' hints that rank is not required but no conditions, exclusions, or prerequisites are given.

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

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

Goes well beyond the readOnly/openWorld/idempotent annotations by disclosing that modified_since is not applied server-side and that filtering happens in the adapter, plus the exact comparison used. That is exactly the kind of non-obvious behavior an agent cannot get from annotations or 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?

The core purpose and its query example are front-loaded in one sentence, and the caveat follows immediately. Some redundant framing around the 'source-adapter checkpoint contract' could be trimmed, but it earns most of its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values needn't be described, and the tricky modified_since behavior is covered. However, with four parameters at zero schema coverage, the pagination parameters remain unaddressed, leaving a real 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 0%, so the description must compensate. It explains 'term' via example and gives deep semantics for 'modified_since', but retmax and retstart are left completely undocumented in both schema and 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?

States a specific verb and resource ('Search NCBI Taxonomy') and gives a concrete Entrez query example, which distinguishes it from the sibling GBIF search by naming the data source. It stops short of explicitly contrasting with taxonomy_gbif_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?

The example query syntax implies how to use it, but there is no guidance on when to choose this over taxonomy_gbif_search or gbif_occurrence_search, nor any stated prerequisites. 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 already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds that each result names the join key used for entity resolution, which is useful beyond the annotations, but it says nothing about pagination behavior despite limit/offset parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short, but the space is partly spent on internal references that mean nothing to an agent: the :data:`world_reference_mcp.api.wikidata.ENTITY_TYPES` symbol path and the internal code 'EH-032'. The core statement should be front-loaded in plain language instead.

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. Still, for a 3-parameter search tool the description does not clarify what a result actually contains, how the external-id match is performed, or how to page through results, leaving real gaps for 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?

With 0% schema description coverage the description must carry parameter meaning, and it does document the required entity_type with four concrete values that the schema does not enumerate. However, limit and offset are entirely undocumented, including their defaults and any maximum, so compensation is only partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

It names a concrete verb and resource ('List Wikidata items'), but the scope statement 'carrying the external id ``entity_type`` matches on' is convoluted and leaves it unclear whether the search returns Wikidata items, external-id values, or both. The enum values help an agent reason about the domain, but there is no differentiation from the other search siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never states when to choose this tool over taxonomy_ncbi_search, taxonomy_gbif_search, or the other siblings, nor any when-not conditions. The enumerated entity_type values hint at applicability but are not usage guidance.

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