Find adoptable shelter pets and how to contact the shelter. Read-only, no sign-in, 10 languages.
Scored across 9 tools
Most tools have distinct roles, but find_pets, search_by_description, and show_pets all surface adoptable pets and could be confused. Descriptions mitigate this well ('prefer find_pets when you already have structured values') and resolve_breed/resolve_place are clearly scoped helpers, so boundaries are mostly clear.
Names follow a consistent snake_case verb_noun pattern (find_pets, get_pet, get_rescue, resolve_breed, resolve_place, search_by_description, show_pets, similar_pets). The one deviation, about_this_service, is a noun phrase rather than verb_noun but remains readable and predictable.
Nine tools is well-scoped for a pet-adoption search service, with no obvious redundancy. Each tool earns its place by covering a distinct search modality, lookup, or helper.
The read-only lifecycle is well covered: discovery (find_pets, search_by_description, show_pets), detail (get_pet, get_rescue), exploration (similar_pets), and input resolution (resolve_breed, resolve_place), plus service info. Only minor gaps exist, such as no direct rescue-contact or saved-favorites operation, which agents can work around via existing detail tools.
Where the listings come from, who runs this service, what it keeps, and how a rescue changes or removes its listings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 structurally. The description adds genuine context beyond that by naming the topical domains it covers, including retention and listing removal/change semantics. It does not, however, say whether the content is static documentation or live data, nor anything about response shape.
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 most likely query target ('where the listings come from') and packed with four distinct content areas. Every clause earns its place and nothing is repeated from the schema or annotations.
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-argument, read-only informational tool with full annotation coverage and no output schema, the description is nearly sufficient: it tells the agent what questions this tool answers. The only minor gap is that it never confirms the call is argument-free and always available, which an agent must infer from the empty 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly does not clutter itself with parameter talk.
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 enumerates the exact content the tool surfaces: listing provenance, service operator, data retention ('what it keeps'), and how rescues change or remove listings. That is specific enough to separate it from every sibling (find_pets, get_pet, get_rescue, etc.), which all return pet/rescue data rather than service metadata. It falls short of a 5 only because it is a noun-phrase content list with no explicit verb like 'returns' or 'explains'.
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 only implied: an agent can infer this is the tool for provenance/policy/operator questions, but there is no statement of when to reach for it versus the data-retrieval siblings, and no exclusions. No prerequisites or conditions are given, which is acceptable for a zero-argument informational tool but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search adoptable pets at rescues and shelters (and, in some cities, found pets: marked found:true, announced for their owners first, not adoptable yet; pass found=exclude to leave them out): near a US ZIP, lat,lon or a Taiwan county or township in any language (near, with miles or km; sorted by distance); by species, age, size, sex, breed, color and whether they are good with dogs, cats or kids; or by words in any of 10 languages (q). Returns names, short facts, distance, the rescue and a link to each listing, plus what q was understood as.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Words in the person's own language: breeds, colors, ages, sizes, sex and places become filters ("black shiba girl Taipei", "黑色柴犬", "perro mayor"); other words are full-text search | |
| km | No | Radius in kilometres, instead of miles | |
| age | No | ||
| sex | No | ||
| lang | No | The person's language for names and text: en, es, zh-Hant, zh-Hans, ko, ja, vi, fr, ar, tl (default en) | |
| near | No | Where the person is: a US ZIP (65738), lat,lon (25.03,121.56; rounded to ~1 km), or a Taiwan county or township in any language (信義區, Xinyi, 臺北市). Results are sorted by distance. Prefer this or place over free text | |
| page | No | ||
| size | No | ||
| sort | No | photo = best photo first | |
| breed | No | A breed name in any language, or its Wikidata id (Q39315) | |
| color | No | ||
| found | No | Found pets (Vienna's list, announced for their owners for 30 days) are included by default, each marked found:true and NOT adoptable yet. exclude = adoptable pets only; only = found pets only. Never call a found pet adoptable | |
| limit | No | ||
| miles | No | Radius in miles (default 50) | |
| photo | No | good: only pets whose best photo passed our checks (analysed; not blurry, dark, tiny, or without a pet in it). Pets not analysed yet are left out | |
| place | No | The same as near, as structured fields (do not put a street address or a whole sentence here; the server resolves it against its own place table) | |
| facets | No | Add counts by species, size, age, sex, region and good-with | |
| region | No | Taiwan county or city, e.g. Taipei City, New Taipei City, Taoyuan City | |
| country | No | Which country's shelters: US, CA, TW (Taiwan), ES (Spain) or AT (Austria). Optional when near is a US ZIP or a Taiwan place | |
| species | No | ||
| good_with | No | Only pets the rescue says are good with these | |
| min_photo_px | No | Only pets whose best photo is at least this many pixels on its longest side |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, non-destructive, so the safety profile is covered. The description adds valuable behavioral context beyond that: found pets are announced for owners first, not adoptable yet, excluded via found=exclude, and the server resolves place against its own table. It doesn't cover pagination or rate limits, but it does meaningfully exceed the annotation baseline.
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?
It is front-loaded with the core purpose, which is good, but the description is a single dense, run-on paragraph stringing together many clauses. It is information-rich but not well structured; readers must parse parentheses and semicolons to extract semantics. Every clause is useful, but the packaging is heavy for a description field.
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 22 params, no required params, no output schema, and 68% schema coverage, the description does substantial work covering the multi-language, found-pet, and place-resolution nuances. It states the return shape ('names, short facts, distance, the rescue and a link'), which is valuable absent an output schema. It is largely complete, though some param behaviors (sort default, facets, limit) go unmentioned.
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 description adds meaning beyond the schema for several parameters: found, q, near, km/miles, photo, and the Taiwan/place handling. Schema coverage is 68%, not full, so the description compensates for the q filter vocabulary, multi-language support, and the place resolution behavior. Some parameters (sort, facets, limit) aren't explained, keeping it from 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?
The description states a specific verb+resource ('Search adoptable pets at rescues and shelters') and enumerates the rich filtering surface. It implicitly distinguishes from siblings like search_by_description (free text) and show_pets by describing the multi-faceted search. It doesn't explicitly name the siblings or their boundaries, so 4 rather than 5.
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 explains what 'found' means and how to exclude it, which is genuine usage guidance for one parameter. But it never says when to choose find_pets over search_by_description, show_pets, or similar_pets, nor does it state prerequisites or when-not-to-use. Usage context is implied by the capability list, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One adoptable pet by id (from find_pets): photos, temperament, good-with, adoption fee, the rescue and how to reach it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The pet's id, e.g. rg-8013243, tw-470460, us-mc-A508423 or es-zgz-2922 | |
| lang | No | The person's language (default en) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. With no output schema, the description usefully discloses what comes back — including the rescue's contact details ('how to reach it') — though it says nothing about lookup failure behavior.
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 dense sentence with the scope front-loaded and no filler; every clause carries information the agent can act on.
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-param read with full schema coverage and no output schema, the description covers purpose, id provenance and expected return contents. Only edge behavior (unknown id, lang effect) is left unstated.
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%, so both params are already documented, including id patterns and examples. The description only adds the provenance hint that id comes from find_pets and never addresses lang, so it sits at the baseline.
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 ('One adoptable pet by id') with explicit scope, plus the exact result contents (photos, temperament, good-with, adoption fee, rescue contact). The parenthetical '(from find_pets)' separates it from the list-returning siblings find_pets, show_pets and similar_pets.
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?
'(from find_pets)' tells the agent that the required id originates from find_pets output, which is a concrete chaining cue. It does not, however, state when to use this over get_rescue or what to do on a missing/invalid id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One rescue or shelter by id (from a pet's rescue.id): where it is, its adoption page, email and phone.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds value by disclosing the returned fields (location, adoption page, email, phone) and that the target may be either a rescue or a shelter — useful given there is no output schema. It omits error behavior for an unknown or mismatched id.
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 front-loaded sentence with zero filler: entity, key, provenance, and payload are all packed in without redundancy.
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 read tool with full annotations and no output schema, the description covers what it returns and where the id comes from, which is most of what an agent needs. Missing only edge-case behavior (invalid id, unknown entity type).
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 0%, so the description must compensate and it partially does by explaining that id comes from a pet's rescue.id and can denote a rescue org or a shelter. It does not explain the strict id prefixes encoded in the schema pattern (rg-org-, tw-shelter-, us-shelter-, etc.), leaving format detail undocumented in prose.
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 ('One rescue or shelter by id') and even names the id's origin ('from a pet's rescue.id'), which clearly separates it from get_pet and find_pets. It stops short of naming an alternative sibling, so it is clear rather than maximally differentiating.
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 parenthetical '(from a pet's rescue.id)' gives real, actionable context: the agent learns to source this id from a pet record, implying it is a secondary lookup after get_pet. There is no explicit when-not guidance or named alternative (e.g., resolve_place), so usage remains 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.
Turn a breed name in any language (貴賓犬, pit bull, perro salchicha, 시바견) into Wikidata breed ids, to pass to find_pets as breed or to compare listings across countries.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| species | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description usefully discloses the output contract (Wikidata ids) and shows multilingual input examples, but says nothing about unresolved names, ambiguity, or rate limits beyond what the annotations imply.
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 front-loaded sentence with a concrete downstream purpose; the embedded examples are illustrative rather than wasteful. Nothing reads as 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?
With no output schema, the description does well to name the return type (Wikidata breed ids) and the downstream consumer. However, for a two-parameter tool it omits any guidance on the species enum and on how ambiguous or unlisted breed names are handled.
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 0% for two parameters. The description illustrates the 'text' parameter well with multilingual examples, but never mentions the 'species' enum parameter (Dog, Cat, Rabbit, etc.), leaving a required-to-invoke filtering dimension unexplained in both schema and prose.
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 states a precise verb ('Turn ... into Wikidata breed ids') and resource (a breed name in any language), with concrete multilingual examples that make the cross-lingual normalization purpose unambiguous. It is clearly distinguishable from siblings like find_pets or about_this_service.
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 explicitly tells the agent what to do with the result: pass to find_pets as the breed argument, or use it to compare listings across countries. That is a clear usage context, though it does not state any when-not-to-use condition or alternatives for non-breed name resolution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a US ZIP, lat,lon or a Taiwan county or township name (any language) into the point and radius find_pets would search around, to confirm with the person before searching. Positions are rounded to about 1 km and nothing is stored.
| Name | Required | Description | Default |
|---|---|---|---|
| near | Yes | A US ZIP, lat,lon, or a Taiwan county or township name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world. The description adds genuinely new behavioral facts: coordinates are rounded to about 1 km and nothing is stored, which tells the agent the resolution is lossy and privacy-safe.
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 dense sentence that front-loads accepted inputs, then the output, then the workflow constraint. No filler and nothing repeated from the schema or annotations.
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 steps in to say what comes back (a point and radius), how precise it is, and that nothing persists. Combined with the routing to find_pets, an agent has everything needed to call this 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?
Schema coverage is 100% for the single 'near' parameter, so baseline is 3. The description earns an extra point by clarifying that Taiwan place names are accepted in 'any language', a constraint the schema does not state, and by describing what the parameter resolves to.
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 ('turn ... into the point and radius') and enumerates the accepted input forms (US ZIP, lat,lon, Taiwan county/township). It also names the downstream sibling find_pets, so an agent can place this tool precisely in the workflow.
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 makes the usage context clear: resolve first, then 'confirm with the person before searching', with find_pets as the consumer. It stops short of stating when-not to use it or what to do on failure, but the pre-search sequencing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find pets to adopt from a sentence in any language (found pets, marked found:true, are not adoptable yet): “a calm small dog that is good with kids, under 10 kg, near Springfield”. Returns the pets AND what was understood (understood.chips: species, breed, age, size, good-with, place, radius...), so you can tell the person what was searched and drop a wrong one with off=[chip id]. Good-with and similar facts are only filters when a listing states them; each pet has match[] saying stated / not_stated. Weight caps are approximated by size group and energy is only a hint. If the AI parts are unavailable it still answers from the words (degraded says so). Prefer find_pets when you already have structured values.
| Name | Required | Description | Default |
|---|---|---|---|
| off | No | Chip ids from a previous answer's understood.chips to leave out, e.g. ["good_with:kids"] | |
| lang | No | The person's language: en, es, zh-Hant, zh-Hans, ko, ja, vi, fr, ar, tl (default en) | |
| near | No | A US ZIP, lat,lon or a Taiwan place, if it is not in the query | |
| page | No | ||
| limit | No | ||
| query | Yes | What the person wants, in their own words and language, e.g. “a calm small dog good with kids, under 10 kg, near 65738” | |
| country | No | ||
| include_unknown | No | Also include pets whose listing does not say whether they are good with dogs/cats/kids (they are marked not_stated) |
Show adoptable pets near a place as an interactive view: photos, facts, and a button to meet one at its rescue. Use it when someone wants to look at pets to adopt. Apps without interactive views get the same list as text.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Words in the person's own language: breeds, colors, ages, sizes, sex and places become filters ("black shiba girl Taipei", "黑色柴犬", "perro mayor"); other words are full-text search | |
| km | No | Radius in kilometres, instead of miles | |
| age | No | ||
| sex | No | ||
| lang | No | The person's language for names and text: en, es, zh-Hant, zh-Hans, ko, ja, vi, fr, ar, tl (default en) | |
| near | No | Where the person is: a US ZIP (65738), lat,lon (25.03,121.56; rounded to ~1 km), or a Taiwan county or township in any language (信義區, Xinyi, 臺北市). Results are sorted by distance. Prefer this or place over free text | |
| page | No | ||
| size | No | ||
| sort | No | photo = best photo first | |
| breed | No | A breed name in any language, or its Wikidata id (Q39315) | |
| color | No | ||
| found | No | Found pets (Vienna's list, announced for their owners for 30 days) are included by default, each marked found:true and NOT adoptable yet. exclude = adoptable pets only; only = found pets only. Never call a found pet adoptable | |
| limit | No | ||
| miles | No | Radius in miles (default 50) | |
| photo | No | good: only pets whose best photo passed our checks (analysed; not blurry, dark, tiny, or without a pet in it). Pets not analysed yet are left out | |
| place | No | The same as near, as structured fields (do not put a street address or a whole sentence here; the server resolves it against its own place table) | |
| facets | No | Add counts by species, size, age, sex, region and good-with | |
| region | No | Taiwan county or city, e.g. Taipei City, New Taipei City, Taoyuan City | |
| country | No | Which country's shelters: US, CA, TW (Taiwan), ES (Spain) or AT (Austria). Optional when near is a US ZIP or a Taiwan place | |
| species | No | ||
| good_with | No | Only pets the rescue says are good with these | |
| min_photo_px | No | Only pets whose best photo is at least this many pixels on its longest side |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuine behavioral value beyond them: it discloses the response shape (interactive view vs. plain text list) and the fallback behavior for clients lacking interactive rendering, which the annotations do not convey. It still omits pagination and result-volume behavior for a 22-param search.
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 short sentences, purpose front-loaded, with the interactive-view detail following. The middle sentence ('Use it when someone wants to look at pets to adopt') largely restates the purpose, a minor redundancy, but nothing is bloated.
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 22-parameter, zero-required, nested-object search with no output schema, the description covers the output form well but leaves the sibling-routing question entirely open and says nothing about parameter interplay. It is minimally adequate rather than complete.
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 description contributes no parameter guidance at all despite 22 parameters. Schema coverage is 68%, below the high-coverage baseline threshold, and roughly a third of parameters (e.g. age, sex, size, page, limit, country, species) carry no schema description, so the description's silence leaves real gaps.
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 concrete verb and resource ('Show adoptable pets near a place') plus the output form (interactive view with photos, facts, and a meet button), which is more than a tautology. However, it never distinguishes itself from sibling find_pets or similar_pets, which plausibly return the same pet data, so an agent cannot tell which to pick from the text alone.
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 it when someone wants to look at pets to adopt' gives only a generic trigger and names no alternatives, even though siblings find_pets, search_by_description and similar_pets exist. The 'apps without interactive views get the same list as text' line is a rendering fallback, not a when-to-use/when-not-to-use rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pets similar to one pet id (from search results): same kind of pet and size, nearest in meaning of their listings. Use it after the person likes one pet.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| lang | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the useful constraint that the id comes from search results and how similarity is computed, but says nothing about return volume, limit/lang behavior, or result format.
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 short sentences with the core purpose front-loaded and the usage trigger second; no filler. Minor awkwardness ('one pet id', 'nearest in meaning of their listings') slightly reduces precision rather than length.
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, so return values don't need describing, and annotations carry the safety profile. However, for a 3-parameter tool with 0% schema coverage, the absence of any guidance on limit and lang leaves the definition incomplete for correct invocation.
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 0% across three parameters. The description gives partial meaning for id ('from search results', encoded id pattern in schema) but says nothing about lang or limit (1-24), leaving two parameters entirely undocumented in both schema and prose.
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 clear operation on a specific resource: return pets similar to one pet id, and goes further by defining the similarity criteria (same kind and size, nearest in meaning of listings). This distinguishes it from find_pets and search_by_description, though the phrasing 'nearest in meaning of their listings' is slightly ambiguous.
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?
Provides an explicit trigger: 'Use it after the person likes one pet,' which anchors it to a conversational moment. It does not name alternative tools or state when not to use it, so it stops short of full routing guidance.
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.
find_pets8 fields changedInput schema / properties / country / descriptionPrevious value: -"Which country's shelters: US, CA or TW (Taiwan). Optional when near is a US ZIP or a Taiwan place"New value: +"Which country's shelters: US, CA, TW (Taiwan), ES (Spain) or AT (Austria). Optional when near is a US ZIP or a Taiwan place"Input schema / properties / country / enumPrevious value: -[
- "US",
- "CA",
- "TW"
-]New value: +[
+ "US",
+ "CA",
+ "TW",
+ "ES",
+ "AT"
+]Input schema / properties / foundAdded value: +{
+ "description": "Found pets (Vienna's list, announced for their owners for 30 days) are included by default, each marked found:true and NOT adoptable yet. exclude = adoptable pets only; only = found pets only. Never call a found pet adoptable",
+ "enum": [
+ "include",
+ "exclude",
+ "only"
+ ],
+ "type": "string"
+}Input schema / properties / min_photo_pxAdded value: +{
+ "description": "Only pets whose best photo is at least this many pixels on its longest side",
+ "maximum": 4000,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / photoAdded value: +{
+ "description": "good: only pets whose best photo passed our checks (analysed; not blurry, dark, tiny, or without a pet in it). Pets not analysed yet are left out",
+ "enum": [
+ "good"
+ ],
+ "type": "string"
+}Input schema / properties / sort / descriptionAdded value: +"photo = best photo first"Input schema / properties / sort / enumPrevious value: -[
- "relevance",
- "newest",
- "distance"
-]New value: +[
+ "relevance",
+ "newest",
+ "listed",
+ "distance",
+ "photo"
+]Input schema / properties / species / enumPrevious value: -[
- "Dog",
- "Cat",
- "Rabbit",
- "Bird",
- "Horse",
- "Small animal",
- "Reptile",
- "Pig",
- "Barnyard"
-]New value: +[
+ "Dog",
+ "Cat",
+ "Rabbit",
+ "Bird",
+ "Horse",
+ "Small pet",
+ "Reptile",
+ "Pig",
+ "Barnyard"
+]get_pet2 fields changedInput schema / properties / id / descriptionPrevious value: -"The pet's id, e.g. rg-8013243 or tw-470460"New value: +"The pet's id, e.g. rg-8013243, tw-470460, us-mc-A508423 or es-zgz-2922"Input schema / properties / id / patternPrevious value: -"^(rg|tw|sample)-\\d{1,12}$"New value: +"^(?:(?:rg|tw|sample)-\\d{1,12}|us-(?:mc|kc)-[A-Za-z0-9]{1,12}|es-zgz-\\d{1,8}|at-vie-\\d{1,8})$"get_rescue1 field changedInput schema / properties / id / patternPrevious value: -"^(rg-org-[a-z0-9]{1,12}|tw-shelter-\\d{1,6})$"New value: +"^(?:rg-org-[a-z0-9]{1,12}|tw-shelter-\\d{1,6}|us-shelter-(?:mc|kc)|es-shelter-zgz|at-shelter-(?:tqt|ma60|rfz))$"resolve_breed1 field changedInput schema / properties / species / enumPrevious value: -[
- "Dog",
- "Cat",
- "Rabbit",
- "Bird",
- "Horse",
- "Small animal",
- "Reptile",
- "Pig",
- "Barnyard"
-]New value: +[
+ "Dog",
+ "Cat",
+ "Rabbit",
+ "Bird",
+ "Horse",
+ "Small pet",
+ "Reptile",
+ "Pig",
+ "Barnyard"
+]search_by_descriptionshow_pets8 fields changedInput schema / properties / country / descriptionPrevious value: -"Which country's shelters: US, CA or TW (Taiwan). Optional when near is a US ZIP or a Taiwan place"New value: +"Which country's shelters: US, CA, TW (Taiwan), ES (Spain) or AT (Austria). Optional when near is a US ZIP or a Taiwan place"Input schema / properties / country / enumPrevious value: -[
- "US",
- "CA",
- "TW"
-]New value: +[
+ "US",
+ "CA",
+ "TW",
+ "ES",
+ "AT"
+]Input schema / properties / foundAdded value: +{
+ "description": "Found pets (Vienna's list, announced for their owners for 30 days) are included by default, each marked found:true and NOT adoptable yet. exclude = adoptable pets only; only = found pets only. Never call a found pet adoptable",
+ "enum": [
+ "include",
+ "exclude",
+ "only"
+ ],
+ "type": "string"
+}Input schema / properties / min_photo_pxAdded value: +{
+ "description": "Only pets whose best photo is at least this many pixels on its longest side",
+ "maximum": 4000,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / photoAdded value: +{
+ "description": "good: only pets whose best photo passed our checks (analysed; not blurry, dark, tiny, or without a pet in it). Pets not analysed yet are left out",
+ "enum": [
+ "good"
+ ],
+ "type": "string"
+}Input schema / properties / sort / descriptionAdded value: +"photo = best photo first"Input schema / properties / sort / enumPrevious value: -[
- "relevance",
- "newest",
- "distance"
-]New value: +[
+ "relevance",
+ "newest",
+ "listed",
+ "distance",
+ "photo"
+]Input schema / properties / species / enumPrevious value: -[
- "Dog",
- "Cat",
- "Rabbit",
- "Bird",
- "Horse",
- "Small animal",
- "Reptile",
- "Pig",
- "Barnyard"
-]New value: +[
+ "Dog",
+ "Cat",
+ "Rabbit",
+ "Bird",
+ "Horse",
+ "Small pet",
+ "Reptile",
+ "Pig",
+ "Barnyard"
+]similar_petsabout_this_servicefind_petsget_petget_rescueresolve_breedresolve_placeshow_petsSearch animals in eight languages with habitats, countries, photos and source credits.
Lost, found and stray pets in France: listings, photo search, adoption, advice, breeds.
Cães e gatos para adoção no Brasil, de ONGs e protetores. Busque por cidade, porte, idade e saúde.
Read-only search of Québec's bilingual classifieds: ads, categories, filters, places.
Add one secure layer between your agents and this server.
