MonRdvKine

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

Annotations already declare readOnlyHint/idempotentHint, but the description adds real behavioral context beyond them: an empty week is automatically replaced by the next, at most 3 weeks are examined, BookableFrom/BookingOpenUntil/BookingOpensOn explain lead-time and later-opening days, and it explicitly says nothing is reserved — the BookingUrl must be handed to the patient. It even disambiguates the response branches (Slots vs Message).

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?

Front-loads the resource and scope, and no sentence is filler — every clause carries an operational rule. It is, however, a single semicolon-chained block that is dense to parse; splitting the step logic from the lead-time field notes would read faster without losing 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?

With 4 parameters, no output schema, and full schema coverage, the description still explains the shape of what comes back (Slots, Message, BookingUrl, QueueListUrl) and what the agent must and must not do with it. Nothing an agent needs to call this 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 coverage is 100%, so the baseline is 3; the description goes further by explaining why motif_id and cabinet_id are optional on the first call (only when asked / after Motives or Offices) and by defining a_partir_du as WeekStart or NextWeekStart with the default of the next available week. The added meaning is genuine decision logic rather than a restatement of 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?

Names a concrete verb and resource — online slots for a new patient's first session at a kinésithérapeute — and scopes the horizon (one week at a time, WeekStart, up to 3 weeks examined). This is unmistakably different from the sibling search tools rechercher_kines / rechercher_kines_autour, which locate practitioners rather than availability.

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?

Gives an explicit step machine (OfficeSelection, Motive, AppointmentSelection, Blocked/MotiveMessage) with the action to take at each step, including when to re-call with cabinet_id or motif_id. Also states the one-motif vs multi-motif branch (take it vs ask the patient the reason first) and the fallback to the waiting list when IsQueueListActive, so no alternative is left to inference.

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 the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), yet the description adds the 20-result cap and enumerates the returned flags (AcceptsNewPatientsOnline, IsQueueListActive, QueueListUrl), which is real value since no output schema exists. It does not explain what happens when neither ville nor code_postal is supplied, nor any error behavior, so it falls 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?

Three dense sentences, front-loaded with the core action before the sibling routing, return shape, and next step. The heavy use of parentheticals makes it slightly cramped, but no sentence is 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 correctly compensates by naming the key response fields and the result cap, and it links to the natural next tool call. Its only gap is the absence of guidance when no location filter is provided, which matters for a zero-required-parameter 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 all three parameters including the optionality relationship between ville and code_postal. The description only restates that the search is by city or postal code and never mentions the 'nom' filter, adding essentially nothing beyond the schema. 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 ('Recherche des masseurs-kinésithérapeutes inscrits sur MonRdvKiné (France)'), names the search keys (ville / code postal) and explicitly distinguishes itself from the sibling rechercher_kines_autour for GPS-based lookup. An agent can route between the two search tools 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?

Gives an explicit exclusion rule ('avec des coordonnées GPS, utiliser rechercher_kines_autour') and an explicit follow-up step ('Utiliser ensuite disponibilites_nouveau_patient avec PhysicianId'). It also caps expectations with 'Renvoie au plus 20 praticiens', so the agent knows not to expect exhaustive results.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: results are capped at 20, sorted nearest to farthest, DistanceKm is straight-line distance, and the key flags returned (AcceptsNewPatientsOnline, IsQueueListActive). What happens when more than 20 practitioners match within the radius is not stated.

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 dense sentences: what it searches, what it returns and in what order, then the next step. No filler, and the search scope is 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?

With no output schema, the description carries the return-value burden and does so: it names the result cap, ordering, distance semantics and two decision-relevant flags, plus the follow-up call. That is enough for an agent to call it correctly and chain 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?

Schema coverage is 100% with examples, default and maximum for rayon_km, so the baseline is 3. The description adds meaning beyond the schema by explaining where the latitude/longitude values come from (patient position or geocoded address), though it says nothing extra about the radius parameter.

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: searches masseurs-kinésithérapeutes registered on MonRdvKiné around GPS coordinates. The geographic scoping implicitly separates it from the sibling rechercher_kines (a name-based search), but the description never names that sibling explicitly, so differentiation is inferred rather than stated.

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?

Gives clear usage context: coordinates come from the patient's position or a geocoded address, and the tool is a first step in a workflow, followed by disponibilites_nouveau_patient with the returned PhysicianId. It stops short of stating when NOT to use it (e.g. searching by practitioner name), leaving that to the agent.

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