dog_list_breeds
Fetches all dog breeds and sub-breeds for selection, lookup, or automation workflows.
Instructions
List all dog breeds and sub-breeds.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Fetches all dog breeds and sub-breeds for selection, lookup, or automation workflows.
List all dog breeds and sub-breeds.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.11Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description adds one piece of real behavioral information the annotations don't carry: results include sub-breeds, implying a hierarchical/grouped payload rather than a flat list. It stops short of describing result shape or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler, which is appropriate for a trivial lookup. It is arguably over-trimmed given the crowded dog-breed sibling family, but nothing in it 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-param read with no output schema, an agent still doesn't know the return shape beyond 'breeds and sub-breeds' (flat names? grouped objects? images attached?). Annotations cover safety, but the description could have said more about what comes back.
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 schema also closes the object with additionalProperties=false. Baseline of 4 applies for a no-arg tool.
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?
Specific verb 'List' plus resource 'all dog breeds and sub-breeds' makes the operation unmistakable, and mentioning sub-breeds signals the nested shape of the result. However, the sibling list contains dog_breed_list, dog_api_breeds and dog_breed_image, and the description gives no way to tell which one an agent should pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this versus the near-duplicate siblings (dog_breed_list, dog_api_breeds) or versus dog_breed_image for images. Usage has to be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.