Identify cat breeds from descriptions or photos with furriq.com's 61-breed database.
Scored across 5 tools
analyze_cat_photo and find_cat_breed both identify breeds, but their descriptions clearly separate them by input modality (image URL vs. text description) and explicitly call out the deterministic vs. AI distinction. compare_breeds, get_breed, and list_breeds are each clearly distinct, so no meaningful overlap remains.
All five tools follow a consistent snake_case verb_noun pattern: analyze_cat_photo, compare_breeds, find_cat_breed, get_breed, list_breeds. The inclusion of 'cat'/'breed' varies slightly, but the structure and verb style are uniform.
Five tools is well-scoped for a breed identification service: list, get, find (text match), compare, and analyze (photo). Each tool covers a distinct workflow with no redundant entries.
The surface covers the core identification lifecycle: enumerate breeds, fetch profiles, match descriptions, compare breeds, and analyze photos. Minor gaps exist (e.g., no explicit search-by-name or batch/save functionality), but agents can work around these via list_breeds and find_cat_breed.
Analyze a cat photo with AI vision and estimate the most likely breeds, with honest uncertainty. Provide a public image URL (or a data: URL). Limited to 10 analyses per day; a lighter deterministic alternative is find_cat_breed with a text description. For a full report, https://www.furriq.com/identify-cat-by-photo
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | Publicly fetchable http(s) or data: URL of a cat photo (JPEG/PNG/WebP). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful traits: a concrete rate limit (10 analyses/day), the probabilistic nature ('honest uncertainty'), and the accepted input form. It omits auth requirements and any return format, but the rate limit and non-determinism hints are genuinely useful disclosure.
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 front-loaded sentences, each doing work: purpose, input/rate limit, alternative. The trailing promotional link ('For a full report, ...') is the one element that does not help an agent invoke the tool, costing a point.
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 one-parameter tool with no annotations and no output schema, the description covers purpose, input format, rate limit, and the sibling alternative, and hints at output ('most likely breeds, with honest uncertainty'). Return-shape detail is thin since no output schema exists to carry it, but the essentials for correct invocation are present.
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 there is a single required parameter, so the schema already documents image_url fully. The description's 'Provide a public image URL (or a data: URL)' largely restates the schema's own description, adding no syntax or constraint beyond it. 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 ('Analyze a cat photo with AI vision') plus the output ('estimate the most likely breeds'). It distinguishes itself from the sibling find_cat_breed by contrasting photo-based AI vision against a text-description approach, so an agent can route 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?
Explicitly names the alternative ('a lighter deterministic alternative is find_cat_breed with a text description'), giving a clear condition for choosing it. It also implies the use case (you have a photo). What it lacks is an explicit when-not or prerequisite statement beyond the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two cat breeds side by side (identification markers, temperament, care) and, when the breeds are commonly confused, return furriq.com's "how to tell them apart" guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| breedA | Yes | First breed slug or name. | |
| breedB | Yes | Second breed slug or name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does add one genuine behavioral detail beyond the schema: conditional extra output ('how to tell them apart' guidance) when the breeds are commonly confused. However, it says nothing about invalid/non-cat breed names, matching behavior for slugs vs names, or response size, which is a meaningful gap for an annotation-free tool.
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?
A single sentence, front-loaded with the core action and resource, followed by the comparison dimensions and the conditional extra output. No filler clauses; each segment contributes information.
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 tool with no output schema, the description covers both the returned dimensions (markers, temperament, care) and a conditional extension (confusion guidance). It is nearly complete; only edge-case handling for unresolvable breed names is 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% and both parameters are documented as 'breed slug or name,' so the schema already does the work. The description adds only the framing that these are the two sides of the comparison, which is marginal. 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 (compare) and resource (two cat breeds) and enumerates what is compared: identification markers, temperament, care. The 'two breeds side by side' framing naturally distinguishes it from get_breed, list_breeds, and find_cat_breed without needing to name them.
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?
Usage is implied: call this when you need a two-breed comparison rather than a single breed lookup. There is no explicit when-to-use/when-not statement and no naming of the sibling alternatives (get_breed for one breed, find_cat_breed for identification), leaving routing partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Match a cat description to likely breeds from furriq.com's curated database of 61 breeds. Describe what the cat looks like or how it behaves (coat pattern, body shape, ears, temperament) and get the top candidates with the specific markers that matched. Deterministic — no AI guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Description of the cat, e.g. "large fluffy cat with a bushy tail and lynx-like ear tufts" or "small hairless wrinkly cat". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose real traits: the matching is deterministic ('no AI guessing'), it draws from a fixed 61-breed curated database, and it returns top candidates with matched markers. It omits what happens on a poor/no match and any input 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?
Three tight sentences, front-loaded with the action and followed by input expectations and output nature. No filler or 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?
For a single-parameter read tool with no output schema and no annotations, the description covers input style, data source, and result shape well. It could add no-match behavior or result limits, but nothing essential to invocation 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 100% so the baseline is 3, but the description adds genuine query-construction guidance by enumerating which attributes to include (coat pattern, body shape, ears, temperament) and promising marker-level output, beyond the schema's two examples.
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 ('Match a cat description to likely breeds') plus scope ('curated database of 61 breeds'). It implicitly separates itself from analyze_cat_photo by requiring a text description rather than a photo, but it never names a sibling 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?
It tells the agent how to supply input ('Describe what the cat looks like or how it behaves') but gives no when-to-use/when-not guidance and never contrasts itself with analyze_cat_photo or list_breeds. 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.
Get the full profile of one cat breed from furriq.com: physical identification markers, temperament traits, size/weight/lifespan/origin, health notes, and links to similar breeds.
| Name | Required | Description | Default |
|---|---|---|---|
| breed | Yes | Breed slug or name, e.g. "norwegian-forest" or "Norwegian Forest Cat". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the return payload composition (which is genuinely useful since there is no output schema), but says nothing about what happens for an unknown breed slug, whether the source is live/cached, rate limits, or auth requirements. Read-only nature is only implied by "Get".
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?
A single sentence, front-loaded with the core action and resource followed by the payload inventory. Nothing is wasted, though the long comma-separated field list is slightly dense.
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?
Absent an output schema, listing the returned data is the right move and partially compensates. However, for a retrieval tool with no annotations, the definition omits error behavior for invalid slugs and any distinction from the closely named find_cat_breed sibling.
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% with a single, well-documented 'breed' parameter including slug and display-name examples. The description adds no parameter detail beyond that, so the baseline of 3 for schema-documented params 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?
The description names a specific verb ("Get") and resource ("full profile of one cat breed") and enumerates the exact payload: identification markers, temperament, size/weight/lifespan/origin, health notes, similar breeds. Sibling differentiation is only implicit — it doesn't explicitly contrast with find_cat_breed or list_breeds, though "full profile of one" implies detail rather than search or enumeration.
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?
Usage is implied rather than stated: the agent can infer this is for fetching a detailed profile of a single known breed. There is no explicit when-to-use/when-not guidance, no mention of how it differs from find_cat_breed or compare_breeds, and no prerequisites or failure conditions given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all 61 cat breeds in the furriq.com database with size, origin, and category.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full behavioral burden. It doesn't state pagination limits, whether results are cached or sorted, or the response shape. 'All 61' is a useful size hint but does not compensate for the absence of any other operational detail.
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?
Single tight sentence with the scope front-loaded. Every clause earns its place and nothing is repeated from structured data.
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-param list operation with no output schema, the description is minimally sufficient. It would benefit from stating whether the 61-count is fixed or currently available and whether results are sorted, but for a simple enumeration tool it is adequate.
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, so baseline is 4 per the rubric. The description correctly implies the tool takes no input and always returns the complete set.
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+resource ('List all 61 cat breeds') with the scope of the data set named. It's clearer than a bare 'list breeds', though it does not explicitly distinguish itself from siblings like find_cat_breed or get_breed, which could be similarly invoked by an agent.
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 when-to-use guidance, no alternatives named, no prerequisites. With siblings like find_cat_breed, get_breed, and compare_breeds, the agent must infer that this is the 'browse everything' variant rather than a filtered lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_cat_photocompare_breedsfind_cat_breedget_breedlist_breedsReal cat photos, diaries, profiles, age and food reference calculators, and breeds.
Match dog breeds to your life, compare them, plan a test drive and estimate U.S. vet costs.
Search 180+ free PawLine pet care guides and run pet care calculators.
Vet reviewed pet lab interpretation tool for dogs and cats. Furva reads blood work and urinalysis and explains every result in easy to understand terms, built on a biomarker reference set reviewed by a licensed veterinarian. It explains what markers like BUN and creatinine measure, tracks results over time, suggests when labs should be rechecked, and helps owners prepare questions for their vet. Education only: never diagnoses or prescribes. Connect with OAuth 2.1 sign-in or an fmcp_ API key.
Add one secure layer between your agents and this server.
