honestdog

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds meaningful framing that this is an explanatory/attribution response rather than live lookup results, but says nothing about response shape (e.g., whether text, when to surface it to the user) beyond that. The modest added context justifies a 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?

The English sentence is front-loaded: purpose, then provenance, then attribution, then the usage trigger. The full German mirror doubles the length, which is defensible for a .de platform with German-speaking users but is still redundant payload relative to a purely technical reading.

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 informational tool with no output schema and annotations covering its safety profile, the description supplies everything needed to select and invoke it correctly: what it returns conceptually and when to call it. Only the response format is left implicit, which is acceptable given there is no return schema to align with.

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 per the rubric the baseline is 4. There is nothing the description could add, and it introduces no misleading argument hints.

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 precisely states the tool's content: what HonestDog is, where breeder/shelter/breed-health data originates, and how results link back to honestdog.de. That is unmistakably distinct from the sibling search_* tools, which retrieve entities rather than platform/provenance background. It lacks an explicit verb-and-resource phrasing, but the scope 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 when the user asks what HonestDog is or whether its data can be trusted" gives a concrete trigger condition, effectively excluding entity-search requests that belong to siblings. It stops short of naming those siblings as the alternative path, so it is clear context without explicit 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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description instead adds genuinely non-obvious context: what L1 means, that club_required is driven by the breed club's Zuchtordnung, and the caveat that a listed qualzucht_trait does not mean every dog is affected. It stops short of auth/permission or freshness/rate-limit context.

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-loads the use-case triggers, then layers field-by-field explanations, so the important routing information is first. The fully duplicated German translation is a meaningful chunk of the length, but it plausibly serves a bilingual audience rather than being pure 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?

No output schema exists, so the description must carry return-value semantics — and it does, defining the S–E grade with rationale, hereditary diseases, health tests, club_required, and qualzucht_traits levels. An agent can understand the payload without a response 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% for the single breed_slug parameter and the description adds nothing about it (e.g. that the slug must come from search_breeds, or casing/format rules). Baseline 3 applies when the schema does the lifting.

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

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

States a specific verb+resource ('per-breed health data: S–E breeding-health grade, hereditary diseases, health tests') and anchors it with real user-query examples. It is clearly distinguishable from search_breeds/search_breeders, which locate breeds or breeders rather than return health profiles.

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 trigger conditions ('Use when someone asks how healthy a breed is, which hereditary diseases it has, or which health tests to ask a breeder for') plus sample phrasings. It does not name an alternative tool or state when not to use it, so it stops short of a full when/when-not 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 the description adds context annotations cannot: contact happens on honestdog.de and never through this tool, the returned fields are listed, and there is a special Qualzucht caution-instead-of-results behavior. That is exactly the kind of non-obvious behavior 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?

Front-loaded with a clear 'Use when...' clause, which is good, but the trailing German sentence largely restates the English content and inflates length for an agent-facing tool. The return-value list is useful, yet the overall text could shed the duplication.

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 compensates by enumerating the returned fields (kennel name, photo, city/region/country, score, profile URL) and explains contact flow and the Qualzucht edge case. Nothing an agent needs to call or interpret this tool 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 75% and the description adds genuinely new semantics the schema lacks: breed_slug accepts only exact breeds (crosses like Labradoodle are not listed under a parent breed) and state uses German spelling with English names mapped. The limit parameter gets no mention, and the state/city spelling guidance largely duplicates the schema, so it falls slightly short of 5.

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 ('Searches HonestDog's directory of vetted, APPROVED dog breeders') and immediately distinguishes itself from siblings by naming search_breeds as the source of the breed slug and contrasting with shelter adoption implicitly. The geographic scope (Germany/Austria/other Europe) further sharpens what this tool is versus a generic 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 concrete when-to-use triggers with real example queries in two languages. However, it never explicitly names an alternative to route to (e.g. search_shelter_dogs for adoption) or states when NOT to use it, so the routing guidance stops just short of the top score.

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, non-destructive, closed-world), and the description adds genuinely new behavior: results are ranked most popular first, query matching accepts German or English with optional umlauts, and it returns breed slugs, a photo, and the honestdog.de page URL. With no output schema, that return-value disclosure is exactly the missing context.

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 usage trigger and examples, then the mechanics and return values. The German sentence is a full translation of the English one, which is redundant for an agent, but the overall length is proportionate to the information delivered.

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, no-required-param search tool with no output schema, the description covers the trigger, the searchable dimensions, ranking, and the shape of the return (slugs keyed to the other tools, photo, URL). Only the limit behavior and any zero-result handling are 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 75% and already documents query language/umlaut handling, size class, and the S–E grade scale. The description restates these filter dimensions but adds no syntax or format detail beyond the schema, and never mentions the limit parameter — 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 and resource ('Searches HonestDog's breed catalogue') plus the fields searched (name, size, health grade) and the result ordering. An agent can distinguish it from search_breeders and search_shelter_dogs, which are the sibling searches over different corpora.

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 trigger context ('when someone is choosing a dog breed or asks which breeds are healthy') with concrete example queries in two languages. It does not explicitly say when NOT to use it or name the sibling tool to prefer for breeder/shelter lookups, so it stops short of 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower — and the description still adds real context: small coverage ('a few shelters, mostly mixed breeds'), photos only where the shelter consented, and that adoption completes off-platform via the linked listing pages.

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 trigger condition and efficient; every sentence carries information. The full German translation roughly doubles the length and is redundant for an agent, though it is a deliberate bilingual choice for a German-market 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?

With no output schema, the description carries the return contract itself — name, consented photos, age in years, size, shelter, and the honestdog.de listing URL — plus the coverage limitation. Nothing an agent needs to call or interpret 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 coverage is 60% and the schema already documents the notable semantics (size mapped from German, state English-name mapping, bilingual breed matching). The description merely recaps the filter dimensions ('breed (German or English), size, gender, or Bundesland') without adding new meaning, and never explains the limit parameter.

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 ('Searches dogs currently listed for adoption by German partner shelters on HonestDog') plus the filter dimensions. The resource (shelter dogs for adoption) is distinct from the sibling search_breeders, so an agent can separate 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?

'Use when someone wants to adopt a dog from a shelter in Germany' with two concrete example utterances gives clear trigger conditions. It does not explicitly name an alternative or a when-not case (e.g. use search_breeders for buying from breeders), 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.