honestdog

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

Annotations already declare readOnlyHint=true. The description adds behavioral context: it reveals platform identity, data sources, and citation requirements, which goes beyond the annotation.

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?

Bilingual description in two lines is concise and front-loaded with key information. Slightly redundant due to dual language, but overall efficient.

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

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

Given zero parameters, no output schema, and a simple informational purpose, the description covers everything an agent needs: what it is and when to call it.

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?

No parameters exist, so baseline is 4. The description compensates by explaining the tool's purpose and usage, adding value beyond the empty 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?

Explicitly states what the tool provides: platform identity, data provenance, and attribution. Distinguishes from sibling tools that perform searches, making its unique purpose clear.

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

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

States 'Call this once before presenting HonestDog data', giving explicit when-to-use guidance. No mention of when not to use, but the context implies it's a prerequisite setup tool, so alternatives are not needed.

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?

The description adds context about the data content beyond the readOnlyHint annotation, detailing the grade, rationale, diseases, and tests. However, it does not disclose other behavioral aspects such as data freshness, response format, or any potential limitations.

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 description is extremely concise: two sentences (one in English, one in German) that pack all essential information. No filler words, and front-loaded with the most critical detail (the grade and tests).

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

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

Given the tool has one parameter and no output schema, the description covers the return values well (grade, rationale, diseases, tests). It could be more explicit about the response structure, but it sufficiently conveys what the tool returns for its intended use.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add extra meaning to the 'breed_slug' parameter beyond what the schema already provides (e.g., it should come from 'search_breeds'). No additional constraints or formats are described.

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 title and description clearly state the tool returns a breed health profile including an S–E grade, rationale, hereditary diseases, and required health tests. The resource ('breed health profile') and the action ('get') are specific and distinguishable from siblings like 'search_breeds'.

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 does not provide explicit guidance on when to use this tool versus alternatives. It implicitly assumes the user has a breed slug (likely from 'search_breeds'), but no when-to-use or when-not-to-use advice is 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?

The description adds behavioral context beyond the readOnlyHint annotation: it details that only public profile data and a URL are returned, contact happens externally, and Qualzucht breeds trigger a caution. No contradictions.

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 description is concise with two sentences in English and one in German. It is front-loaded with the key purpose. The German sentence is redundant for an English-speaking agent but not overly harmful.

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

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

Given four parameters and no output schema, the description covers the tool's purpose, filtering options, edge case (Qualzucht), and contact flow. It lacks return format details (e.g., pagination) but provides enough for basic usage.

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 50% (only state and breed_slug have descriptions). The description mentions optional filtering by breed and location but does not elaborate on parameters like limit, city, or the relationship to search_breeds. It meets the baseline but adds limited semantic value 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?

The description clearly states the tool searches vetted, APPROVED dog breeders by breed and location, distinguishing it from siblings like search_breeds and search_shelter_dogs. It specifies the source (HonestDog's directory) and the intent (find approved breeders).

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 provides guidance by noting that for Qualzucht breeds a caution is returned instead of results, and that contact occurs via the profile URL, not through the tool. It lacks explicit when-to-use vs. siblings, but sibling context supplements.

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 indicate readOnlyHint: true. The description adds that it returns breed slugs and URLs, and mentions the search criteria. This provides useful behavioral context beyond the annotations.

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

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

The description is two sentences (bilingual) with a clear verb-first structure, no filler, and all information is relevant and 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?

Given no output schema, the description adequately explains the purpose, search criteria, and return values (slugs and URL). It lacks details on limit behavior or result ordering, but is generally complete for a search tool.

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

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

Schema coverage is 75%, and the description reiterates search by name, size, and health grade but does not add details beyond the schema parameter descriptions. The limit parameter lacks description 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?

The description clearly states it searches the breed catalogue by name, size, or health grade, and mentions it returns breed slugs and URLs. This distinguishes it from sibling tools like search_breeders and search_shelter_dogs.

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 explicit when-to-use or when-not-to-use guidance is provided. Context from sibling names implies this is the tool for breed searches, but alternatives are not named.

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 provide readOnlyHint, which the description does not contradict. The description adds useful context: it searches by substring match for breed_text and that adoption happens via linked pages. However, it does not cover rate limits, pagination, or result structure.

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

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

Two sentences (English and German) that are front-loaded with the essential purpose. There is no wasted text; every word adds value.

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 search tool with 5 parameters and no output schema, the description adequately covers the scope and action. It mentions the platform (HonestDog) and the adoption process via linked pages, though it omits details on result format or pagination. Slightly light on completeness but sufficient for typical use.

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 schema description coverage at 40%, the description reiterates the filter fields (breed text, size, gender, Bundesland) but adds little detail beyond the schema. It does not clarify the 'limit' or 'size' parameter constraints. Baseline 3 is appropriate as the schema partially covers two parameters.

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 clearly states the tool searches for adoptable shelter dogs on HonestDog, specifying searchable criteria (breed, size, gender, Bundesland). This distinguishes it from sibling tools like search_breeders and search_breeds.

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 explicit guidance on when to use this tool versus alternatives. The description does not mention when not to use it or provide context for choosing between search_shelter_dogs and sibling tools like search_breeders or get_breed_health_profile.

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