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

With no annotations, the description carries full responsibility for behavioral disclosure. It mentions the conditional sending of a consent invitation, but fails to disclose side effects, idempotency, error scenarios, or authentication requirements. For a mutation tool, this is a significant gap.

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, front-loaded sentence that conveys the main action efficiently. It avoids unnecessary words, but its brevity sacrifices crucial details, so it earns a 4 rather than 5.

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 two parameters and no output schema, the description is highly incomplete. It omits critical context such as how the consent invitation is triggered, what happens if the recipient already exists, any prerequisites like authentication, and the expected outcome. An agent would struggle to use this tool correctly based solely on the description.

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 0%, and the description does not mention either parameter. The schema itself provides formats and patterns for email and apiKey, but the description adds no meaning about their usage or purpose, making it unhelpful for an agent that needs to know what values to provide.

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 adds a recipient and optionally sends a consent invitation. It identifies the primary action and target resource, distinguishing it from list/remove operations by implication, though it does not explicitly name an alternative 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?

No guidance is provided on when to use this tool versus sibling tools like list_recipients or remove_recipient. The phrase 'when required' is vague and does not specify conditions or prerequisites, leaving the agent to infer when the consent invitation is needed.

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?

No annotations are provided, so the description carries the full burden. It discloses that this is a creation operation, but does not mention whether it is idempotent, what happens if the address already exists, whether it requires special permissions, or what the response contains. For a mutation tool with zero annotation coverage, this is a significant gap.

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, short sentence with no wasted words. It is front-loaded with the action and resource, but it is under-specified for a tool with three undocumented parameters.

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 no annotations, no output schema, and 0% parameter coverage, the description is incomplete. An agent would not know what values to provide for address/displayName, what the API key format implies, or what a successful response looks like. The sibling list shows related tools but the description itself does not provide enough context.

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 0%, so the description must compensate. It does not explain the meaning of apiKey, address, or displayName, nor their constraints (e.g., address format, displayName max length). The description adds no parameter-level meaning beyond the schema's raw property names.

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

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

The description states a specific verb ('Creates') and resource ('a mailbox') for the authenticated account. It is clear enough to distinguish from siblings like list_mailboxes or get_mailbox, though it doesn't explicitly name a sibling alternative.

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 guidance on when to use this tool versus alternatives, no prerequisites, and no mention of required authentication context beyond 'authenticated account'. The description implies usage but provides no exclusions or conditions.

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 no annotations, the description carries the full burden of behavioral disclosure, and it does disclose the core destructive behavior: the mailbox and all associated messages are deleted. However, it does not state that the action is irreversible, what permissions are required, or what other resources may become orphaned or affected.

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 front-loaded sentence that wastes no words. It states the action and its scope compactly, which is appropriately sized for a simple deletion operation.

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 destructive tool with no annotations, no output schema, and two parameters, the description should warn about irreversibility, prerequisites, or at least route the agent to the sibling delete_messages for partial deletion. It covers only the basic purpose, leaving an agent without enough context for safe 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?

Schema description coverage is 0%, and the description does not explain apiKey or mailboxId beyond the word 'mailbox.' mailboxId is inferable as the target mailbox, but apiKey's role in authentication is left entirely to the schema, so the description adds very little semantic value over the property names.

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 ('Deletes') and resource ('a mailbox'), and explicitly states the cascade over 'all associated messages.' This clearly distinguishes it from sibling tools like delete_messages and update_mailbox, so an agent can tell exactly what the operation removes.

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 the tool is for removing an entire mailbox, but it never names assistantmail_delete_messages as the alternative for deleting only messages, nor does it mention when not to use this tool. There is implied context, but no explicit selection guidance against 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?

No annotations are provided, so the description carries the full burden. It discloses the destructive nature ('Deletes') and the two modes, but it does not warn about irreversibility, whether deleteAll bypasses messageIds, whether messages are hard-deleted or soft-deleted, or any permission requirements. For a destructive tool with zero annotation coverage, this is a significant gap.

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 action and covers both modes. It earns its place with no filler, though it could add a brief warning without becoming bloated.

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 destructive tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It does not explain the deleteAll vs messageIds interaction, irreversibility, or what happens after deletion. An agent needs more guidance to invoke this tool safely and 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?

Schema description coverage is 0%, so the description must compensate. It mentions 'by IDs' (messageIds) and 'deletes all messages' (deleteAll), but it does not explain the relationship between deleteAll and messageIds (e.g., which takes precedence, whether both can be set), nor the apiKey parameter. The description adds some meaning but leaves critical parameter semantics unresolved.

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

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

The description states a clear verb ('Deletes') and resource ('messages from a mailbox'), and distinguishes two modes: by IDs or all messages. It is clear enough to differentiate from sibling tools like delete_mailbox, though it doesn't explicitly name a sibling alternative.

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 context: use when you need to delete specific messages or clear a mailbox. However, it does not explicitly state when to prefer this over other deletion tools (e.g., delete_mailbox) or mention any prerequisites or safety conditions.

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?

No annotations are provided, so the description carries the full burden. It states the operation is a get (read), but doesn't disclose what the response contains, whether the policy is account-wide or mailbox-specific, or any authentication requirements beyond the implied apiKey parameter. The description is minimal and doesn't add behavioral context beyond the obvious read operation.

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 states the action and resource. It is front-loaded with the verb and resource. It could add a bit more context about the response or usage, but it is appropriately sized for a simple getter tool.

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 getter with one parameter and no output schema, the description is somewhat thin. It doesn't explain what the inbound policy settings are, what the response looks like, or how this relates to the update_inbound_policy sibling. Given the sibling list includes update_inbound_policy, a brief note about the read-only nature and relationship would improve 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?

Schema description coverage is 0%, but there is only one parameter (apiKey) with a clear pattern (^amk_.*). The description doesn't mention the apiKey parameter at all, but the schema's pattern and format provide sufficient meaning. The description adds no parameter-specific information, but the schema is self-explanatory for a single API key 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 clearly states the verb 'Gets' and the resource 'inbound email policy settings' for the authenticated account. It distinguishes itself from the sibling update_inbound_policy by being a read operation, though it doesn't explicitly name that sibling.

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 this is a read-only retrieval tool for the authenticated account's inbound policy. It doesn't explicitly state when to use it versus alternatives, but the read vs update distinction is clear from the verb and resource. No exclusions or alternative routing is provided.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'gets,' which implies a read operation, but it does not disclose response shape, error cases, authentication requirements, rate limits, or whether the call is safe and idempotent. For an unannotated tool, this is insufficient.

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 short sentence with no filler, and the core operation and target are front-loaded. It is appropriately sized for a simple getter and contains no redundant clauses.

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

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

With no annotations, no output schema, and no parameter descriptions, this definition is too thin. An agent cannot know what metadata fields are returned, whether apiKey is required beyond schema presence, or how this tool relates to the many sibling tools. It provides only the bare action and target.

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 0%, so the description must compensate. It adds meaning to mailboxId by saying 'for a mailbox ID' and ties it to 'mailbox metadata,' but it does not explain the apiKey parameter or its role/precondition. This is partial compensation, not enough for two parameters.

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 ('Gets'), a resource ('mailbox metadata'), and a scope ('for a mailbox ID'), making it clear this is a single-mailbox lookup. It is not quite a 5 because it doesn't explicitly distinguish itself from sibling tools like list_mailboxes or get_me, and 'mailbox metadata' is somewhat underspecified.

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

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

There is no guidance about when to use this tool versus alternatives such as list_mailboxes, get_me, or get_inbound_policy. Usage is only implied by 'for a mailbox ID'; there are no exclusions, prerequisites, or routing hints. This is effectively no usage guidance beyond the core action.

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?

No annotations are provided, so the description must disclose behavioral aspects. It does not mention authentication requirements (aside from implicit apiKey), read-only nature, or potential errors. It's a metadata retrieval, but no statement about what the response contains or if it's safe to call.

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 sentence, no waste, but slightly vague 'profile and tier metadata' could be more specific. Still, it is concise and front-loaded with the purpose.

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 metadata endpoint with one optional parameter and no complex output schema, the description is adequate but could benefit from noting that it requires authentication and what 'tier metadata' might include. It is not incomplete to the point of confusing.

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 0%, so the description should explain the apiKey parameter. It does not, but the parameter has a clear pattern 'amk_.*' implying it's an API key. The description doesn't add meaning beyond the schema, so baseline of 3 is appropriate given the single 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 clearly states it gets account profile and tier metadata, which specifies the verb and resource. It distinguishes from siblings like list_mailboxes or get_usage, though not explicitly compared.

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 guidance on when to use this versus alternatives. For example, it doesn't clarify that this is the top-level account info, distinct from get_usage or get_mailbox. No context on typical use cases or prerequisites.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It does add useful behavior beyond the schema by mentioning 'hydrated text/html bodies when available,' which signals that body content may or may not be present. However, it does not disclose authentication expectations, response structure, or what happens when hydrated bodies are unavailable.

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, front-loaded sentence that states the action, the target, and a key output feature. Every word earns its place, and there is no redundant or filler 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?

For a simple get-by-id tool the description is minimally adequate, especially with the required IDs visible in the schema. However, with no annotations and no output schema, an agent would benefit from knowing what the response looks like, how 'hydrated' bodies are represented, and how this tool relates to list_messages or get_message_reference.

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 0%, so the description must compensate, but it only loosely maps to parameters via 'mailbox' and 'specific message.' It does not explain that mailboxId identifies the mailbox and messageId identifies the message, nor does it clarify the role or format of apiKey beyond the schema pattern. The description adds little semantic value over the parameter names themselves.

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 and resource: 'Gets a specific message for a mailbox.' This clearly distinguishes it from sibling tools like list_messages, which retrieve collections, and get_message_reference, which presumably returns a lighter-weight reference. The added detail about 'hydrated text/html bodies when available' further clarifies the tool's unique value.

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 phrase 'a specific message' implies this is for fetching one already-identified message, as opposed to listing messages. However, the description does not explicitly state when to use this tool versus list_messages or get_message_reference, nor does it mention prerequisites such as needing a mailboxId and messageId obtained from a prior listing call.

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 no annotations provided, the description carries the burden of disclosing behavior. It clearly indicates a read operation via 'fetching' and mentions full body content, but does not disclose endpoint-specific behavior, auth requirements, or response format beyond that.

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 concise, front-loaded sentence that conveys the core function without extraneous detail. Every word contributes to understanding the tool's purpose.

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?

It is adequate for a simple read operation with only two required parameters, but it lacks context about how this tool differs from the similarly named get_message sibling, and with no output schema it would benefit from a note about the response structure.

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 0% and the description does not explain the two parameters. The names mailboxId and messageId are fairly self-explanatory, but the description adds no meaning about how they are used together.

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 operation: 'fetching a single message including its full body content.' It identifies the resource and scope, but does not differentiate from the sibling tool assistantmail_get_message, which appears to have the same purpose.

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

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

There is no guidance on when to use this tool versus assistantmail_get_message or assistantmail_list_messages_reference. The description only states what it does, not when to prefer it over 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Gets' implies a read-only operation, but the description does not disclose what the response looks like, what units or limits are returned, whether the mailbox must exist, or any error behaviors. This is minimal behavioral transparency for an unannotated tool.

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 with no filler and the key resource is front-loaded. It is efficient and scannable, though it prioritizes brevity over behavioral or parameter 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?

Given there is no output schema and no annotations, the description should clarify return values and usage context. It does neither, nor does it disambiguate from the similarly named get_usage_reference sibling. For a quota-related tool, missing information about units or response shape 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 0%, so the description must compensate. It adds value by clarifying that mailboxId is the mailbox whose usage is queried, but it says nothing about apiKey, its format, or how it relates to authentication. The description leaves one of two parameters entirely unexplained.

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

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

The description states a specific verb ('Gets'), a clearly defined resource ('send quota usage for a mailbox'), and the data granularity ('daily and monthly'). It is clear and functional, but it does not differentiate itself from the sibling tool assistantmail_get_usage_reference, so it lacks full sibling differentiation.

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 (when quota usage is needed) but provides no explicit guidance about when to prefer this tool over alternatives such as assistantmail_get_usage_reference. There are no stated prerequisites, exclusions, or context that would help an agent choose between similar 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It indicates an informational behavior by saying it 'Provides the AssistantMail REST endpoint', but it does not disclose whether authentication is required, what the returned endpoint data looks like, whether network calls are made, or any limitations.

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 sentence with no filler words or redundant content. It front-loads the core purpose and avoids restating the tool name or the schema.

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?

There is no output schema and no annotations, so the description is the sole source of behavioral and return-value context. It fails to explain what exactly is returned when the endpoint is provided, how the mailboxId is applied, or any further invocation details, leaving an agent uncertain about the expected result.

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 0%, and the description makes no mention of the mailboxId parameter. The parameter name is somewhat self-explanatory, but the description adds no semantic detail about how mailboxId is used, what values are valid, or what happens if it is missing or invalid.

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 ('Provides') and names the resource ('the AssistantMail REST endpoint for checking send quota usage'), so an agent can tell the core function. However, it does not explicitly distinguish this 'reference' tool from its sibling assistantmail_get_usage, and it leaves ambiguous whether the tool returns endpoint documentation or performs the usage check.

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 guidance is given about when to use this tool versus assistantmail_get_usage or any other alternative. The description implies a documentation/reference purpose, but it never states when an agent should select this tool instead of the non-reference sibling.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It does communicate that the operation is read-only by saying 'Returns', which rules out destructive behavior. However, it does not clarify whether the tool performs a live health check, what metadata fields are included, or how failures are reported.

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, front-loaded sentence with no filler. Every word contributes meaning, and it is appropriately sized for a zero-parameter health/metadata tool.

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 is minimally viable: it names the tool's purpose well enough for an agent to select and invoke it. Yet without an output schema, it leaves the exact contents of 'metadata' ambiguous, so an agent cannot fully predict what the response will contain.

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 schema coverage is 100%, so there is no parameter semantics burden on the description. The baseline of 4 applies because no compensation is needed.

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 clear verb ('Returns') and names a specific resource ('AssistantMail MCP server and API endpoint metadata'). It is immediately distinguishable from sibling tools, which all operate on mailboxes, messages, or policies rather than server-level metadata.

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 the tool is used to inspect AssistantMail server/endpoint metadata, but it does not explicitly state when to use it or when an alternative would be better. There is no direct competing sibling, so the lack of exclusions is acceptable, but usage context is only implicit.

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 no annotations provided, the description carries the full burden, but it only states the action and scope. It implies a read-only list operation and authentication dependency, yet does not disclose response format, pagination, or error handling. This is minimally transparent but not misleading.

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, dense sentence that front-loads the action and adds a useful scope qualifier. There is no filler, redundancy, or wasted wording.

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 tool has no output schema and only one optional, undocumented parameter, yet the description does not explain what the response contains or how apiKey influences behavior. An agent would not know whether to supply apiKey or what format the returned list takes, leaving important context 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?

The input schema has 0% description coverage, and the tool description never mentions apiKey. The parameter name and pattern '^amk_.*' suggest an API key, but its purpose, whether it is required, and how it affects the call are entirely undocumented.

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 ('Lists') and resource ('mailboxes'), and adds a scope qualifier ('accessible to the authenticated account') that clarifies the operation. This clearly distinguishes it from sibling tools like assistantmail_list_messages and assistantmail_get_mailbox, even without naming them.

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 guidance is given on when to use this tool versus alternatives. There is no mention of filtering, pagination, or any conditions under which a different mailbox-related sibling tool would be more appropriate, leaving the agent to infer from the name alone.

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?

No annotations are provided, so the description carries the burden of disclosure. It states it lists messages but does not disclose whether results are paginated, whether it includes both read and unread, whether it requires the apiKey parameter in all cases, or what the output format is. Since it's a list operation with no destructive effects, the description is adequate but lacks depth.

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 is front-loaded with the core action. It is appropriately short, but it omits critical parameter details that would make it more useful, so it's not perfect.

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 0% schema coverage, 4 parameters, and no output schema, the description is inadequate for an agent to confidently invoke the tool correctly. The agent lacks guidance on how to specify the time range (since), pagination (limit), or authentication (apiKey), which are essential for correct use. The description is too minimal given the schema's lack of support.

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 description coverage is 0%, meaning the schema provides no descriptions for the parameters. The description of the tool does not explain the meaning or purpose of mailboxId, limit, since, or apiKey. For example, 'since' is a date-time filter but not mentioned in the description. This forces the agent to infer parameter semantics from names alone, which is insufficient.

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 lists inbound and outbound messages for a mailbox, using a specific verb and resource. It is distinct from sibling tools like get_message (single message) and list_mailboxes (mailboxes, not messages), though it doesn't explicitly differentiate from them.

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 (listing messages for a mailbox) but provides no explicit guidance on when to use this tool versus alternatives like get_message (for retrieving a single message) or list_mailboxes. It does not state conditions to avoid using it or when to prefer other 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It only states that messages are listed; it does not mention pagination, response shape, authentication requirements, ordering, or what distinguishes this 'reference' variant behaviorally.

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 and is easy to scan. It is appropriately short for a one-parameter tool, though it sacrifices useful differentiation for brevity.

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 listing tool with no output schema and no annotations, the description is minimally adequate but incomplete. It leaves open the relationship to assistantmail_list_messages, the meaning of 'reference', and any behavioral details needed for a caller to trust the result.

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 0% schema description coverage, the description should compensate for the undocumented mailboxId parameter. It only vaguely ties 'mailbox' to the operation and does not explain where the mailboxId comes from, its expected format, or how to obtain valid values.

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 identifies a clear action and resource: listing messages (inbound and outbound) in a mailbox. However, it does not differentiate this tool from the closely named sibling assistantmail_list_messages, and the 'reference' suffix is left unexplained.

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 guidance is given about when to choose this tool over assistantmail_list_messages or any other sibling. The description implies a listing use case but does not state conditions, alternatives, or exclusions needed for correct tool selection.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It states the operation is read-only by implication ('Lists') but does not mention pagination, response format, permission requirements, or any side effects. A somewhat useful scope detail ('approved/pending') is present, but broader behavioral context is missing.

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 places the main action and object up front. There is no filler, repetition, 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?

The tool is relatively simple: one optional parameter, no annotations, and no output schema. The description conveys the core purpose and scope with minimal ambiguity, making it minimally viable. However, it does not explain the response shape or apiKey handling, which would be needed for full self-sufficiency.

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 0%, and the description does not explain the 'apiKey' parameter, its format, or how it relates to the authenticated account beyond a vague implication. Since the schema carries no semantic weight, the description should compensate but does not.

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 identifies the verb ('Lists'), resource ('recipients'), and scope ('for the authenticated account'), including the specific statuses 'approved/pending'. It is distinct from siblings like add_recipient and remove_recipient, though it does not explicitly call out which sibling it is not.

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 no explicit guidance about when to use this tool versus alternatives such as add_recipient or remove_recipient. The intended usage is only implied by the verb and resource, so the agent must infer context from the tool name and sibling list.

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 no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic mutation. It does not mention whether removal is idempotent, irreversible, fails for unknown recipients, or requires authentication via apiKey.

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 with no filler or repetition. It is front-loaded with the core action, though its brevity comes at the cost of useful behavioral and parameter context.

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 mutation tool with no annotations and no output schema, the description is too sparse to be complete. It omits prerequisites, side effects, error conditions, and any relationship to sibling tools like add_recipient or list_recipients.

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 0% and the description adds no parameter-level meaning. It never explains that the email parameter identifies which recipient to remove or what apiKey is used for, so the description fails to compensate for the absent schema descriptions.

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 (removes) and the resource (a recipient from the allowed recipient list). It is distinguishable from the sibling add_recipient, though it does not explicitly differentiate itself by name or compare with list_recipients.

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 guidance is given about when to use this tool vs alternatives. It never mentions that add_recipient would be the inverse operation or that list_recipients should be used to inspect the current list before removal.

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?

No annotations are provided, so the description is the only source of behavioral information. It only nods that a reply is being performed, but does not disclose any side effects, return behavior, or authentication requirements (apiKey). This is a thin disclosure for a mutating tool operating on a mailbox.

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 entire description is one clear sentence with no filler or redundant details. Every word earns its place, and the key intent (replying to existent message in a thread) is front-loaded and complete.

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 five parameters, no output schema, and no annotations, the description is insufficient to fully understand how to invoke the tool. It does not explain required vs optional parameters, how the response is returned, or any prerequisites such as the apiKey format. More context is needed to reliably call the tool beyond just guessing its 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 input schema has 0% description coverage and the tool description does not clarify any parameter's purpose. The word 'message' hints at messageId, but html, text, apiKey, and mailboxId remain completely unexplained. The description provides almost no compensation for the missing schema metadata.

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 'replies' and the target 'existing message in a mailbox thread.' This distinguishes it from sibling tools like send_email, which creates a new email, and get_message, which only reads. It is not a tautology and leaves no ambiguity about what the tool does.

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 (when replying to an existing message) but provides no explicit when-not to use it or alternatives. It does not address how it differs from send_email or when a reply is not appropriate. A clear implication is present, hence the middle score.

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 no annotations, the description carries the full burden of behavioral disclosure. 'Queues' usefully implies asynchronous enqueueing, but it does not mention authentication requirements, side effects, error conditions, or what happens after queueing.

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 extremely compact and front-loads the primary action with no wasted words. However, for a 6-parameter tool, this terseness comes at the cost of necessary operational context.

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?

This is a mutating operation with no annotations, no output schema, and six parameters, yet the description provides only a single clause. It omits required context such as how recipients are specified, how html/text relate, auth expectations, and what a caller should expect in response.

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 0%, so the description needed to compensate, but it adds no parameter-specific meaning. It gives only a vague mapping of 'mailbox' to mailboxId and leaves html/text, to, subject, and apiKey entirely to 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 names the action ('Queues') and the resource ('an outbound email') plus the target ('a mailbox'). It distinguishes the tool from most mailbox-read and mailbox-management siblings, though it does not explicitly disambiguate from assistantmail_send_email_reference.

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 guidance is given about when to use this tool versus alternatives such as assistantmail_send_email_reference or assistantmail_reply_message. Prerequisites, exclusions, and selection conditions are all absent.

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 no annotations, the description carries the full burden of disclosing side effects and behavior. It says the tool 'provides' endpoint and headers, which hints at a read-only reference operation, but it does not clarify whether it makes a network call, returns static documentation, requires authentication, or has any side effects.

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 sentence with no filler, which is good for conciseness. However, it is so terse that it sacrifices meaningful content; it is under-specified rather than efficiently complete.

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?

There is no output schema and no annotation coverage, so the description needed to clarify the return value, usage context, and relationship to sibling tools. It only gives a minimal hint about 'endpoint and required headers' and leaves critical operational questions unanswered.

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 0%, so the description needed to explain the mailboxId parameter but never mentions it. The parameter name is somewhat self-explanatory, but the agent receives no guidance on what the ID represents, where to obtain it, or how it relates to the returned endpoint and headers.

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

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

The description names a specific resource ('AssistantMail REST endpoint and required headers') and ties it to email send requests, so it is not a pure tautology. However, it never states whether this tool actually sends emails or merely returns reference information, leaving the core action ambiguous relative to the sibling assistantmail_send_email.

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 guidance is given about when to use this reference tool versus assistantmail_send_email or any other sibling. The phrase 'for email send requests' implies a connection to sending, but the description does not state that this tool should be used to retrieve endpoint/header details before calling the actual send 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a mutation ('Updates') but does not disclose side effects, permission requirements, whether the update is partial or full replacement, or what happens to existing allowedSenders when policy changes. The description adds minimal behavioral context beyond the verb itself.

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 with no wasted words. It is front-loaded with the action and resource, though it could have used the available space to add parameter or usage context.

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 mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin. It does not explain the policy enum semantics, the role of allowedSenders, or the effect of the update, leaving an agent under-informed for correct 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?

Schema description coverage is 0%, so the description must compensate, but it does not explain any parameter semantics. The schema provides enums and formats, but the description adds no meaning about how policy values ('owner', 'list', 'sent') interact with allowedSenders or what each policy implies.

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

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

The description states a specific verb ('Updates') and resource ('inbound email policy') for the authenticated account. It is clear enough to distinguish from sibling tools like get_inbound_policy, though it doesn't explicitly name the sibling or elaborate on what the policy controls.

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 guidance is provided on when to use this tool versus alternatives, nor any context about prerequisites or typical scenarios. The description only states what it does, leaving the agent to infer usage from the name and schema.

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 no annotations, the description carries the full burden for behavioral disclosure. 'Updates' signals mutation, but the description does not mention prerequisites, whether the display name is fully replaced, side effects, or what response to expect. This is a significant gap for a mutation tool.

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 efficient sentence with the verb and resource front-loaded. There is no filler, but the brevity comes at the cost of useful behavioral and usage context.

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 mutation tool with no annotations, no output schema, and 0% parameter description coverage, this description is incomplete. It states only the immediate action and does not cover prerequisites, effects, or how it relates to the broader mailbox tool family.

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 0%, so the description must compensate. It clarifies that displayName is the metadata field being updated, but it does not explain apiKey or mailboxId beyond their property names, and it provides no additional meaning for the required parameters in context.

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

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

The description states a clear verb and resource: 'Updates mailbox metadata', and the parenthetical narrows the scope to display name. This distinguishes it from create/get/list/delete_mailbox and from update_inbound_policy, though it does not explicitly name alternatives.

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 when-to-use or when-not-to-use guidance is provided. The agent must infer from the verb 'Updates' that this is for changing mailbox metadata, but the description offers no alternatives or exclusions, so it does not help the agent choose between sibling tools.

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