Server Quality Checklist

Tool Scores

• get_emailsA
  4/5.0
  Behavior4/5

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

  With no annotations, the description must carry the burden of behavioral disclosure. It does so well: clarifies performance (never opens message files), return behavior (opaque keys, not row numbers), ordering (newest first), and filtering (deleted excluded). It does not mention auth or rate limits, which are expected to be handled elsewhere.

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

  Conciseness5/5

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

  The description is three concise sentences. The first conveys the main purpose and filters, the second adds performance and safety context, and the third clarifies return keys and deleted-message behavior. No wasted words.

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

  Completeness4/5

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

  With no output schema, the description explains the return format sufficiently by stating 'opaque message keys' and how they differ from row numbers. It does not detail other returned fields, but the sibling tool get_email likely consumes these keys. For a listing tool with 5 optional parameters, this is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter is already documented. The description adds context by grouping filters (unread, flagged, mailbox, date) and noting the 'date' filter corresponds to 'after', but this adds minimal value beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool lists messages ('List messages') and specifies scope: recent messages, newest first, with filters. It distinguishes itself from siblings like get_email (which fetches a single message) and search by focusing on catalogue-based listing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for filtered listing and highlights speed ('reads Mail's own catalogue') but does not explicitly contrast with alternatives like search or get_email_links. No exclusions or when-not-to-use guidance, but the purpose and filters make intended usage clear.

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

• list_accountsA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It adds valuable context by explaining that accounts are derived from mailboxes on disk and that empty accounts are omitted, plus a performance note ('Fast'). However, it does not describe the return format or error conditions.

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

  Conciseness5/5

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

  The description is two short sentences with the primary action front-loaded. It states what the tool returns and immediately adds a relevant caveat, all in efficient language without filler.

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

  Completeness4/5

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

  For a zero-parameter list tool with no output schema, the description is mostly complete: it tells what is returned (accounts with mailbox counts) and a key behavioral caveat (empty accounts absent). It could be more explicit about the return fields, but this is minor for a simple list.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so schema coverage is trivially 100%. The description does not need to explain parameters; the baseline of 4 applies because there is nothing to add beyond the schema.

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

  Purpose5/5

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

  The description clearly states it lists the mail accounts configured on this Mac, including the number of mailboxes per account. This specific verb+resource structure distinguishes it from sibling tools like list_mailboxes and get_emails.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus alternatives such as list_mailboxes. The description implies an account-level overview but does not say 'use this when you need account information' or mention any exclusions.

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

• list_mailboxesA
  4/5.0
  Behavior3/5

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

  The description adds useful behavioral context: the operation is fast and uses pre-maintained counts, and it lists the output fields. However, it says 'Every mailbox' while the optional limit parameter caps results, and it does not disclose ordering or pagination behavior. With no annotations, this is a moderate disclosure.

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

  Conciseness5/5

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

  The description is extremely concise, with the main purpose front-loaded in the first sentence. The second and third sentences are short and add relevant performance and data-source context without fluff.

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

  Completeness4/5

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

  For a simple listing tool, the description covers the returned fields (account, message count, unread count) and a performance trait. The primary gap is the inconsistency with the limit parameter, but the schema covers that. Overall, it is nearly complete for this tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides a clear description for the limit parameter ('Maximum results. Capped at 200.'), so the baseline is 3. The description adds no additional parameter meaning and could even be misleading with 'Every mailbox' given the limit cap.

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

  Purpose5/5

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

  The description clearly states the tool lists every mailbox with its account, message count, and unread count. The title 'List mailboxes' provides a specific verb+resource, and the description's detail on returned fields distinguishes it from sibling tools like list_accounts and get_emails.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: use this tool to quickly retrieve mailbox overviews with counts. It mentions 'Fast' and that counts are maintained by Mail, which gives contextual guidance. However, it does not explicitly name alternatives or conditions for 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.

• get_emailA
  4.4/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden. It discloses that it returns null rather than error for missing keys, explains why (message moved/deleted), and provides performance/cost behavior. This is thorough and useful.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose, then adds valuable cost context. Every sentence earns its place with no redundancy.

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

  Completeness4/5

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

  Given the single parameter and no output schema, the description explains purpose, error behavior, and performance. It doesn't detail what metadata fields are returned, but the tool name and title provide enough context for selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage, including a detailed description of the 'key' parameter. The tool description adds no new semantic information about the parameter beyond restating 'by its key', so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it returns metadata for a single message by key, using a specific verb and resource. It distinguishes from siblings like get_email_body and get_emails by focusing on metadata and singular message.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: use to fetch metadata for a message by key. The description notes a cost implication and the null-return behavior, which helps decide when to use it, though it doesn't explicitly name alternatives or exclusions.

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

• get_email_attachmentA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses critical behaviors: it never returns bytes/base64, parsing runs in a sandboxed process with limits, type detection uses leading bytes rather than declared type, and returned message text is wrapped in an untrusted-content marker. This is exceptional transparency beyond what any annotation could provide.

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

  Conciseness5/5

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

  The description is dense but every sentence adds unique value: the contents list, format limitations, the no-bytes policy with rationale, sandboxing details, type-mismatch handling, and trust boundaries. It is front-loaded with the most important information and contains no fluff.

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

  Completeness5/5

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

  Given a single parameter, no annotations, and no output schema, the description covers everything an agent needs: what is returned, what is not returned, safety mechanisms, and how to interpret the data. There are no significant gaps for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully documents the lone parameter 'key'—its origin, stability, and rejection of Apple row numbers. The tool description adds no additional parameter-level meaning, so the baseline score of 3 applies due to 100% schema coverage.

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

  Purpose5/5

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

  The description clearly states that the tool returns attachment metadata (name, part id, type, size) and optionally bounded extracted text, while explicitly excluding PDFs/images from text extraction. This distinguishes it from sibling tools like get_email_body or get_emails by focusing specifically on attachments.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use this tool when you need attachment metadata or extractable text. It also states when not to rely on it—PDFs/images yield no text, and file bytes/base64 are never returned. It does not name alternative tools explicitly, but the boundaries are evident.

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

• get_email_linksA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries behavioral disclosure. It explicitly states URLs are never fetched/resolved/checked and explains the security rationale (attacker-controlled URLs). Also discloses the prerequisite of a published body index.

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

  Conciseness5/5

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

  Three concise sentences: the first states the tool's output, the second explains the crucial security behavior, and the third gives the prerequisite. No fluff or repetition.

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

  Completeness5/5

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

  Given its simplicity (one parameter, no output schema), the description is sufficient: it tells what, why, and under what conditions. The reference to get_email_body provides useful analogy. No significant gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes the 'key' parameter, including its opaque nature and stability. The description adds no additional parameter semantics beyond the prerequisite, which relates to the message rather than the key. Baseline of 3 is appropriate given high schema coverage.

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

  Purpose5/5

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

  States clearly that the tool returns http/https URLs found in a message as text. This differentiates it from sibling tools like get_email_body and get_email_attachment. The purpose is immediately understandable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explains that a published body index is required, mirroring get_email_body, which gives context on prerequisites. Does not explicitly name alternative tools, but the security warning clarifies why links are not fetched. Sufficient guidance for an agent deciding when to call it.

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

• get_email_bodyA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses important behavioral traits: it strips quoted reply history, applies a length cap, returns content inside an untrusted-content marker, and specifically explains the null-return condition when the body index is missing. It even provides the reasoning about Apple's per-mailbox row numbers, giving deeper insight into the tool's limitations.

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

  Conciseness5/5

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

  The description is compact and well-structured: it leads with the core function, then a security note, then a limitation with a clear reason. Every sentence adds unique value, and there is no filler or repetition of schema details.

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

  Completeness5/5

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

  For a one-parameter tool with no output schema, the description addresses all critical aspects: what it returns (readable text), how it transforms input (removes quotes, caps length), how to interpret output (untrusted marker), and when it might fail (missing index). It is fully self-contained and leaves no major gaps for an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides a rich description for the sole 'key' parameter (opaque, stable, rejects Apple's row numbers). The tool description adds context by explaining why row numbers fail (per-mailbox) and tying the parameter to the required body index, enhancing the schema's semantics without redundancy.

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

  Purpose5/5

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

  The description clearly states the tool gets 'the readable text of one message' with specific transformations (removes quoted reply history, length cap). This distinguishes it from siblings like get_email_links and get_email_attachment, making its purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description sets clear context for when to use the tool (to retrieve readable message text) and explicitly warns about a prerequisite (published body index) that gates usage. It does not explicitly name alternative tools, but the sibling names and purpose make the intended use clear without ambiguity.

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

• get_threadA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and excels. It discloses quote stripping and token savings, ordering, threading logic, the null-return behavior when the required index is missing, message count/text caps, and the untrusted-content marking of message text. This is exemplary behavioral disclosure.

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

  Conciseness5/5

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

  Although lengthy, every sentence earns its place, covering rationale, usage, edge cases, limitations, and security. The structure front-loads the core purpose in the first sentence, then systematically expands. There is no fluff, and the length is proportionate to the tool's complexity.

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

  Completeness5/5

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

  Given the tool's complexity, the description is complete: it explains the return value (thread messages, order, content), error behavior (null when no index), output limits, and the meaning of a degenerate thread. It also distinguishes from siblings. No output schema exists, so the description's coverage of return semantics is essential and well handled.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline of 3 applies. The description adds no specific parameter-level semantics beyond what the schema already provides; it doesn't discuss 'limit' or 'includeText' in prose. The schema itself is clear, so the tool remains adequately documented, but the description contributes no extra parameter value.

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

  Purpose5/5

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

  The description explicitly states the tool gets the entire thread for a single message, listing messages oldest first, with each message carrying only its sender's own text. It clearly differentiates from siblings by noting the collapsed nature and explicitly referencing get_email_body as an alternative, establishing a distinct, specific purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance: 'Prefer this over calling get_email_body once per message in a conversation.' It also clarifies the threading algorithm (RFC headers, not subject line), the behavior for single-message threads, and the critical prerequisite of a published body index, giving the agent clear conditions for when to use and when to avoid the tool.

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

• index_statusA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and excels: it explains auto-start behavior, non-blocking nature, and what counts/ranges are reported. It also hints that the first call may initiate a build, which is an important side effect for the agent to know.

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

  Conciseness5/5

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

  Three sentences, each packed with relevant information; no filler. It is front-loaded with the main output, followed by a use case and behavioral notes, making it highly efficient.

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

  Completeness5/5

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

  For a zero-parameter, no-output-schema tool, the description provides sufficient context on return values, use cases, and build behavior. It covers the essential information an agent needs to decide when and how to use it, including the distinction between no matches and unbuilt index.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and schema coverage is trivially 100%. The baseline for 0 parameters is 4; the description adds no parameter info, but none is needed since the schema is empty.

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

  Purpose5/5

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

  The description clearly states the tool reports index coverage, generation, and change counter, and specifically positions it as a diagnostic for empty search results. The verb 'Call this' and the resource (index status) distinguish it from sibling search tools like search and get_email.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance to call when an empty search result needs differentiation between no matches and an unbuilt index, and advises polling to monitor build progress. It does not explicitly name alternatives, but the context implies when not to use (e.g., not for actual search results), so a 4 is warranted.

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

• searchA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and excels. It reveals that filters are hard constraints, that search mode depends on body index availability (text vs subjects only), that results include searchable fraction, that threads are grouped with match counts, and that message text is untrusted. This is a comprehensive disclosure of non-obvious behaviors.

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

  Conciseness5/5

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

  Though lengthy, every sentence conveys a distinct, essential fact. The structure is logical: core purpose, then 'IMPORTANT' mode caveat, then grouping behavior, then data safety note. No redundancy or filler; the length is justified by the tool's complexity.

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

  Completeness5/5

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

  Despite the absence of an output schema, the description thoroughly explains what results contain (mode indicator, searchable fraction, thread grouping, match counts, flat list preservation). It also covers limitations (subject-only search) and security context (untrusted markers), making it complete for an agent to invoke and interpret results correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers all seven parameters with clear descriptions, so the baseline is 3. The description adds value by stating that filters are hard constraints rather than ranking hints, and by explaining how the query interacts with the body index—semantics not present in the schema. This elevates it above baseline but does not fully detail every parameter's interplay.

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

  Purpose5/5

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

  The description starts with 'Search messages by free text and/or structured filters', clearly stating the verb and resource. It enumerates specific filter types (sender, mailbox, date range, unread) and notes that filters are hard constraints, which distinguishes it from retrieval tools like get_emails and get_thread. The behavioral detail about conversation grouping further separates it from a flat list tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear context for when to use the tool (searching with filters) and provides an explicit alternative: 'use get_thread on any group worth reading in full'. However, it does not explicitly contrast with get_emails or get_email for scenarios like retrieving a single known message, so it stops short of full when/when-not guidance.

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