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

The readOnlyHint annotation already declares that this is a safe read operation. The description adds the specific return data (the type-to-ID mapping) but does not disclose additional behavioral traits such as pagination, rate limits, or side effects. With annotations present, this meets the baseline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the verb and resource, and includes the essential mapping inline. 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?

For a simple, parameterless tool with no output schema, the description fully explains the return value by enumerating all six activity type IDs and their meanings. This is complete for the tool's purpose.

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 has zero parameters, and the baseline for zero parameters is 4. The description does not need to explain parameter semantics since there are none, and the schema already reflects this with an empty properties object.

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 (list) and resource (activity types) and provides the exact mapping of IDs to type names. This distinguishes it from sibling tools like corymbus_list_activities, which lists activities themselves.

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 clearly communicates that this tool returns the catalog of activity types and their IDs, making it obvious when to use it (whenever you need to interpret activity type codes). It does not explicitly mention alternatives or exclusions, but the context is clear enough.

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 readOnlyHint annotation already discloses the safe read-only nature. The description adds minimal behavioral context beyond what the annotation provides, such as noting that nameContains works only if supported by the entity, which is also in the schema. No extra details about response format or rate limits are given.

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, focused sentence that introduces the tool and lists key parameters efficiently. No wasted words, and the most important information (secondary entities) 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 7 parameters, an entity enum, and no output schema, the description is adequate but leaves gaps. It does not explain differences across entity types, return structures, or any entity-specific limitations beyond the schema's note on nameContains. It is sufficient for a straightforward list tool but not rich enough for high completeness.

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 descriptions cover 100% of parameters, so the description adds little beyond restating a few parameter names. The baseline of 3 applies because the schema does the heavy lifting, and the description provides no additional semantic 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 clearly states the tool's purpose as a generic list for secondary entities, enumerating the specific entity types (campaign, target, user, subscription, filter, team, document, product, quote). This distinguishes it from sibling tools that list accounts, contacts, opportunities, and activities.

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 implied usage context by labeling the tool as for secondary entities, which hints that primary entities have dedicated list tools. However, it does not explicitly state when to use this tool versus the sibling list tools or provide any 'when not to use' 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=true, and the description adds useful behavioral context: it notes that custom tenant fields are returned as-is in each object, which is extra transparency about the response shape. No contradictory behavior is described.

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-loading the primary purpose and then adding one relevant behavioral note. Every sentence earns its place 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?

Given the tool's simplicity, rich schema, and readOnly annotation, the description is complete: it covers purpose, filters, and custom field behavior. No output schema is needed, and the absence of pagination details is compensated by schema descriptions.

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 provides 100% coverage with descriptions for all 8 parameters, including default values and filters. The tool description merely repeats a few filter names (nameContains, owner, activity) without adding meaning beyond the schema, so it meets the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Liste/recherche') and resource ('comptes (entreprises)'), distinguishing it from sibling list tools for contacts, opportunities, and activities. The mention of filters further clarifies its 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 clear context: this tool is for listing/searching account records, with specific filter parameters mentioned. It does not explicitly compare to sibling tools, but the resource-specific naming makes the intended use evident.

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?

With readOnlyHint=true annotation, the read-only nature is already declared. The description adds practical behavior by mentioning filters and sorting recommendation ('Trier par start DESC'), which goes beyond the annotation. However, it does not disclose response format, pagination behavior, or any other operational details beyond what the schema and annotation already cover.

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 front-load the purpose, then list filters and a sort tip. It avoids unnecessary verbosity while packing relevant info. The only minor issue is the density of parentheses with IDs, but it remains clear and efficient.

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?

The schema thoroughly covers all 9 parameters, and the description provides the core purpose and a useful sort hint. However, since there is no output schema, the response format is not described anywhere, and neither the description nor annotations clarify what the tool returns. For a list operation, this is a notable 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 description coverage is 100%, providing full parameter documentation. The description adds extra value by summarizing the key filter parameters and providing a specific sort example ('start' DESC) that is not in the schema, offering practical guidance for using order_field. This goes slightly beyond the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Liste/recherche les activités' (list/search activities), enumerates the activity types covered, and specifies the filterable entity types. This distinguishes it from sibling list tools like corymbus_list_accounts or corymbus_list_contacts, which target different resources.

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 usage for activity-related listing/searching via its resource focus and filter list, but it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. There is no mention of 'use this instead of' or conditions for other tools. Usage is implied rather than clearly guided.

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?

L'annotation readOnlyHint=true est cohérente avec 'liste/recherche'. La description n'ajoute pas de détails comportementaux supplémentaires, mais ce n'est pas indispensable étant donné l'annotation et la simplicité de l'opération.

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?

Phrase unique et structurée, les filtres sont listés après un deux-points. Aucune redondance, chaque mot apporte de la valeur.

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?

Outil simple de lecture seule, avec un schéma complet et une annotation appropriée. La description suffit pour comprendre l'usage, même si le format de retour n'est pas explicite, ce qui est implicite pour une lister.

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?

La couverture du schéma est de 100%, chaque paramètre étant déjà décrit. La description répète les noms de filtres sans ajouter de sémantique nouvelle, à part préciser que 'target' correspond à un groupe ce qui est un léger apport.

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?

La description utilise un verbe clair 'Liste/recherche' avec la ressource 'contacts' et précise les filtres. Elle se distingue nettement des outils frères dédiés aux comptes, opportunités et activités.

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?

Le contexte d'utilisation est clair : outil pour lister/rechercher des contacts, avec des filtres pour divers cas. Aucune alternative n'est mentionnée explicitement, mais l'absence d'exclusions est compensée par la clarté du champ d'application.

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, and the description adds valuable context: status IDs depend on tenant pipeline configuration, and status_label provides the human-readable label. It also enumerates valid expected_close_date periods, which is non-obvious behavior. No contradictions with 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 two sentences: the first front-loads the purpose and filters; the second adds a crucial caveat about status IDs. Every sentence earns its place, with no redundant phrasing.

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 list tool with schema covering all parameters, the description addresses key filters and a significant tenant-configuration nuance. It does not spell out the return shape, but given the straightforward list semantics and lack of output schema, this is a minor omission.

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 elevates it by explicitly listing all valid expected_close_date periods and explaining the tenant-dependent nature of status IDs. This goes beyond the schema, which refers to 'voir description' for that 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?

The description uses a specific verb-resource pair, 'Liste/recherche les opportunités (deals)', clearly distinguishing it from sibling list tools for accounts, contacts, and activities. The inclusion of 'deals' as an alias further clarifies the resource.

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 clear context for when to use the tool (listing/searching opportunities with filters) but does not explicitly mention alternatives or state when not to use it. Usage is implied rather than directly contrasted with sibling 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?

Annotations already indicate readOnlyHint=false, but the description adds crucial context: 'Peut écrire selon method/path' (may write depending on method/path), which warns of mutation risk. This exceeds the annotation information, though it doesn't detail other behaviors like auth or error handling.

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 very concise: two sentences, front-loaded with purpose and warning, no fluff. The emoji warning effectively calls attention to the write risk.

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 raw request tool with no output schema, the description sufficiently covers purpose, usage, parameter hints, and side-effect risk. It doesn't explain return values, but that's expected for a raw API wrapper. Overall, it's complete for practical use.

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 descriptions cover all parameters with decent detail (method enum, path format, query example). The description adds that body/query are optional and reinforces method and path constraints. Since schema coverage is high, the description adds marginal but useful guidance.

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 it is a 'raw call to the Corymbus API for endpoints not covered by a dedicated tool,' which identifies the specific verb ('call') and resource (Corymbus API). It distinguishes itself from siblings by explicitly noting it covers endpoints without a dedicated tool.

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 when to use it: for endpoints not covered by a dedicated tool. This implies that dedicated sibling tools should be preferred when available. It also warns that it can write, guiding careful usage.

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 explicitly warns '⚠️ Écrit dans le CRM de production', adding important behavioral context about writing to a production system, which the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) do not convey. It also clarifies the create/update branch based on id presence. No contradiction with annotations; the production warning is a valuable addition.

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 one short sentence with a warning symbol, immediately conveying the core function and production warning. It is front-loaded and every word earns its place. No unnecessary fluff.

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 9 parameters, no output schema, and a production-write side effect, the description is too sparse. It does not explain what fields mean, how extra_fields merges, return values, error possibilities, or any constraints. The production warning is helpful but does not make the tool usable without schema lookup, and the schema only documents two parameters. Significant gaps remain.

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?

With schema coverage at only 22%, the description should compensate for undocumented parameters. It explains the id parameter's role (omit/create, provide/update), echoing the schema, but gives no semantics for the other seven parameters (name, owner, phone, country, website, description, billing_address). The extra_fields object is mentioned in the schema but not in the description. The description adds minimal value 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 clearly states the tool creates an account when no id is provided and updates when an id is provided, using a specific verb ('Crée'/'met à jour') and resource ('un compte'). It distinguishes itself from sibling tools by focusing on account upsert, similar to upsert_contact but for a different entity.

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 clear context on when to use the tool: create without id, update with id. It does not explicitly mention alternatives or exclusions, but the context is well-defined for the upsert operation. The sibling list includes read-only tools (list_accounts), but the description doesn't directly say 'use those for reading'—a minor gap.

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 warning 'Écrit dans le CRM de production' adds critical side-effect context beyond the annotations (which already indicate a non-read-only mutation). It also honestly notes that the creation schema is undocumented and advises verifying the result, adding transparency about reliability.

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 followed by a crucial warning. It front-loads the primary purpose (create/update) and packs the type mapping and production write warning without any wasted words.

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?

The description covers the upsert semantics, type enum, production impact, and undocumented creation schema. While it doesn't describe return values (no output schema), the schema covers most parameters, and the tool's behavior is sufficiently clear for an upsert operation.

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 covers 83% of parameters with descriptions. The description adds extra value by mapping type values (1=Tâche, 2=Appel entrant, etc.) and clarifying the id semantics (omit for create, provide for update), which enriches 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 clearly states that the tool creates (without id) or updates (with id) an activity, and enumerates activity subtypes (task, call, appointment, note, email). It distinguishes itself from sibling upsert tools for accounts, contacts, and opportunities by explicitly naming the resource type.

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 clear usage guidance on when to create vs. update based on presence of id, and warns that it writes to production. It does not explicitly mention alternatives or when not to use it, but the resource-specific wording makes the intended use obvious.

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 indicate this is a mutable operation (readOnlyHint: false), but the description adds a meaningful warning: '⚠️ Écrit dans le CRM de production' (Writes to the production CRM). This flags the side effect of impacting production data, which goes beyond the binary annotation flags. It lacks further detail on irreversibility or permission requirements, but the warning is valuable.

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, concise sentence that front-loads the core operation and includes an essential production-impact warning. Every word earns its place; there is no redundancy or 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?

With 14 parameters, no required fields, and no output schema, the description is under-specified. It covers the create/update distinction but omits information about input constraints, validation rules, response format, or error behavior. The agent would need to rely on an incomplete schema and infer the rest, which is risky for a production-mutating 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 only 21% (3 of 14 properties have descriptions), and the tool description provides no parameter-specific information beyond the already-schema-documented id semantics. Most parameters (email, owner, lastname, extra_fields, etc.) remain undocumented in both schema and description, leaving the agent without guidance on how to populate fields correctly.

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 verb and resource: 'Crée (sans id) ou met à jour (avec id) un contact' (creates or updates a contact). It explicitly distinguishes create vs. update based on presence of 'id', and the resource 'contact' differentiates it from sibling upsert tools for accounts, opportunities, and activities.

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 clear usage context by specifying that omitting 'id' creates a contact and providing 'id' updates one. This directly guides the main decision when invoking the tool. However, it does not mention when to prefer alternative tools (e.g., list_contacts for reading, raw_request for custom operations) or exclude inappropriate scenarios.

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?

Les annotations ne révèlent pas la nature de l'écriture (readOnlyHint=false, destructiveHint=false), mais la description compense en prévenant que l'outil écrit dans le CRM de production. L'avertissement sur les champs non documentés et l'invitation à vérifier le résultat ajoute une transparence supplémentaire.

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?

La description est concise avec deux phrases. Chaque phrase apporte une information utile : l'action et les précautions. Pas de superflu.

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?

Avec 10 paramètres, aucune sortie décrite et un objet imbriqué, la description est trop courte pour être complète. Elle ne détaille pas les règles de validation, le format de réponse ou les erreurs possibles. L'absence d'informations sur de nombreux paramètres laisse l'agent mal équipé.

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?

Le schéma fournit des descriptions pour 5 paramètres sur 10 (50%). La description ajoute la sémantique de l'id (création vs mise à jour) mais ne compense pas le manque d'informations sur les autres paramètres comme name, owner, amount, etc. L'avertissement reste vague.

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?

La description indique clairement le comportement upsert : créer sans id, mettre à jour avec id, pour une opportunité. Cela permet de la distinguer des outils frères (upsert_account, upsert_contact, etc.).

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?

Le guide d'utilisation est implicite : l'id détermine s'il faut créer ou mettre à jour. Bien qu'aucune alternative ne soit nommée, la logique conditionnelle est un guide clair. L'avertissement sur les champs non documentés donne un contexte d'utilisation.

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 annotation readOnlyHint=true already indicates a safe read operation. The description adds nothing beyond that, but does not contradict. For a simple, non-destructive version getter, additional behavioral detail is not necessary, so the baseline is acceptable.

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, focused sentence. It is front-loaded with the action and resource, and there is no redundancy or wasted 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?

Given the tool's simplicity (no parameters, no output schema, read-only annotation), the description is complete. It fully conveys the purpose and requires no further elaboration for an agent to select and invoke it 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 tool has zero parameters, so the schema covers 100% of what exists. The description does not need to explain parameters, and the baseline for zero params is 4.

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 with a specific verb ('Renvoie' = returns) and resource ('la version du serveur Corymbus'). It is unambiguous and distinguishes itself from siblings, none of which are version-specific.

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 usage: use when you need the server version. It gives no explicit guidance on when to use this tool versus alternatives, but given its specialized purpose, alternatives are not obvious. Context is minimal.

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 declare readOnlyHint=true, so the agent knows it is safe. The description adds that it returns the authenticated user's name and email, and implies authentication state, but does not mention error handling or auth failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence that fully communicates the tool's purpose and output without waste.

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 whoami tool with an output schema absent, the description fully covers what the agent needs to know: what it returns and that it pertains to the authenticated user. The annotation covers safety.

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 has zero parameters, so the baseline is 4. The description adds no param semantics because none exist.

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 the specific verb 'Renvoie' (returns) and clearly identifies the resource: the currently authenticated Corymbus user, with fields name and email. This distinguishes it from sibling tools that operate on accounts, contacts, opportunities, etc.

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?

No explicit guidance is given about when to choose this tool over alternatives, but the purpose is self-evident from the name 'whoami' and the description, so usage is 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.