Mission Museaux

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds useful context about the returned payload (the association, the cost participation, and the page where the adoption request is made), which matters since there is no output schema, but it omits pagination/limit 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?

Two dense sentences, front-loaded with the resource and scope, followed by a compact bilingual line. It is a slightly run-on enumeration of returned fields but every clause carries information and there is no 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?

For a 7-parameter search tool with no output schema, the description does the important work of explaining what each result contains (association, cost, page URL for the request). It covers species and geography adequately; the main gap is pagination/limit semantics.

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 71%, with espece and limite undocumented in the schema. The description partially compensates by naming the species ('chats et chiens') and the geographic scope (commune vs whole country), but adds little on the limit or coordinate parameters beyond what the schema already states.

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 resource (cats and dogs for adoption in France) and its scope (Mission Museaux plus other associations, around a commune or nationwide). It clearly conveys what an agent gets back, but the action verb is only implied via the name and it does not name or distinguish itself from siblings like chercher_annonces.

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 explicit when-to-use or when-not-to-use guidance. The geographic framing ('autour d'une commune ou dans tout le pays') implies context, but with overlapping siblings such as chercher_annonces and voir_annonce, the agent is left to infer which tool to pick.

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, and the description is consistent with them while adding real context: the data is France-scoped public listings, and each result returns the listing address plus where to make contact and where to report a sighting. It does not cover pagination or how results are ordered, but it clearly exceeds what the annotations supply.

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?

Content is front-loaded: the resource scope, the statut hint and the return behavior all appear before the English mirror. The bilingual duplication doubles the length, but that mirrors the tool's own langue parameter and is therefore earned rather than wasteful.

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 10-parameter, zero-required search tool with no output schema, the description supplies the missing pieces an agent needs: geographic scope (commune or lat/long point), France-only coverage, and what a result contains. It omits pagination/limite behavior and how commune interacts with latitude/longitude when both are supplied, which keeps it short of 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?

Schema description coverage is 80%, so the schema already documents most parameters (statut, commune, rayon, langue, jours, texte). The description adds one genuinely new semantic detail — keywords match race names in French or English — but the statut explanation largely restates the schema, so this sits at the high-coverage 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?

The description gives a specific verb (cherche) and resource (annonces publiques de Mission Museaux) and enumerates the exact listing types covered: perdus, trouvés et recueillis, vus en liberté. This implicitly separates it from chercher_adoptions, but no sibling is named explicitly, so it stops short of full sibling differentiation.

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 hints at usage with 'Le statut « trouve_ou_errant » couvre ce qu'une personne qui a perdu son animal doit consulter', which tells an agent which filter a grieving owner should pick. However, there is no explicit when-to-use-this-vs-alternatives guidance (e.g. versus chercher_par_photo or voir_annonce), 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.

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

Annotations already cover read-only/idempotent/open-world safety, but the description adds genuinely useful context beyond them: the photo is not retained, the comparison uses the association's own vision model, and results include a likeness score plus an estimated breed. It does not mention latency, result limits, or behavior when nothing matches.

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?

Core capability is front-loaded and every sentence carries information, but the full French/English duplication roughly doubles the text and the website mention is tangential to invoking the 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 usefully spells out what comes back (ranked listings with percentages and estimated breed) and the privacy behavior. The main gap is that no parameter is marked required, yet a photo is essential; the description never says photo_url or photo_base64 must be supplied.

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 89%, so the schema already documents nearly every parameter, including the base64-instead-of-URL rule. The description only restates that an https URL or base64 image is accepted and that cats/dogs are supported, adding little beyond the schema; 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 ('Compare une photo d'animal ... aux photos des annonces') and names the outputs (similarity percentage, estimated breed). The photo-matching capability is inherently distinct from the text-oriented siblings (chercher_annonces, chercher_adoptions) and from reconnaitre_race, so an agent can tell what this tool is for without opening the 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?

Usage is only implied: it is clearly the tool for finding a lost/found pet from a picture, and it notes the web page for phone-based uploads, but it never states when to prefer it over reconnaitre_race (which also estimates breed) or the text search siblings, nor any prerequisite conditions.

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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing the content shape of the response — steps, FAQ, useful phone numbers, site pages — and the bilingual fr/en behavior, which annotations do not convey.

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 purpose and situation coverage are front-loaded in the first sentence, with the bilingual note last. The long enumeration of situations is functional (it maps to the enum), though it makes the single sentence 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?

For a read-only, non-destructive static-content tool with no output schema, the description covers what the tool is for, which situations it handles, and roughly what the answer contains. Nothing an agent needs to invoke it 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 description coverage is 100% and both parameters are fully documented enums with a default, so the baseline is 3. The description restates the same situation list and the French/English option without adding format, fallback, or error semantics 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 names a concrete resource — Mission Museaux's step-by-step procedure ('la marche à suivre') for a given situation — and enumerates the covered situations (chat perdu, animal trouvé, chatons, maltraitance, identification, adoption). An agent can immediately tell this returns guidance content rather than search results, though it never explicitly contrasts itself with the sibling search/lookup tools.

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 enumerated situations act as an effective routing map: 'use this when the user asks what to do about X.' It gives clear context but no exclusions and does not name any sibling as an alternative for adjacent needs (e.g. adoption search vs. adoption guidance).

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 readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds real value beyond that by spelling out the returned payload (FCI standard, origin, live listing and adoptable-animal counts, page address) in the absence of an output schema, though it says nothing about rate limits or how the counts are derived.

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?

Each language is a single dense sentence that front-loads the resource name, with no filler. The full bilingual duplication doubles the length, but that is a defensible choice for a fr/en service and no sentence 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?

With no output schema, the description does its job on return values by enumerating the fields per breed, and annotations cover the safety profile. It remains incomplete on parameters (espece, limite undocumented anywhere), on result-limit/pagination behavior, and on when to prefer this tool over reconnaitre_race for breed questions.

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 only 50%: 'espece' and 'limite' carry no schema descriptions. The description never explains any parameter, so it fails to compensate for the gap; the mention of 'French and English' and 'dog and cat' only loosely gestures at 'langue' and 'espece' and says nothing about the 1–30 result cap on 'limite'.

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 resource (Mission Museaux dog and cat breed directory) and enumerates exactly what each entry contains: FR/EN names, alternate names, FCI standard, origin, listing/adoption counts, and the breed page URL. This is clearly distinct from siblings like reconnaitre_race (photo identification) or chercher_annonces (listing search), although no sibling is named 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?

Usage is only implied: an agent can infer this is the browse/lookup tool for breed reference data, and the 'recherche' schema note hints at partial-name lookup, but the description itself gives no when-to-use, when-not, or routing guidance against reconnaitre_race or chercher_annonces.

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 readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=true, so safety is covered. The description adds genuinely non-structured behavior: the result is an estimate and not a certainty, and the photo is not stored (a privacy guarantee an agent should be able to relay). It does not mention rate limits, size limits, or error modes, so it stops short of a 5.

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?

Content is front-loaded with the core purpose, then outputs, then the caveat, then accepted input forms — a sensible ordering with no filler. The main cost is the full bilingual duplication, which roughly doubles length, though it plausibly 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 carries the return-value burden and does so well: likely breed with its share, possible mix, and each breed's page. Combined with the estimate caveat, the no-storage note, and accepted input forms, an agent has everything needed to call and interpret this 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 description coverage is 100%, so the schema already documents espece, langue, photo_url and photo_base64, giving a baseline of 3. The description adds the either/or relationship ('https address or base64') and the mutual exclusivity implied by the schema's 'instead of photo_url', but no extra format or size guidance beyond that.

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 gives a specific verb+resource: it estimates a dog's or cat's breed from a photo by comparing against Mission Museaux's breed directory and known-breed records. That is unambiguous and actionable, but it never explicitly names or contrasts with the closest sibling, chercher_par_photo, which also takes a photo, leaving the agent to infer the division of labor.

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: the reader infers this is for identifying a breed when the breed is unknown, versus 'races' (browsing the directory) or 'chercher_par_photo' (searching listings by image). There is no explicit when-to-use/when-not-to-use statement and no named alternative, so guidance is thin but derivable from the purpose.

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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that the detail is 'public' and that it includes 'ce que l'on peut faire depuis sa page' (available actions), which is mild extra context; it says nothing about auth, rate limits, or error behavior for a bad/expired 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?

The core purpose and content list are front-loaded in one efficient sentence. The trailing English one-liner largely duplicates the French rather than adding information, which costs a little space but does not obscure the main content.

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 detail tool with full annotation coverage, a complete input schema, and no output schema, the description helpfully previews what the response contains (fields, observation count, available actions). Nothing critical to invoking it 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 description coverage is 100% for both parameters, so 'annonce' (id or https address) and 'langue' (fr/en enum with default) are already fully documented. The description adds no syntax or format detail 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 and resource ('Le détail public d'une annonce') and enumerates the fields surfaced (description, distinctive marks, location, dates, photos, observation count, breed), so the agent knows this returns a single listing's full record. It is distinguishable from the sibling 'chercher_annonces' only implicitly, via the singular 'une annonce' and 'détail', with no explicit contrast drawn.

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 by 'détail ... d'une annonce' and by the singular required 'annonce' identifier, but there is no statement of when to prefer this over chercher_annonces/chercher_par_photo, nor any prerequisite or exclusion. Adequate 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.