Constat Auto — Constat amiable

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

The description adds significant behavioral context beyond the annotations. While annotations indicate destructive and idempotent behavior, the description specifies exactly what is affected: 'invalide les liens de signature en circulation' (invalidates signature links in circulation) and the limitation 'Sans effet sur un constat déjà envoyé'. This is valuable, non-obvious context that annotations alone 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 description is two concise sentences, front-loaded with the primary action. It includes the key limitation in a separate short sentence, with no filler or redundant information. This is a model of efficient communication.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description covers the essential aspects: what it does, what it invalidates, and its non-effect on sent constats. Combined with the annotations (destructive, idempotent), it gives an agent sufficient understanding to select and invoke the tool correctly. No critical information 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% as the single parameter 'dossier' has a description in the schema. The tool description does not add any additional meaning about the parameter beyond what the schema already provides, so the baseline score of 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?

The description uses a specific verb 'Annule' (cancels) and clearly identifies the resource 'le dossier' and the secondary effect 'invalide les liens de signature'. It distinguishes itself from sibling constat tools by focusing on cancellation and invalidation of signature links. The final clause about no effect on an already sent constat further clarifies the scope.

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 provides a clear context for use: cancel a dossier and invalidate signature links. It explicitly states a limitation/exclusion: 'Sans effet sur un constat déjà envoyé' (no effect on an already sent constat), which tells the agent when this tool will not work. However, it does not name alternative tools or provide explicit when-to-use guidance, so it falls short of a 5.

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, idempotentHint=true, and destructiveHint=false. The description adds valuable integration context (what to do with the result, fallback behavior) beyond annotations, but does not disclose deeper behavioral details like pagination or response format, which is acceptable for a simple lookup.

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 two sentences, front-loaded with purpose, then provides integration and fallback details. Every sentence earns its place with no unnecessary repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter, no output schema), the description covers purpose, usage, integration with a sibling tool, and fallback behavior. Annotations provide safety context. This is complete for an agent to invoke the tool 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?

The input schema has one parameter ('recherche') with a clear description ('Début du nom de l'assureur. Vide pour obtenir la liste des partenaires.'), resulting in 100% schema coverage. The tool description does not add additional parameter semantics beyond reinforcing 'par son nom', so the baseline score of 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?

The description clearly states the tool's function: searching for an insurer or broker by name for the constat, and returning exact names for a specific field. It distinguishes itself from siblings by referencing constat_renseigner and the destinataire.assureur field.

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 guidance is provided: use the returned names in destinataire.assureur of constat_renseigner, and if the insurer is not found, use 'Autre' and fill destinataire.email_courtier. This gives clear when-to-use and fallback instructions.

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 destructiveHint=false. The description adds that no dossier is required and specifies the exact output (17 cases with advice), providing useful context beyond the annotations.

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 a single, information-dense sentence beginning with the main action. Every word earns its place, and there is no wasteful repetition of schema or annotation data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only reference tool, the description fully covers what is returned, that it is read-only, and that no dossier is needed. The absence of an output schema is acceptable given the tool's simplicity.

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 and the empty schema fully documents this. The description adds meaning by explaining what the tool returns, which is sufficient given there are no parameters to clarify.

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 clearly states the tool returns the 17 official circumstances boxes of the European amicable statement, with advice on choosing them. It uses a specific verb (renvoie) and resource, and the read-only note distinguishes it from sibling mutation tools like constat_annuler or constat_renseigner.

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 notes 'Lecture seule, aucun dossier requis' (read-only, no file required), which clarifies that it can be used as a standalone reference without needing an active constat. This gives clear context, though it doesn't explicitly list alternatives or exclusions.

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 mark the tool as destructive/mutating. The description adds valuable context beyond that: the sketch is automatically drawn and attached to the report, and the tool also returns the circumstances boxes and usual impact zones for confirmation. This exceeds annotation coverage without contradiction.

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 sentences, front-loaded with the main purpose, followed by workflow and next-step instructions. Every sentence contributes meaning with zero 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?

Given the complexity (12 params, no output schema), the description covers the essential workflow: what the tool produces (sketch, circumstances, impact zones) and how to proceed. The schema handles parameter details. Minor gap: it does not mention prerequisites like an existing dossier, but the schema's dossier description covers that.

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 detailed per-parameter descriptions. The description adds high-level selection guidance (choose scenario closest to the account, indicate which vehicle made the maneuver), which helps the agent map narrative to scenario and initiateur even though the schema already enumerates the options.

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 'Établit le croquis de l'accident' (establishes the accident sketch), a specific verb+resource pairing. It clearly distinguishes from sibling tools by stating it generates the sketch and returns circumstances, while constat_renseigner is mentioned as the recording step.

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 gives explicit procedural guidance: choose the closest scenario, indicate the maneuvering vehicle, and then use constat_renseigner only after driver confirmation. This names the sibling tool as the appropriate next step and clarifies when to use which tool.

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?

Even though annotations are present (all false), they provide limited safety context. The description adds behavioral details beyond annotations: the tool creates a new dossier, returns an identifier to reuse, and also returns a list of information to collect. It also warns that it should be called only once, implying non-idempotent behavior, which is valuable transparency.

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 concise and well-structured: three sentences each serving a distinct purpose (what it does, when to use it, what it also returns). There is no filler or redundancy, and key information 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?

Despite having no output schema, the description adequately explains the tool's outputs (identifier and list of info) and its role in the conversation flow. It covers the essential context for an initialization tool: what it returns, how to use the returned ID, and that it is the first step. The single optional parameter is fully documented in the 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 input schema fully covers the only parameter 'langue' with a description ('Langue du constat et des liens de signature. Par défaut fr.'). The tool description adds no additional parameter meaning, so the baseline of 3 applies given the high schema coverage.

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 clearly states the tool's action ('Ouvre un dossier de constat amiable') and its primary output ('renvoie son identifiant'). It distinguishes itself from sibling tools by being the initialization step in the workflow, even mentioning that the returned ID should be reused in all subsequent calls.

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 gives explicit timing guidance: 'À appeler une seule fois au début de la conversation.' It implies the tool is the entry point and should not be repeated, which is clear contextual usage. It does not explicitly name alternatives, but the role as the starting step is unambiguous.

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?

The description adds meaningful behavioral context beyond the annotations: it discloses that the tool sends an email, is idempotent (no effect if already sent), and that the unilateral declaration flag causes the constat to mention B's absence. These concrete details complement the generic destructiveHint and idempotentHint annotations.

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 three sentences, front-loaded with the main action, then typical use cases, and an important no-op warning. Every sentence carries useful information 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 tool with no output schema and two parameters, the description covers all essential aspects: the trigger condition, when it is normally unnecessary, the special unilateral declaration mode, and the idempotent behavior. No critical gaps remain for selection or 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?

Both parameters are fully documented in the schema, including the condition for envoyer_sans_signature_b (explicit user request with awareness of consequences). The description does not add new parameter-level information beyond what the schema provides, so the baseline score 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?

The description clearly states the action: 'Vérifie l'envoi du constat, et le déclenche si les signatures sont réunies' — it verifies and triggers sending the constat. It distinguishes from sibling tools by noting it normally happens automatically and by specifying a special use case (unilateral declaration).

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 explicitly says the tool is 'Normalement inutile' and explains its main uses: confirming sending or producing a unilateral declaration when driver B never signs. It also warns that calling has no effect if already sent, guiding when not to invoke it and implicitly directing users to alternatives for status checks.

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 destructiveHint=true and idempotentHint=true, but the description adds crucial context beyond those: only provided fields are modified ('Seuls les champs fournis sont modifiés'), a strict no-invention policy discourages open-world assumptions, and modifying a signed constat invalidates signatures. These behavioral traits align with the annotations and add significant value.

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. The first states the purpose, the second explains the incremental calling pattern and field update rule, and the third warns about signed records. No redundancy, 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?

Given the tool's complexity (nested objects, 10 parameters, no output schema), the description covers the essential behavioral contract: partial updates, no invented values, and signature invalidation. It omits explicit cross-references to constat_demarrer for obtaining the dossier ID, but that is available in the schema. The description is sufficient for an agent to use the tool correctly within the workflow.

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 baseline is 3. The description elevates this by explaining partial-update semantics: 'Seuls les champs fournis sont modifiés' tells the agent that calling with a subset of fields won't clobber others. The instruction 'un champ inconnu doit rester absent' reinforces the closed-world behavior, which is not explicit in 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 opens with a specific verb+resource: 'Enregistre ou met à jour les informations du constat' (records/updates accident report info). It clearly distinguishes this tool from siblings like constat_demarrer (start) and constat_finaliser (finalize) by emphasizing incremental data entry and repeated calls.

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 explicitly instructs when to invoke: 'Appelez-le autant de fois que nécessaire, par petits groupes de champs, au fil de la conversation' – call it as often as needed, in small field groups. It also warns about modifying signed constats. However, it doesn't explicitly name alternative tools for starting/finalizing, though context signals make the usage clear.

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?

The description offers substantial behavioral detail beyond the annotations: links expire after 48 hours, are non-recoverable, and each new call invalidates previous unused links. It also discloses the automatic email dispatch on final signature. This aligns with destructiveHint=true and provides critical side-effect information an agent needs to handle the tool correctly.

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 three sentences, starts with the main action, and each sentence adds distinct value: the purpose, the legal importance and automatic email, and the link validity/invalidation behavior. No filler or 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 tool with no output schema and moderate complexity, the description covers the core behavior, side effects, and important constraints. It does not mention error cases or the exact return format, but the provided context on signature requirements and link management is sufficient for most invocation scenarios. Sibling tools and schema descriptions fill remaining gaps.

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?

Input schema coverage is 100%, with detailed descriptions for all parameters. The tool description does not add new parameter-level semantics; it only gives broader context about signatures and link validity. According to the rubric, baseline 3 is appropriate when the schema handles parameter documentation, and the description adds no extra parameter-specific value.

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: 'Émet les liens de signature à transmettre aux conducteurs' (emits signature links to transmit to drivers). This clearly defines the tool's function and distinguishes it from sibling constat tools that handle other steps like renseigner, finaliser, or annuler. The legal context reinforces the purpose: the constat only has legal value with both signatures.

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 implies when to use the tool: after the constat has been prepared, to collect signatures. It notes that the email sends automatically upon the last signature, which frames the expected workflow. It also warns that links are valid for 48h and a new call invalidates previous unused links, which guides repeated use. No explicit alternative tool is named, but the tool family context makes the usage context clear.

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?

The description states 'Lecture seule' (read-only), but the annotations declare readOnlyHint: false, which implies the tool may modify state. This is a direct contradiction. No other behavioral context is provided to compensate.

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 concise, with two sentences that communicate the purpose, key return values, and usage context. It is front-loaded with the main purpose and avoids unnecessary detail.

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 status tool with one parameter and no output schema, the description covers the main return values and usage timing. It lacks details about potential errors or edge cases, but these are not critical given the tool's simplicity.

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 input schema has 100% coverage for the single parameter 'dossier', which is described as the identifier returned by constat_demarrer. The tool description adds no additional parameter meaning beyond this, so a baseline score of 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?

The description clearly states the tool's purpose: providing the progress status of the file, including missing information, signature status, and whether the constat was sent. It uses a clear resource (the dossier) and distinguishes it from sibling tools that focus on individual aspects.

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 explicitly says 'À appeler avant de conclure quoi que ce soit sur l'avancement', giving clear context on when to use it. It also mentions a specific use case (checking if driver B filled their part), but does not discuss when not to use it or alternative tools.

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?

The annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds concrete behavior by specifying the return JSON structure (id, titre, URL, texte) and 'contenu complet', which is not covered by annotations.

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, front-loaded sentences: the first states the purpose and input source, the second states the output format. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple parameter tool with clear annotations and a detailed parameter schema, the description sufficiently explains the action, input, and return value. It does not need to cover error cases or elaborate formatting.

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 schema already provides a full description for the single parameter `id` (Identifiant du document renvoyé par `search`), and the tool description merely restates this relationship without adding further semantics. Schema coverage is 100%, so 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?

The description clearly states the verb 'Récupère' (fetches) and the resource 'guide de constat-auto.com' using an identifier from `search`. It distinguishes from sibling tools by specifying that it retrieves full guide content for a document ID, not constat-related operations.

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 says the identifier must come from `search`, indicating that this tool should be used after a search to retrieve full content. It names the source of the ID, effectively providing a prerequisite, though it does not explicitly list exclusions or alternatives.

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 read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond this by detailing the return fields (identifier, title, URL, excerpt) and the follow-up action with fetch, which is especially helpful given no output schema exists.

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 concise, consisting of two well-structured sentences that immediately convey the purpose, then the output format, and finally the next step. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool with one parameter and no output schema, the description fully covers the search scope, return format, and how to proceed. It's complete and actionable for an agent.

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 schema fully describes the only parameter (query) with a natural language description, so the description doesn't need to add more. It adds no extra semantics beyond what the schema provides, making the baseline score of 3 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?

The description clearly states the tool searches practical guides on constat-auto.com with specific topics, and explicitly mentions the JSON result format with identifier, title, URL, and excerpt. It distinguishes from siblings by directing users to use `fetch` with the identifier for reading full guides, making its role unique.

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 implies its use for finding guides and explicitly instructs to use `fetch` next, providing a clear workflow. However, it doesn't explicitly state when not to use this tool or mention alternatives like the constat_* tools, though the context makes it implicit.

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