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 declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real domain semantics beyond that: L1 means mandated by the breed club's Zuchtordnung, and the caveat that a listed qualzucht trait does not mean every dog of the breed is affected — a genuine interpretive warning.

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 usage trigger and then the data contents, which is the right order, and every clause carries information. It is somewhat long and the trailing German translation repeats content the agent has already read, which slightly dilutes efficiency but serves a bilingual audience.

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 must carry the return-value burden and does: it names the grade and rationale, hereditary diseases, required tests, and the optional qualzucht_traits field plus its interpretation caveat. For a one-param read tool this is complete enough to 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?

There is a single parameter with 100% schema description coverage, so the schema already documents breed_slug and its pattern. The description never references breed_slug and adds no format, source, or validation meaning 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+resource (get a breed's health profile) and enumerates the returned content: the S–E breeding-health grade with rationale, hereditary diseases, required health tests, and qualzucht traits. It is clearly distinguishable from search_breeds and the other siblings, which retrieve breeders, dogs, or breed lists rather than health data.

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 tells the agent when to reach for it ('Use when someone asks how healthy a breed is, which hereditary diseases it has, or which health tests to ask a breeder for') with concrete trigger examples in two languages. It does not name a competing sibling or a when-not condition, so it falls short of a full 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/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.