Same-day appointment openings in Quebec: hair, nails, massage, physio. No account needed.
Scored across 7 tools
Discovery tools (categories_et_villes vs chercher_places) are clearly distinct, but the booking flow splits across three tools that all target a business without online booking: preparer_demande (prefilled link), envoyer_code (code + request prep) and confirmer_code (code check + send). lien_alerte_texto and preparer_demande also both 'build a link and submit nothing', so an agent must read descriptions carefully to pick correctly, and confirmer_code conflates two jobs (send request / activate limits and return a mandate key).
Five of seven names follow a clean French verb_noun pattern (chercher_places, envoyer_code, confirmer_code, preparer_demande, proposer_limites) in snake_case throughout. Two outliers are noun phrases (categories_et_villes, lien_alerte_texto), a minor deviation but still readable and unambiguous.
Seven tools map neatly onto the domain's stages: browse, search, request, verify, alert, and mandate. Nothing looks padded or missing at the count level, and each tool has a distinct role in the workflow.
Discovery, self-serve request links, code-verified agent requests, alerts and agent mandates are all covered, but there is no way to check the status of a submitted request, cancel or modify a booking, or inspect/revoke an existing mandate (cancellation happens only out-of-band via STOP AGENT). These gaps will leave agents at a dead end after sending a request.
Les villes, les catégories et leurs services, avec le nombre de places libres par ville et par catégorie d'ici 7 jours. / Cities, categories and services, with the number of open spots per city and category over the next 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so safety behavior is covered. The description adds useful domain context by specifying the 7-day window and open-spot counts, but it does not describe response shape or grouping.
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 description is compact and front-loads the resource scope before the 7-day detail. The French/English duplication is appropriate for a bilingual catalog, though it repeats the same content rather than adding structure.
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 zero parameters and clear read-only annotations, the core invocation context is sufficient. However, the description lacks sibling differentiation and does not state how the returned cities/categories/services are structured, which matters because there is no output 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 are no parameter semantics to clarify. The baseline for a parameterless tool is 4, and the description does not introduce misleading parameter information.
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 the resources returned: cities, categories, services, and open spots per city/category over a 7-day horizon. It is specific about content and scope, but it does not explicitly distinguish this lookup tool from the sibling 'chercher_places'.
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 guidance on when to use this tool versus 'chercher_places' or 'lien_alerte_texto', nor any stated prerequisites or exclusions. The usage is only implied by the content description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cherche les places libres d'une ville, par catégorie, jour, moment et quartier, et au besoin par condition de santé ou par clientèle (commerces Dispolà Pro qui l'ont cochée). Rend l'établissement, le quartier, le service, l'heure, la durée, le prix et le lien pour réserver. Avec une catégorie, rend aussi sur_demande : des commerces sans réservation en ligne, avec des moments estimés à confirmer. / Finds open appointment spots in a city, by category, day, time of day and neighbourhood, optionally by health condition or clientele, with the booking link. With a category, also returns sur_demande: businesses without online booking, with estimated times to be confirmed by phone.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude, avec lng : trie du plus proche au plus loin. / Latitude, with lng: sorts nearest first. | |
| lng | No | Longitude, avec lat. / Longitude, with lat. | |
| jour | No | aujourdhui, demain ou AAAA-MM-JJ (heure de Montréal). / today, tomorrow or YYYY-MM-DD. | |
| ville | Yes | La ville, ou ailleurs : ailleurs au Québec, hors des villes du site (Trois-Rivières, Granby, Saguenay...) ; donne alors la ville de la personne dans quartier, ou lat et lng. / The city, or ailleurs: elsewhere in Quebec; then give the person's town in quartier, or lat and lng. | |
| limite | No | Nombre de places, 10 par défaut. / Max spots, default 10. | |
| moment | No | am : avant midi ; pm : de midi à 17 h ; soir : après 17 h. / morning, afternoon, evening. | |
| quartier | No | Un quartier, par exemple Plateau ou Limoilou : trie du plus proche au plus loin. / A neighbourhood: sorts nearest first. | |
| categorie | No | La catégorie (voir categories_et_villes). / The category. | |
| clientele | No | Une clientèle (femmes_enceintes, enfants, aines, mobilite_reduite...) : seulement les commerces Dispolà Pro qui l'ont cochée. Sans sur_demande. / A clientele: only Dispolà Pro businesses that checked it. | |
| condition | No | Une condition de santé (maux_de_dos, stress, commotion...) : seulement les commerces Dispolà Pro qui se disent à l'aise avec elle. Pas un diagnostic : ce que le ou la pro dit connaître. Sans sur_demande. / A health condition: only Dispolà Pro businesses that checked it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive safety, and the description adds genuinely new behavior: the exact result fields (établissement, quartier, service, heure, durée, prix, booking link) plus the conditional sur_demande block returned only when a category is supplied, with estimated times 'to be confirmed by phone'. It stops short of describing ordering guarantees or what an empty result means, so not 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?
Purpose and filter scope are front-loaded, and each sentence (return fields, then the sur_demande caveat) carries information. The full French/English duplication roughly doubles length, which is a deliberate bilingual choice rather than padding, but it does cost some density.
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 10 parameters, five enums and no output schema, the description does the important work of enumerating return fields and the conditional sur_demande payload, which the schema cannot convey. It leaves minor gaps around result ordering (beyond the 'nearest first' notes in the schema) and what happens when zero spots match.
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 every parameter is already documented in the schema, including the enums, defaults and limites cap. The description adds only the cross-parameter rule that categorie triggers sur_demande while clientele/condition disable it, which duplicates what those parameter descriptions already say. Baseline 3 is right.
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 ('Cherche les places libres') plus the full filter scope (ville, catégorie, jour, moment, quartier, condition, clientèle) and enumerates the returned fields. An agent can distinguish it from the sibling lookup tools (categories_et_villes, proposer_limites, preparer_demande) without opening any 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 implied rather than stated: the description notes that clientèle/condition narrow results to Dispolà Pro businesses and suppress sur_demande, and the category enum points to categories_et_villes for valid values. But it never explicitly says when to pick this tool over a sibling, nor any exclusion or precondition (e.g. whether it must follow proposer_limites or preparer_demande).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vérifie le code à 6 chiffres que la personne a reçu par texto après envoyer_code ou proposer_limites. Avec le bon code, une demande part chez Dispolà, qui appelle le commerce, ou des limites deviennent actives et l'outil rend la clé mandat. Un mauvais code est refusé. / Checks the 6-digit code the person received by text. Sends the request, or activates their limits and returns the mandate key. A wrong code is rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Les 6 chiffres reçus par la personne. / The 6 digits. | |
| reference | Yes | La référence rendue par envoyer_code ou proposer_limites. / The reference returned earlier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses meaningful side effects: with a correct code, a request goes to Dispolà and may trigger a merchant call, or limits become active and a mandate key is returned. It also states that a wrong code is refused. It does not discuss retry limits, code expiration, or detailed failure behavior, which keeps it short of fully comprehensive.
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 description is short and front-loads the verification purpose and consequences. The French and English versions duplicate the same content, which is useful for bilingual readers but not maximally concise for an agent.
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 two-parameter confirmation tool with no output schema, it covers the prerequisite tools, the success side effects, the returned mandate key, and rejection of a wrong code. It could say more about error responses or attempt limits, but the core information needed to invoke it correctly is 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%, so both parameters are already documented in the schema. The description restates that the code is 6 digits and the reference comes from earlier tools, but it adds no syntax or meaning beyond what the schema provides.
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 action (verify a 6-digit texted code) and its two possible outcomes: sending a request to Dispolà or activating limits and returning a mandate key. It also differentiates the tool from prerequisites by naming envoyer_code and proposer_limites, so an agent can tell where this fits in the flow.
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 clearly says to use this after envoyer_code or proposer_limites, which establishes the prerequisite context. It also states that a wrong code is rejected, but it does not name alternatives or explicitly cover when not to use it beyond that failure case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prépare la demande chez un commerce sur demande et texte à la personne un code à 6 chiffres, avec le texte exact de son accord. La personne lit ce code, et confirmer_code envoie la demande. Le prénom et le cellulaire sont ceux de la personne, pour elle-même. Avec mandat (la clé de confirmer_code après proposer_limites) et accepter_seul, une demande qui respecte toutes ses limites part sans code. / Prepares the request and texts the person a 6-digit code with the exact consent wording; confirmer_code sends it with that code. With a mandate key and auto-accept, a request within all their signed limits is sent without a code.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude, avec lng. / Latitude. | |
| lng | No | Longitude, avec lat. / Longitude. | |
| lieu | No | Où est la personne : code postal ou quartier. / Postal code or neighbourhood. | |
| heures | Yes | Au moins 2 heures de moments, séparées par des virgules, qui vont toutes à la personne. / At least 2 times from moments, comma-separated. | |
| langue | No | Langue des textos. / Text language. | fr |
| mandat | No | La clé mandat rendue par confirmer_code après proposer_limites. / Mandate key. | |
| prenom | No | Le prénom de la personne. / Their first name. | |
| service | Yes | Le service précis (champ services de sur_demande). / Precise service code. | |
| commerce | Yes | Le code du commerce (champ commerce de sur_demande). / Business code. | |
| cellulaire | No | Son cellulaire, Canada ou États-Unis. / Their mobile number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavioral context beyond the annotations: a 6-digit code is texted, the exact consent wording is included, and mandated requests can bypass the code step. However, destructiveHint=true and idempotentHint=false are never explained — nothing says that retrying issues another SMS/code or what state is overwritten. Since annotations cover the safety flags but the description leaves their practical consequences opaque, a 3 is appropriate.
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?
Compact and front-loaded: the core action and the code are in the first sentence, prerequisites and the auto-accept variant follow. The bilingual duplication doubles length but the French version carries all the information and nothing 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?
Ten parameters, no output schema, and a destructive external side effect. The description never says what the call returns — a code reference, a pending-request id, a send status — which the agent needs since there is no output schema. Everything about inputs and flow is covered; the return side is a genuine gap.
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 provenance and ownership meaning the schema does not: 'Le prénom et le cellulaire sont ceux de la personne, pour elle-même' and that the mandate key comes from confirmer_code after proposer_limites. It still does not explain the heures requirement (at least 2 slots derived from moments) or the lat/lng vs lieu choice.
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 ('Prépare la demande chez un commerce', 'texte à la personne un code à 6 chiffres') and explicitly separates this tool from confirmer_code, which only sends the request. An agent can tell from the description alone that this is the code-issuing step in a two-step flow.
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?
Explicit routing: use this to prepare and text the code, then use confirmer_code with that code to actually send. It also names the precondition path ('la clé de confirmer_code après proposer_limites') and the exception where no code is needed (mandate key + accepter_seul within all signed limits). Both alternatives are named by tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Construit le lien du formulaire prérempli d'alerte texto quand aucune place ne convient. La personne l'ouvre, entre elle-même son cellulaire et consent aux textos ; l'outil ne soumet rien. / Builds a prefilled text alert form link; the person enters their own number and consents. The tool submits nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| jour | No | aujourdhui, demain ou AAAA-MM-JJ (heure de Montréal). / today, tomorrow or YYYY-MM-DD. | |
| ville | Yes | La ville. / The city. | |
| langue | No | Langue du formulaire. / Form language. | fr |
| moment | No | am : avant midi ; pm : de midi à 17 h ; soir : après 17 h. / morning, afternoon, evening. | |
| service | No | Le code du service, par exemple ongles.gel (voir categories_et_villes). / Service code. | |
| quartier | No | Le quartier de la personne. / Their neighbourhood. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered; the description adds the genuinely useful behavioral fact that the end user enters their own number, gives consent, and 'l'outil ne soumet rien' — an important boundary no annotation conveys. No mention of link expiry or whether the URL is returned vs. displayed, but the key non-submission caveat is 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?
Two short sentences per language, with the purpose front-loaded and the non-submission caveat as the follow-up. The bilingual duplication adds length but is a deliberate mirror, not padding.
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 link builder with a fully documented schema and no output schema, the description covers purpose, trigger condition, and the user-consent boundary. Only the shape of the result (a URL string) and any link validity window are left implicit.
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 4 of 6 parameters carry enums with inline descriptions, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond what the schema documents, giving the baseline 3.
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 ('Construit le lien du formulaire prérempli d'alerte texto') plus the fallback condition 'quand aucune place ne convient', which implicitly separates it from chercher_places and preparer_demande. It never names a sibling tool outright, so the differentiation is inferential rather than explicit.
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?
'quand aucune place ne convient' gives a clear trigger condition for when to call this instead of the booking/search tools. It stops short of stating what to do first (e.g. only after chercher_places returns nothing) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bâtit le lien de la demande chez un commerce sans réservation en ligne (sur_demande de chercher_places), avec les heures, le service et le lieu de la personne déjà choisis. La personne l'ouvre, vérifie, entre elle-même son prénom et son cellulaire et consent ; Dispolà appelle le commerce et lui texte l'heure confirmée. L'outil ne soumet rien. / Builds the prefilled request link for a business without online booking, with the person's times, service and location filled in. The person opens it, enters their own name and number and consents; Dispolà calls the business. The tool submits nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude de la personne, avec lng (arrondie à 100 m). / Latitude, with lng. | |
| lng | No | Longitude, avec lat. / Longitude, with lat. | |
| lieu | No | Où est la personne : code postal ou quartier, pour un commerce de rechange proche d’elle. / Postal code or neighbourhood. | |
| heures | No | Les heures qui vont à la personne, prises dans moments de sur_demande, séparées par des virgules : au moins 2, en cas que la première soit prise. Ex. 2026-10-29T14:00,2026-10-29T15:00. / Times from sur_demande moments, comma-separated, at least 2. | |
| langue | No | Langue du formulaire. / Form language. | fr |
| service | No | Le service précis (champ services de sur_demande, ex. coupe-courts). / Precise service code. | |
| commerce | Yes | Le code du commerce (champ commerce de sur_demande). / Business code (commerce field of sur_demande). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this with 'L'outil ne soumet rien' plus the post-call sequence (person consents, Dispolà calls the business and texts the confirmed time). That workflow context genuinely exceeds what annotations convey, though the response payload a caller receives remains unspecified.
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 bilingual pairing doubles length but each version is two dense sentences with the outcome and the non-submission caveat front-loaded. No filler sentences; every clause carries workflow meaning.
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?
Annotations cover the safety profile, the schema fully documents all seven parameters, and the description supplies the missing behavioral picture — what the link does, who fills it in, and what happens after. No output schema is needed since the tool returns a link only.
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 each parameter already documents its origin (sur_demande fields, comma-separated heures, lat/lng pairing). The description only restates that times, service and location get filled in, adding 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 artifact — building a prefilled request link for a business without online booking — and anchors it in the sibling tool it depends on (sur_demande de chercher_places). An agent can distinguish this from lien_alerte_texto or chercher_places without opening a 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?
Clearly scopes the tool to businesses with no online booking and explains the handoff workflow, plus an implicit exclusion ('the tool submits nothing'). It does not name an explicit alternative for businesses that do have online booking, so the when-not side is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose les limites dans lesquelles un agent peut demander pour la personne (le mandat ouvert d'AP2) : catégorie, services, jours (au plus 14), heures, lieu et rayon, prix max, et envoi sans code ou non. Dispolà les lui texte mot pour mot avec un code ; confirmer_code, avec ce code, rend la clé mandat. La personne peut tout annuler en textant STOP AGENT. / Proposes limits within which an agent may request on the person's behalf, texted to them word for word and signed with a text code.
| Name | Required | Description | Default |
|---|---|---|---|
| au | No | Dernier jour, au plus 14 jours d'ici. Les limites expirent ce soir-là. / Last day; limits expire that night. | |
| du | No | Premier jour, AAAA-MM-JJ. Demain par défaut. / First day. | |
| lieu | No | Code postal ou quartier de la personne. / Postal code or neighbourhood. | |
| apres | No | Pas avant cette heure, HH:MM. / Not before. | |
| avant | No | Pas après cette heure, HH:MM. / Not after. | |
| ville | Yes | La ville. / The city. | |
| langue | No | Langue des textos. / Text language. | fr |
| prenom | Yes | Le prénom de la personne. / Their first name. | |
| prix_max | No | Prix max en dollars. Inconnu d’avance chez un commerce sur demande : Léon le vérifie au téléphone. / Max price. | |
| rayon_km | No | Distance max du lieu, 3 km par défaut. / Max distance. | |
| services | No | Les services permis (codes de services de sur_demande), séparés par des virgules. Sans : toute la catégorie. / Allowed service codes. | |
| categorie | Yes | La catégorie. / The category. | |
| cellulaire | Yes | Son cellulaire. / Their mobile number. | |
| accepter_seul | No | oui : une demande qui respecte tout part sans code. non : un code à chaque demande. / Auto-accept. | non |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructive/openWorld annotations, the description discloses that the limits are texted word for word with a code, that confirmer_code returns the mandate key, and that the person can cancel everything by texting STOP AGENT. It leaves some gaps around return values and replacement behavior when limits already exist.
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 description is information-dense and front-loads the core proposal and confirmation flow. The bilingual repetition slightly lengthens it, but each sentence carries relevant behavioral or procedural 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 complex 14-parameter mutation with no output schema, the description adequately explains the proposal-and-code workflow and the cancellation path. It still does not describe what proposer_limites returns or how errors are surfaced, so it is strong but not 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 100%, and the schema already explains every parameter in bilingual detail. The description only maps the concepts at a high level, adding little parameter-level meaning beyond what the schema provides.
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 opens with a specific verb and resource: it proposes signing limits for an agent mandate. It enumerates the exact dimensions covered (category, services, days, hours, location/radius, max price, auto-accept) and distinguishes the follow-up role of confirmer_code.
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 clearly frames the tool as the proposal step that texts a code, with confirmer_code as the next step using that code. It does not explicitly say when not to use it or how it differs from envoyer_code, but the workflow context is clear.
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.
chercher_places2 fields changedInput schema / properties / clienteleAdded value: +{
+ "description": "Une clientèle (femmes_enceintes, enfants, aines, mobilite_reduite...) : seulement les commerces Dispolà Pro qui l'ont cochée. Sans sur_demande. / A clientele: only Dispolà Pro businesses that checked it.",
+ "enum": [
+ "femmes_enceintes",
+ "bebes",
+ "enfants",
+ "ados",
+ "aines",
+ "couples",
+ "familles",
+ "lgbtq",
+ "autisme",
+ "diabete",
+ "deficience_intellectuelle",
+ "sourdes",
+ "mobilite_reduite"
+ ],
+ "type": "string"
+}Input schema / properties / conditionAdded value: +{
+ "description": "Une condition de santé (maux_de_dos, stress, commotion...) : seulement les commerces Dispolà Pro qui se disent à l'aise avec elle. Pas un diagnostic : ce que le ou la pro dit connaître. Sans sur_demande. / A health condition: only Dispolà Pro businesses that checked it.",
+ "enum": [
+ "acouphenes",
+ "arthrite",
+ "arthrose",
+ "atm",
+ "blessures_sportives",
+ "bursite",
+ "cancer",
+ "canal_carpien",
+ "capsulite",
+ "circulation",
+ "commotion",
+ "coup_de_fouet",
+ "douleur_chronique",
+ "entorse",
+ "epicondylite",
+ "fasciite_plantaire",
+ "fatigue",
+ "hernie_discale",
+ "maux_de_cou",
+ "maux_de_dos",
+ "maux_de_tete",
+ "menopause",
+ "oedeme",
+ "plancher_pelvien",
+ "posture",
+ "inflammation",
+ "readaptation",
+ "sciatique",
+ "scoliose",
+ "sommeil",
+ "stress",
+ "tendinite",
+ "torticolis",
+ "digestif"
+ ],
+ "type": "string"
+}lien_alerte_texto1 field changedInput schema / properties / service / enumPrevious value: -[
- "coiffure.coupe_femme",
- "coiffure.coupe_homme",
- "coiffure.coloration",
- "coiffure.mise_en_plis",
- "coiffure.barbe",
- "ongles.gel",
- "ongles.manucure",
- "ongles.remplissage",
- "ongles.pedicure",
- "cils.classique",
- "cils.hybride",
- "cils.volume",
- "cils.remplissage",
- "cils.rehaussement",
- "sourcils.restructuration",
- "sourcils.teinture",
- "sourcils.laminage",
- "sourcils.fil",
- "esthetique.soin_visage",
- "esthetique.cire",
- "esthetique.bresilienne",
- "massotherapie.suedois",
- "massotherapie.therapeutique",
- "massotherapie.tissus_profonds",
- "massotherapie.prenatal",
- "massotherapie.sportif",
- "massotherapie.drainage_lymphatique",
- "tatouage.flash",
- "tatouage.petit",
- "tatouage.retouche",
- "physiotherapie.evaluation",
- "physiotherapie.traitement",
- "osteopathie.traitement",
- "kinesiologie.seance",
- "therapie_sport.traitement",
- "chiropratique.traitement",
- "acupuncture.seance"
-]New value: +[
+ "coiffure.coupe_femme",
+ "coiffure.coupe_homme",
+ "coiffure.coloration",
+ "coiffure.mise_en_plis",
+ "coiffure.barbe",
+ "ongles.gel",
+ "ongles.manucure",
+ "ongles.remplissage",
+ "ongles.pedicure",
+ "cils.classique",
+ "cils.hybride",
+ "cils.volume",
+ "cils.remplissage",
+ "cils.rehaussement",
+ "sourcils.restructuration",
+ "sourcils.teinture",
+ "sourcils.laminage",
+ "sourcils.fil",
+ "esthetique.soin_visage",
+ "esthetique.cire",
+ "esthetique.bresilienne",
+ "massotherapie.suedois",
+ "massotherapie.therapeutique",
+ "massotherapie.tissus_profonds",
+ "massotherapie.prenatal",
+ "massotherapie.sportif",
+ "massotherapie.drainage_lymphatique",
+ "massotherapie.orthotherapie",
+ "massotherapie.kinesitherapie",
+ "tatouage.flash",
+ "tatouage.petit",
+ "tatouage.retouche",
+ "physiotherapie.evaluation",
+ "physiotherapie.traitement",
+ "osteopathie.traitement",
+ "kinesiologie.seance",
+ "kinesiologie.evaluation",
+ "kinesiologie.entrainement",
+ "therapie_sport.traitement",
+ "chiropratique.traitement",
+ "acupuncture.seance"
+]chercher_places2 fields changedInput schema / properties / ville / descriptionPrevious value: -"La ville. / The city."New value: +"La ville, ou ailleurs : ailleurs au Québec, hors des villes du site (Trois-Rivières, Granby, Saguenay...) ; donne alors la ville de la personne dans quartier, ou lat et lng. / The city, or ailleurs: elsewhere in Quebec; then give the person's town in quartier, or lat and lng."Input schema / properties / ville / enumPrevious value: -[
- "montreal",
- "quebec",
- "sherbrooke",
- "gatineau",
- "rive-nord",
- "rive-sud"
-]New value: +[
+ "montreal",
+ "quebec",
+ "sherbrooke",
+ "gatineau",
+ "rive-nord",
+ "rive-sud",
+ "ailleurs"
+]proposer_limites1 field changedInput schema / properties / ville / enumPrevious value: -[
- "montreal",
- "quebec",
- "sherbrooke",
- "gatineau",
- "rive-nord",
- "rive-sud"
-]New value: +[
+ "montreal",
+ "quebec",
+ "sherbrooke",
+ "gatineau",
+ "rive-nord",
+ "rive-sud",
+ "ailleurs"
+]lien_alerte_texto1 field changedInput schema / properties / service / enumPrevious value: -[
- "coiffure.coupe_femme",
- "coiffure.coupe_homme",
- "coiffure.coloration",
- "coiffure.mise_en_plis",
- "coiffure.barbe",
- "ongles.gel",
- "ongles.manucure",
- "ongles.remplissage",
- "ongles.pedicure",
- "cils.classique",
- "cils.hybride",
- "cils.volume",
- "cils.remplissage",
- "cils.rehaussement",
- "sourcils.restructuration",
- "sourcils.teinture",
- "sourcils.laminage",
- "sourcils.fil",
- "esthetique.soin_visage",
- "esthetique.cire",
- "esthetique.bresilienne",
- "massotherapie.suedois",
- "massotherapie.therapeutique",
- "massotherapie.tissus_profonds",
- "massotherapie.prenatal",
- "tatouage.flash",
- "tatouage.petit",
- "tatouage.retouche",
- "physiotherapie.evaluation",
- "physiotherapie.traitement",
- "osteopathie.traitement",
- "kinesiologie.seance",
- "therapie_sport.traitement",
- "chiropratique.traitement",
- "acupuncture.seance"
-]New value: +[
+ "coiffure.coupe_femme",
+ "coiffure.coupe_homme",
+ "coiffure.coloration",
+ "coiffure.mise_en_plis",
+ "coiffure.barbe",
+ "ongles.gel",
+ "ongles.manucure",
+ "ongles.remplissage",
+ "ongles.pedicure",
+ "cils.classique",
+ "cils.hybride",
+ "cils.volume",
+ "cils.remplissage",
+ "cils.rehaussement",
+ "sourcils.restructuration",
+ "sourcils.teinture",
+ "sourcils.laminage",
+ "sourcils.fil",
+ "esthetique.soin_visage",
+ "esthetique.cire",
+ "esthetique.bresilienne",
+ "massotherapie.suedois",
+ "massotherapie.therapeutique",
+ "massotherapie.tissus_profonds",
+ "massotherapie.prenatal",
+ "massotherapie.sportif",
+ "massotherapie.drainage_lymphatique",
+ "tatouage.flash",
+ "tatouage.petit",
+ "tatouage.retouche",
+ "physiotherapie.evaluation",
+ "physiotherapie.traitement",
+ "osteopathie.traitement",
+ "kinesiologie.seance",
+ "therapie_sport.traitement",
+ "chiropratique.traitement",
+ "acupuncture.seance"
+]confirmer_code1 field changedInput schema / properties / code / descriptionPrevious value: -"Les 6 chiffres lus par la personne. / The 6 digits."New value: +"Les 6 chiffres reçus par la personne. / The 6 digits."proposer_limites1 field changedInput schema / properties / accepter_seul / descriptionPrevious value: -"oui : tu peux envoyer seul une demande qui respecte tout. non : un code à chaque demande. / Auto-accept."New value: +"oui : une demande qui respecte tout part sans code. non : un code à chaque demande. / Auto-accept."confirmer_codeenvoyer_codeproposer_limitespreparer_demandecategories_et_villeschercher_placeslien_alerte_textoSearch and book appointments at local businesses. Barbershops, salons, spas, and more.
Find, compare, and book local service businesses: live availability, prices, reviews, booking.
Find local services, check live availability, and book real appointments with consent.
Discover local services and availability, then create, track, reschedule, or cancel bookings.
Add one secure layer between your agents and this server.