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

With no annotations, the description carries the full behavioral burden. It does disclose the return shape ('a list of matching name suggestions') and illustrates matching behavior with the 'prim' -> 'primates', 'primatiformes' example, which usefully implies prefix-style matching. It omits whether the call is read-only, any result limits, and matching/case semantics, which the schema only hints at.

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 waste: purpose first, usage context second, output and concrete example last. Every sentence contributes and nothing is 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?

No output schema and no annotations exist, so the description must cover the return value, which it does with a concrete example. For a simple single-parameter autocomplete this is nearly sufficient; only edge details like result caps or case handling 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?

There is one parameter with 100% schema description coverage, so the schema already documents 'query' fully, including the lower-case recommendation and examples. The description's example pairs an input with sample outputs, adding minor value but 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 ('Get autocomplete suggestions for taxonomic names') with the input modality (partial text) and the output (list of matching name suggestions). It also distinguishes its use case from the heavier sibling search_taxa by framing it as something to do 'before doing a full 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 a clear context for use: discovering available taxa in PhyloPic before a full search. However, it never names search_taxa as the alternative or states when autocomplete is the wrong choice (e.g., exact lookups or large result sets), so the routing guidance is implied 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?

No annotations are provided, so the description carries the full burden. It discloses the kinds of information returned and that the tool is for status/discovery, but it does not explicitly confirm that the operation is read-only, describe the response shape, or mention any auth/rate-limit behavior. For a zero-parameter informational getter this is adequate but not complete.

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 definition is two tight sentences, front-loading what the tool returns before giving its intended use. Every sentence adds relevant information without repetition.

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

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

With no parameters, no annotations, and no output schema, the description needs to explain what the tool returns and why to call it. It does both by listing build number, API version, and endpoints, though it could more explicitly state that the call has no side effects.

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

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

The tool has zero parameters, so parameter semantics are not applicable and the baseline is 4. The description correctly does not introduce parameter details that would be irrelevant.

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 uses a specific verb and resource ('Get general information about the PhyloPic API') and enumerates the returned fields (build number, API version, resource endpoints). It clearly distinguishes this metadata tool from the sibling data-retrieval tools such as search_taxa or get_image.

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 a clear usage context: checking API status and discovering available endpoints. It does not explicitly state when not to use it or name alternatives like ping, but the implied scope is unambiguous.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the return fields (name, image count, creation date, contact info if available), which is genuine value with no output schema present, but it omits read-only confirmation, auth/permission needs, and error behavior for invalid UUIDs.

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 retrieval scope front-loaded and the return contents following. No filler; slightly under-uses the space that could clarify sibling routing.

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 read tool with no annotations or output schema, the description covers the essence and, importantly, summarizes the return payload. Only missing explicit sibling routing and read-only confirmation keeps it from being complete.

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

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

Schema coverage is 100%, so the uuid parameter (including format, pattern, and an example) is already fully documented in the schema. The description only restates 'by their UUID' and adds no format or edge-case guidance beyond it, 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 ('Get detailed information about a specific PhyloPic contributor by their UUID'), which is clear. The singular 'contributor' implicitly contrasts with the 'list_contributors' sibling, but no explicit differentiation is offered.

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 use case (fetch one contributor by UUID) is implied but there is no explicit when-to-use guidance and no mention of the alternative list_contributors for enumerating many. Usage must be inferred from the singular phrasing.

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

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

No annotations are provided, so the description must carry behavioral context. It clearly implies a read-style operation and describes returned fields plus optional embeds, but it does not mention authentication, error behavior for missing UUIDs, or rate limits.

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 efficient sentences: the first states the core operation and identifier, the second describes the return contents and optional embeds. Nothing is padded 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?

With no output schema, the description usefully enumerates the key return fields and file format links, and it explains the optional embedding behavior. It is nearly complete, with only error/not-found behavior left 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 description coverage is 100%, so all five parameters are already documented in the schema. The description mentions the optional embed behavior for contributor, nodes, and lineage, but adds little beyond the schema's own parameter descriptions.

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: get detailed information about a specific silhouette image by UUID. It also summarizes the return payload, distinguishing it from search/list sibling tools such as search_images_by_node and list_images_by_contributor.

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 UUID requirement gives clear context for when to use this tool: when fetching one known image rather than searching. It does not explicitly route agents to sibling search tools for discovering a UUID, nor does it state when not to use this tool.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the response contents (names, parent node, primary image, child nodes) and the optional embedding behavior, which is useful. It says nothing about permissions, behavior on an unknown/invalid UUID, or whether child nodes are returned in full or partial form.

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 lookup semantics before the return contents and optional embeds. Slightly redundant in naming 'primary image' twice (as a default return and as an optional embed), but 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?

There is no output schema, so the description must describe the return shape, and it does so adequately for a simple read tool. Remaining gaps are minor: no error/not-found behavior and no clarity on how the default return differs from the embedded variants.

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 already documented in the schema, including the UUID format and the defaults for both embed flags. The description restates the embed options without adding format, cost, or size implications, 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 and resource ('Get detailed information about a specific phylogenetic node by its UUID') and enumerates what the node contains. It clearly distinguishes a UUID-keyed lookup from the search-style siblings, but it never names get_node_lineage or get_root_node, which are the closest alternatives an agent must choose between.

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

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

The UUID requirement implies the usage context (you already have a node identifier), which is a form of implied guidance. However, there is no explicit when-to-use/when-not guidance and no routing to alternatives such as get_node_lineage for ancestry or get_root_node for the tree root.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the return shape (a list from the immediate parent to the root), which is genuinely useful, but it omits permissions, error behavior for an invalid/nonexistent UUID, and whether the queried node itself is included in the list.

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 operation and immediately followed by the return shape. The closing 'useful for...' sentence is mild filler but does supply context, so it mostly 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?

For a simple one-parameter read tool with no output schema, the description covers the core return semantics. It leaves gaps an agent might care about: the size/pagination of the lineage list for deep trees and the fields present on each returned node.

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 uuid parameter is fully documented in the schema. The description adds no format, constraint, or semantic detail beyond 'for a given phylogenetic node', 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 and resource ('Get the ancestral lineage... for a given phylogenetic node') and defines the result precisely as a parent chain up to the root. This implicitly distinguishes it from sibling get_node (single node) and get_root_node, but never names those siblings explicitly, so the differentiation is left to inference.

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?

'Useful for understanding the taxonomic classification of an organism' gives a purpose but no when-to-use vs alternatives guidance and no exclusions. An agent must infer on its own that get_node should be used when only the node itself is needed, or search_taxa when starting from a name.

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

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

No annotations are provided, so the description carries the full burden. It discloses one meaningful behavioral trait — that primary image data can optionally be embedded — but says nothing about authentication, rate limits, response shape, or whether the root node is stable/cached.

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 zero wasted words. The middle sentence about the tree of life is lightly redundant with the parenthetical but serves as useful conceptual grounding.

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 zero-required-parameter read tool with full schema coverage and no output schema, the definition covers what the tool returns conceptually and the one option. Only minor gaps remain, such as what identifiers the returned node carries.

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 parameter, so the schema already explains embed_primaryImage fully. The description merely restates that the image data is optional, adding no syntax or format detail. 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 (get the root phylogenetic node) and clarifies the domain concept with a parenthetical definition. It does not, however, distinguish itself from siblings like get_node or get_node_lineage, which an agent must choose between.

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

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

The description implies when this is useful ('This is the top of the tree of life'), but never says explicitly when to prefer it over get_node/get_node_lineage or when it should be avoided on large queries. Usage is inferable but not 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?

With no annotations, the description carries the full burden. It does disclose useful behavior: results are sorted by image count descending, and contact info is only present 'if available' — a genuinely helpful disclosure. However, it omits pagination behavior, whether the list is complete or truncated, and any rate-limit or permission notes.

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, each earning its place: scope, ordering, and return fields. Front-loaded with the core purpose and free of 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 no output schema, the description usefully enumerates the returned fields (name, UUID, image count, contact info), which is exactly what the agent needs. It is only slightly short on pagination behavior for a list endpoint.

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

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

Schema description coverage is 100% and the single 'page' parameter is fully documented there, including its zero-indexed default and bounds. The description adds no parameter detail, so the baseline of 3 applies.

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

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

States a specific verb and resource ('List all PhyloPic contributors') and clarifies the entity with a parenthetical definition, plus the sort order. It never names sibling tools like get_contributor or list_images_by_contributor, so the agent must infer the distinction from the name alone.

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 explains what the tool returns but never says when to choose it over get_contributor (single contributor) or list_images_by_contributor (images for one contributor). No prerequisites, exclusions, or pagination guidance are offered.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only list operation but discloses nothing about pagination behavior, result ordering, or result size limits beyond what the input schema already states.

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, front-loaded with the action and resource. The second sentence is somewhat redundant with the first, keeping it from a perfect score.

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 list tool with no output schema, the essentials are present. However, pagination behavior and the fact that results are paginated (only implied by the page param) are not surfaced in the description.

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 contributor_uuid and page are already documented in the schema. The description adds no additional parameter semantics beyond confirming the contributor-scoped filter. 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 (list) and resource (silhouette images) scoped by contributor, and names the exact filter. An agent can distinguish it from search_images_by_node and search_images_by_clade, which scope by taxonomy rather than contributor.

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 this to browse all images uploaded by a particular artist or contributor" implies a browsing use case but names no alternatives and gives no when-not guidance. An agent must infer that search_images_by_node/clade are for taxonomy-based browsing.

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

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

No annotations exist, so the description carries the full burden, and it does disclose that each entry contains a link to the full license text. That return-shape detail is genuinely useful given there is no output schema. It stops short of noting whether the list is static or cached, but for a trivial read-only enumeration the disclosure is solid.

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 front-loaded, with no filler or repetition of the title. Every sentence adds either scope, return content, or usage context.

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 zero-parameter read tool with no output schema, the description covers what is listed, what each item contains, and why an agent would want it. Only minor details (static vs. dynamic list, ordering) 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. No misleading parameter hints are present.

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 all Creative Commons licenses available for new image submissions to PhyloPic') and scopes the resource precisely. No sibling tool touches licenses, so the agent can distinguish it immediately from the taxa/image/contributor 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?

The closing sentence gives context ('useful for understanding what licenses are accepted when contributing images'), which implies when to call it. However, it never frames when-not to call it, nor points to any related tool for acting on the licenses, so usage is only implied 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?

With no annotations, the description carries the full burden, and it discloses useful behavior: these are authorized namespaces, they map to PhyloPic node resolution, and each entry carries an authority plus a namespace identifier. It doesn't discuss pagination, ordering, or auth requirements, but for a zero-argument read-only enumeration this is solid coverage.

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

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

Three compact sentences, front-loaded with the core action and followed by examples and the returned fields. Slight verbosity in the example list, but every sentence carries information and nothing is wasted.

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

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

For a no-parameter list tool with no output schema, the description covers what the tool does, what the results conceptually contain, and why they exist. The only missing piece is explicit routing guidance to resolve_external_id, which keeps it short of a 5.

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?

Zero parameters means no parameter semantics are needed, which is the baseline 4. The description does add value by explaining the shape of each returned namespace (authority + identifier), which compensates for the absent output 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 (List) and resource (authorized external taxonomic database namespaces) with concrete examples (GBIF, Open Tree of Life, NCBI, Paleobiology Database). An agent can distinguish this enumeration tool from resolve_external_id, which consumes the namespaces this tool returns.

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

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

The description implies the purpose (resolving external identifiers to PhyloPic nodes) but never explicitly says when to call this versus sibling tools like resolve_external_id or search_taxa, nor states prerequisites such as calling this first to discover valid namespace values. Usage is implied 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?

No annotations are provided, so the description carries the full burden. It does disclose that the call returns a simple status message and implies a safe, non-mutating read, but it says nothing about authentication requirements, rate limits, or failure behavior (e.g., what a non-operational API 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 short, front-loaded sentences with no padding; the purpose leads. The third sentence overlaps somewhat with the first, costing a point rather than being wasteful.

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 trivial zero-param health check with no output schema, the description covers purpose, return nature, and use case adequately. It could note the absence of auth requirements to be 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool 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: checking whether the PhyloPic API is operational, plus what it returns. It is clearly a health-check tool, but it does not distinguish itself from the similarly named sibling 'get_api_info', which an agent could plausibly confuse with a connectivity check.

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?

"Useful for health checks and connectivity verification" implies when to reach for it, but there is no explicit when-not guidance and the sibling 'get_api_info' is never mentioned as an alternative or complement.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that resolution is approximate ("closest matching") rather than exact, which is a real behavioral trait an agent needs. However, it says nothing about failure behavior (no match), whether one or many nodes are returned, or any auth/rate considerations.

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, then an example, then the prerequisite. The middle example sentence partially restates the first sentence's intent, so it is efficient but not maximally tight.

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?

No output schema and no annotations, so the description should be compensating more than it does: it never describes what a resolved result looks like (single node? ranked candidates?) or what happens when nothing matches. For a lookup/resolution tool whose entire value is the returned mapping, that is a notable 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 coverage is 100% and all three parameters carry their own descriptions with examples, so the schema already does the heavy lifting. The description's GBIF/NCBI examples broadly reinforce the authority+namespace+object_id framing but add no syntax, format, or constraint 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 ('resolve') and resource ('external taxonomic database identifier' → 'PhyloPic phylogenetic node'), and the example pair (GBIF species key, NCBI taxon ID) makes the transformation concrete. It is clearly distinguishable from siblings like get_node, which resolves internal IDs, and list_namespaces, which enumerates authorities.

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 to a prerequisite sibling: "Use 'list_namespaces' first to see available authorities and namespaces." That is a genuine when-to-use-A-before-B instruction. It does not state when-not to use this tool or what to do if an exact node match is not needed, 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?

With no annotations, the description carries the full behavioral burden. It does disclose a non-obvious trait: results are 'roughly sorted by their subject matter's proximity to the clade root node.' It says nothing about result size, permissions, or rate limits, so it adds one useful behavioral detail but leaves other traits undeclared.

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, followed by usage examples and the sorting note. Every sentence contributes information; there is no repetition of the name or title as 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 read tool with a fully described schema and no output schema, the description covers what is returned (silhouette images), the scope of the search, and ordering. It omits pagination behavior on the return side, but the schema's page parameter partially covers that.

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 clade_uuid and page are fully documented, including the clade UUID example. The description reinforces that clade_uuid denotes a root node whose descendants are included, but adds no format, constraint, or pagination semantics 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 ('List silhouette images') plus the scope ('within a clade (a node and all its descendants)'). The parenthetical definition of clade effectively separates it from search_images_by_node, but the sibling is never named, so the agent must infer the contrast.

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 when it applies — 'useful for ancestral nodes — for example, getting all images of mammals, birds, or insects' — which tells the agent this is for higher-level taxonomic rollups. It stops short of an explicit exclusion or a named alternative (e.g. use search_images_by_node for a single node).

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

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

No annotations are provided, so the description carries the full disclosure burden, and it does cover the most consequential behavioral trait: results are limited to images that *directly* represent the node, not descendants, and only 'silhouette' images are returned. It is silent on read-only guarantees, return payload shape, and empty-result behavior, which keeps 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 sentences, front-loaded with the action and scope, then the use case, then the alternative. Every sentence earns its place and none restates the 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?

For a simple two-parameter list tool with no output schema, the description covers purpose, usage, and sibling routing adequately. It does not mention pagination behavior or what an image result contains, which is a minor but real gap given there are no annotations to fill in.

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 node_uuid (UUID of the phylogenetic node) and page (zero-indexed pagination) are documented in the schema itself. The description adds no format, constraint, or default 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 and resource ('List silhouette images'), the precise scope ('directly represent a specific phylogenetic node'), and gives a concrete example (all images of Homo sapiens). It is immediately distinguishable from search_images_by_clade, which the description names 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?

Gives both the when-to-use ('find all images of a particular taxon') and the when-to-use-the-alternative condition ('For ancestral nodes, consider using search_images_by_clade instead to get images of all descendant taxa as well'). Routing between the two siblings is fully specified rather than 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses what comes back (UUIDs, names, parent taxa, primary images), partially compensating for the missing output schema, but says nothing about pagination behavior, result limits, or whether the search is exact vs substring matching.

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 with zero filler: the action, the payload returned, and the formatting rule. The most decision-relevant content (what it searches and what it returns) 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 two-parameter read tool with full schema coverage and no annotations or output schema, the description covers purpose, return shape, and input normalization adequately. The remaining gap is the absence of any routing against the many sibling search/get 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 coverage is 100%, so the baseline is 3, but the description genuinely adds normalization semantics beyond the schema's 'lower-case recommended': non-alphabetic characters removed and whitespace trimmed. That tells the agent how PhyloPic actually indexes names, which is more than the schema conveys.

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 for phylogenetic nodes (taxa) in PhyloPic by name', and enumerates the return fields (UUIDs, names, parent taxa, primary images). It is clear what the tool does, but it never distinguishes itself from the very close sibling autocomplete_taxa, leaving the agent to infer which lookup path applies.

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 when-to-use guidance, no prerequisites, and no mention of when this search is preferable to autocomplete_taxa or the get_node family. The only guidance offered concerns how to format the query string, which is parameter information rather than usage routing.

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