MinuteMail

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the irreversibility nuance of 'permanently' and targets the archived mailbox specifically, but it does not disclose potential cascading effects, authorization needs, or what happens to associated data.

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, tightly worded sentence with no filler. The key qualifier 'permanently' is front-loaded and adds important meaning without extra length.

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 destructive one-parameter operation with a full input schema and an output schema, the description plus annotations cover the essentials. It could mention what qualifies as an archived mailbox or whether associated attachments are also removed, but no critical selection or invocation information is missing.

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

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

Schema coverage is 100% and the single parameter mailboxId is already described as 'Archived mailbox ID'. The description adds no additional parameter semantics, so the baseline 3 is appropriate.

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

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

The description names a specific verb ('delete'), a specific resource ('archived mailbox'), and the qualifier 'permanently' makes the operation clear. It is easily distinguishable from siblings like archived.get, archived.list, and archived.reactivate.

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 guidance on when to use this tool versus alternatives such as archived.reactivate or mailboxes.delete. The tool name and namespace imply the context, but the description itself does not state it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context, such as error or not-found behavior, but for a simple get-by-ID operation this is acceptable.

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

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

The description is a single focused sentence with no filler. It places the core action and resource first, and immediately specifies the identifying parameter.

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

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

For a single-parameter read-only get operation, the description, combined with comprehensive annotations and an output schema, provides everything an agent needs to correctly select and invoke the tool.

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

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

The schema has 100% coverage: mailboxId is described as 'Archived mailbox ID.' The description simply reinforces the 'by ID' concept without adding new parameter meaning, so the baseline of 3 applies.

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

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

The description states a specific verb ('Fetch'), a specific resource ('archived mailbox'), and the selection criterion ('by ID'). This clearly distinguishes it from archived.list (which would be for multiple) and archived.delete (which would be for mutation).

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 a single archived mailbox is needed by ID. It does not explicitly mention alternatives like archived.list, but the singular scope and sibling context make the intended usage clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds the 'expired but recoverable' domain context but does not disclose further behavioral details like pagination, sorting, or tenant scoping beyond the word 'tenant's.'

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?

A single sentence that front-loads the action and resource, with a useful parenthetical clarifying what 'archived' means. There is no redundancy or filler.

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

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

For a parameterless list tool with an output schema and safety annotations, the description is largely complete. It omits potential pagination or ordering details, but those are minor given the tool's simplicity and the presence of structured annotations.

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 100% schema description coverage, so there are no parameter gaps to fill. The baseline of 4 applies; no additional parameter explanation is necessary.

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 ('List') and a specific resource ('archived mailboxes'), and it clarifies the domain term with 'expired but recoverable.' This makes it easy to tell apart from archived.get, archived.delete, archived.reactivate, and mailboxes.list.

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

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

The description clearly implies this tool is for listing archived mailboxes, but it does not explicitly say when to prefer it over alternatives such as mailboxes.list. No when-not-to-use guidance or alternative references are given.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds no extra behavioral context. It does not mention side effects, prerequisites, or what happens to the mailbox upon reactivation, leaving the agent with only a generic verb.

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 redundant words. It is concise and directly states the action, earning full marks for efficiency.

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?

While the operation is simple and the schema fully documents parameters with an output schema present, the description lacks contextual details such as when to use it (e.g., only for archived mailboxes) or any caveats (e.g., what if the mailbox is already active). It is minimally adequate but not comprehensive.

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

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

Schema description coverage is 100%, and both parameters are already described in the schema (mailboxId as 'Archived mailbox ID' and expiresIn with its range and optionality). The description adds no additional semantic value beyond the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Reactivate' and the resource 'archived mailbox', making the purpose explicit. It distinguishes itself from siblings like 'archived.delete' and 'archived.list' which have different actions.

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, such as when a mailbox is already active or how it relates to creation or updating. The agent must infer usage solely from the name, which is insufficient 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?

Annotations show this is a write operation (readOnlyHint false, idempotentHint false), and the description's "attach" aligns with that without contradicting it. It adds the context that the target is a test-injected email, but does not disclose side effects such as whether an existing attachment is replaced or how errors are handled.

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 says what the tool does and the payload format. There is no filler or repetition.

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

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

The tool is a simple add operation with a full input schema and an output schema, so the minimal description is largely sufficient. It lacks only an explicit statement that the mail must already exist, though the required mailId parameter implies this.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters. The description's only parameter-related phrase, "base64 payload," duplicates the data parameter's existing description, so it adds no new meaning.

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?

"Attach a file to a test-injected email" names a specific action and target resource, and the verb clearly distinguishes it from sibling get/list/delete tools. The base64 payload parenthetical adds the technical mechanism without blurring the 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?

The phrase "test-injected email" gives a clear context: this tool is for adding attachments to synthetic emails, not to arbitrary real mail. It does not explicitly name alternatives or exclusions, so it stops short of a 5.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is established without description. The description adds only the 'single' scope and does not disclose permanence, permissions, or side effects, but this is partially acceptable given the annotation coverage.

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 or repetition. It is appropriately sized for a simple single-resource deletion 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?

Given the simple operation, fully documented parameters, output schema, and destructiveHint annotation, the description is sufficient for invoking the tool correctly. It does not explain when to choose delete_bulk, but that gap is more about usage guidance than blocking 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 100%, with all three required parameters clearly documented as Mail ID, Mailbox ID, and Attachment ID. The description adds no parameter-level meaning beyond the schema, matching the baseline.

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

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

The description uses a specific verb ('Delete') and clearly identifies the resource ('a single attachment'). The word 'single' distinguishes this tool from the sibling attachments.delete_bulk, so an agent can immediately understand its scope.

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

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

The description gives no explicit when-to-use guidance or alternatives. The word 'single' implies this is for deleting one attachment rather than multiple, but the agent must infer the distinction from the sibling tool name delete_bulk rather than being told directly.

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

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

The annotations already carry the important behavioral facts: destructiveHint=true, readOnlyHint=false, idempotentHint=false. The description adds only the scope constraint ('of one email at once') and does not describe behavior beyond what the annotations communicate, such as error handling or whether deletion is permanent. There is no contradiction with annotations.

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

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

A single sentence with no filler. Every word contributes meaning, and the key distinction ('several,' 'one email,' 'at once') is front-loaded. Nothing needs to be cut or reordered.

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 three-parameter bulk-delete tool, the description is sufficient: schema documents all parameters, output schema exists, annotations cover destructive behavior, and the wording explains the operation's scope. An agent has everything it needs to invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real semantic value by binding the three parameters together: 'several' maps to the ids array and 'one email' expresses the relationship between mailboxId and mailId, which helps an agent correctly group all attachment IDs under a single email.

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

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

The description names the exact verb-resource pair ('Delete ... attachments') and adds three discriminating qualifiers: 'several,' 'of one email,' and 'at once.' This makes it easy for an agent to distinguish from the single-delete sibling attachments.delete and from delete tools on other resources.

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

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

The description clearly implies the intended use — deleting more than one attachment belonging to the same email — but it never states when to prefer this over attachments.delete for a single attachment, nor does it mention any exclusions or conditions. The usage context is recoverable from the wording, but not explicit.

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

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

The description adds useful behavioral detail beyond the annotations by specifying that the file contents are returned base64-encoded in the JSON data field. The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered; the description goes further on output format.

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

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

The description is two concise sentences with no filler. The core action is front-loaded, and the return encoding detail is placed second, making it easy to parse quickly.

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, read-only attachment download, the description, schema, and annotations cover the essential behavior. The output schema presumably documents the return shape, so explaining base64 encoding is a helpful addition. It could mention how attachment IDs are discovered, but this is not a blocking 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?

All three parameters have schema descriptions, so the baseline is 3. The tool description does not add parameter-level meaning beyond what the schema provides, such as how to obtain the IDs or guarantee the relationship between mailboxId, mailId, and attachmentId.

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

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

The description states a specific action, 'Download an attachment,' and identifies the exact resource being acted upon. This clearly distinguishes it from sibling operations like attachments.list, attachments.add, and attachments.delete.

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

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

Usage is implied by the verb 'Download': use this when you need attachment content. However, there is no explicit guidance about when not to use it or how it relates to alternatives such as attachments.list, which would help an agent distinguish metadata retrieval from content retrieval.

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

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

Annotations already declare readOnlyHint and destructiveHint false. The description adds that it returns only metadata, which is useful context. However, it doesn't disclose pagination, ordering, or how many attachments, but that's covered by the output schema presumably.

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?

Single sentence, front-loaded with the action and resource. No wasted words.

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

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

For a simple list tool with two required parameters, a clear purpose, and an output schema, the description is adequate but minimal. It lacks any usage context or alternative differentiation, but that's not critical for a straightforward read-only listing.

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

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

Both parameters have generic descriptions in the schema ('Mail ID', 'Mailbox ID'). The tool description does not add any additional meaning or format clarifications. Baseline 3 for high coverage is appropriate.

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

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

The description clearly states a specific verb ('List') and a specific resource ('attachments of an email'), and the parenthetical '(metadata only)' further distinguishes it from attachment retrieval. It is distinguishable from sibling tools like attachments.get which likely returns the attachment content.

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 on when to use this tool over alternatives. It only implies usage when you need to see what attachments an email has, but doesn't state when not to use it or name alternative tools.

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

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

Annotations already declare destructiveHint=true, and the description aligns with this (a delete operation is inherently destructive). The description does not contradict annotations (annotation_contradiction=false). It adds minimal context beyond the annotation — no mention of irreversibility, required permissions, or cascading effects — but is at least consistent. With annotations carrying the destructive-hint burden, a 3 is fair.

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?

A single, clean sentence with zero filler. The action and object are placed up front, making the purpose immediately scannable. No redundant phrasing given the title already says 'Delete domain' — the description still earns its place by clarifying the domain is 'registered'.

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 very simple tool — one required parameter, output schema present, and an annotation declaring destructiveness. The description 'Delete a registered custom domain' is sufficient for an agent to invoke it correctly. The only minor gap is the lack of any note about post-delete behavior (e.g., whether the domain is permanently removed or recoverable), but the output schema likely covers return values, keeping the description adequate.

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

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

Schema description coverage is 100%, and the single parameter domainId is described as 'Domain ID' in the schema itself. The description 'Delete a registered custom domain' adds nothing beyond the schema — the implication that domainId refers to the domain being deleted is self-evident. Baseline 3 applies since the schema fully covers the 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?

States the verb 'Delete' and the resource 'registered custom domain' clearly. The word 'registered' subtly distinguishes it from sibling tools like domains.register and domains.verify, though it doesn't name them explicitly. Purpose is unambiguous.

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

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

Usage context is implied by the verb 'Delete' and the phrase 'registered custom domain' — the agent can infer this applies to already-registered domains only. However, no explicit when-to-use, prerequisites, or alternatives are given, so the agent must infer when this tool is appropriate versus siblings like domains.register.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what the list includes ('DNS verification status'), but it does not disclose additional behavioral details like pagination or filtering. This is acceptable given the annotations and empty parameter list.

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?

A single, tight sentence that front-loads the action and resource. Every word contributes meaning, and there is no redundant restatement of the tool name or title.

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 are no parameters, rich annotations, an output schema, and a clear one-sentence description, nothing critical is missing for an agent to invoke this tool correctly. The description fully scopes what is being listed.

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

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

The tool has zero parameters, so the schema fully describes the parameter surface. The description does not need to compensate for missing parameter explanations, and the baseline of 4 for parameterless tools applies.

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

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

The description uses a specific verb ('List') and a specific resource ('the tenant's custom domains') plus a distinctive attribute ('DNS verification status'). This clearly differentiates it from sibling tools like domains.register, domains.verify, and domains.delete.

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 clear context: this tool is for listing a tenant's custom domains and their verification status. It does not explicitly mention when not to use it or name alternatives, but the scope is unambiguous enough for an agent to select it correctly.

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?

Beyond the annotations, which already indicate a non-read-only, non-idempotent, non-destructive operation, the description reveals the important post-registration requirement: DNS records (TXT token + MX) must be added before verification succeeds. This explains the pending state and prerequisite behavior.

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

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

Two concise sentences front-load the core action and immediately give the next step an agent must know. There is no filler or redundancy.

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

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

For a one-parameter registration tool with annotations and an output schema, the description covers the essential workflow: register the domain, then add DNS records. Nothing critical is missing 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?

The schema already documents the single parameter 'name' with an example, providing 100% coverage. The description does not add extra parameter-level detail, but none is needed for such a simple 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?

States a specific verb and resource: 'Register a new custom domain.' It clearly differentiates from sibling tools like domains.verify, domains.list, and domains.delete by describing the registration action rather than verification, listing, or deletion.

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 conveys when to use it by noting that DNS records must be added after registration before verification can succeed. This implies registration is a prerequisite for verification, though it does not explicitly name alternatives or state when not to use this 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?

Annotations already indicate this is not read-only, not idempotent, and not destructive. The description adds meaningful context by specifying that the verification checks TXT and MX records and by limiting the action to registered domains. It does not contradict the annotations.

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

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

The description is one concise, front-loaded sentence. Every word adds value: it names the action, the resource, the verification method, and the required state of the domain.

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 one-parameter action with an output schema and annotations present, the description is nearly complete. It could mention whether verification is asynchronous or requires DNS records to be configured first, but these are not critical to invoking the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents the domainId parameter. The description adds the contextual detail that the domain must be registered, but it does not materially expand the meaning of the parameter itself.

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 and resource: it triggers DNS verification for a domain, and specifies the verification records (TXT + MX). This clearly distinguishes it from sibling tools like domains.register, domains.list, and domains.delete.

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 'of a registered domain' implies it should be called after registration, but it does not explicitly say when to use it versus alternatives, whether DNS records must already be set, or how to confirm verification status. Usage is inferred rather than stated.

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

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

Annotations already communicate the mutation profile (readOnlyHint=false, idempotentHint=false), and the description adds the 'mock' and 'OAuth flow testing' context. It does not, however, describe further behavioral details such as validation, uniqueness, or side effects beyond what the schema states.

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?

A single front-loaded sentence that names the action, object, binding, and purpose with no filler or repetition of the title.

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 create operation with a full output schema and 100% parameter coverage, nothing essential is missing. It could be slightly richer about prerequisites or limitations, but the schema and annotations fill most gaps.

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

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

Schema description coverage is 100%, so the schema fully documents all seven parameters; the description adds no parameter-level meaning and does not need to. Baseline 3 applies.

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

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

The description names a concrete action ('Create'), a specific resource ('mock identity'), and binds it to a mailbox for OAuth flow testing. This clearly distinguishes it from sibling identity operations (list, get, update, delete) and from mailboxes.create.

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

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

It gives clear context: this tool is for OAuth flow testing using a mock identity that must be linked to an existing mailbox. It does not explicitly list exclusions or alternative tools, so it stops short of a 5.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the description adds no behavioral information beyond what is already structured. It doesn't disclose whether deletion is permanent, cascading, or requires the identity to exist; 'mock identity' is domain color rather than behavioral transparency.

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

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

The description is a single short sentence with no filler or redundant explanation. It front-loads the verb and object and adds only the meaningful qualifier 'mock', making it appropriately sized for a trivial one-parameter delete 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 simple, one-required-parameter delete operation, the combination of annotations, full schema coverage, and an output schema covers most operational needs. The only missing elements are usage guidance and any side-effect disclosure, which keep it from being fully complete.

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

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

The input schema provides 100% coverage and documents identityId as 'Identity ID'. The description does not add any extra format, constraints, or contextual meaning, so with high schema coverage the baseline score of 3 is appropriate.

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

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

The description states a specific action ('Delete') and a specific resource ('a mock identity'), which clearly distinguishes it from sibling operations like identities.get, identities.list, identities.update, and identities.create. The 'mock' qualifier adds useful context about the type of identity being deleted.

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 offers no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, consequences, or exclusions. An agent is left to infer usage entirely from the tool name and generic delete semantics.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'mock identity' context but does not disclose behavior beyond the annotations, such as what happens if the ID does not exist.

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

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

The description is one short, front-loaded sentence with no filler. Every word adds meaning, and the key scoping ('single', 'by ID') is placed immediately.

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

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

For a single-parameter read operation with a rich output schema and comprehensive safety annotations, this description is fully sufficient. The word 'mock' sets appropriate expectations about the data, and no critical calling information is missing.

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

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

Schema coverage is 100% and the identityId parameter is already documented as 'Identity ID'. The description only says 'by ID', adding no meaningful semantic value beyond what the input schema provides, so the baseline of 3 applies.

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

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

The description states a specific verb ('Fetch'), a specific resource ('a single mock identity'), and the lookup key ('by ID'). This clearly distinguishes it from siblings like identities.list, identities.create, and identities.update without needing to open the schema.

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

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

The description implies this is the tool to use when a single identity is needed by its ID, but it does not explicitly mention alternatives or state when not to use it. The usage context is inferable from 'single' and 'by ID', but not explicitly spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context that these are mock tenant identities and mentions the filter options, but it does not disclose additional behavioral traits such as pagination or ordering.

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 that front-loads the action and scope, with filter details appended. Every word earns its place and nothing is redundant.

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

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

For a read-only list operation, the description, full parameter schema coverage, and existing output schema provide all necessary information for an agent to invoke the tool correctly. No critical behavioral details are 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?

Both parameters are fully described in the input schema with 'Filter by...' explanations and Optional flags. Since schema description coverage is 100%, the description does not need to add deeper parameter meaning; it only restates the filtering concept at a higher level.

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 ('List') and resource ('tenant's mock identities'), and mentions optional filtering by OAuth client or mailbox address. This clearly differentiates the tool from identities.get, identities.create, identities.update, and identities.delete.

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

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

The description clearly indicates this is the list operation for identities and shows that filtering is available, but it never explicitly names alternatives or states when not to use this tool. The intended use is implied by the verb and resource rather than stated as direct guidance.

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

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

The description adds behavioral context beyond the annotations. It explicitly mentions that custom claims are merged into the ID token and userinfo, and clarifies that isActive means activate/deactivate. It also references that claims replace existing claims (from the schema). While annotations provide readOnlyHint=false and destructiveHint=false, the description adds useful side-effect information about token/userinfo updates and activation semantics, which is valuable for an agent understanding the tool's impact.

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

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

The description is a single, concise sentence that front-loads the core purpose ('Update a mock identity') and efficiently lists the key updateable aspects. Every word contributes value, with no filler or redundancy. It is appropriately sized for the tool's complexity and immediately orients an agent to what the tool does.

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

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

Given the tool's complexity (7 parameters, nested objects, output schema present) and the annotations (all hints false), the description provides sufficient context for most use cases. It explains the primary side effects (claims merged into tokens/userinfo) and activation semantics. However, it does not explicitly mention that the identity must already exist (though implied), nor does it discuss error conditions or authorization requirements. Still, for a mock identity tool with a well-documented schema, this is a reasonably complete description, though a bit more on prerequisites would make it fully complete.

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

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

The input schema already provides comprehensive descriptions for all 7 parameters (100% coverage), including details like 'Replaces existing claims' and 'Reserved claim names are rejected' for the claims parameter. The tool description repeats some of this (e.g., claims merged into ID token and userinfo) but does not add significant new meaning beyond what the schema already documents. Since the schema does the heavy lifting, a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Update' and the resource 'mock identity', and enumerates the specific fields involved (profile fields, isActive, emailVerified, custom claims). This distinguishes it from sibling tools like identities.create, identities.delete, identities.get, and identities.list, which have different purposes. The description is specific and action-oriented, leaving 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 implicitly conveys that this tool is for modifying an existing identity, as opposed to creating, deleting, or retrieving. However, it does not explicitly state when to use this tool over alternatives, nor does it provide any exclusions or prerequisites. It lacks clear guidance such as 'Use this when updating an existing identity; use identities.create to create a new one.' The usage context is implied but not explicit.

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

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

The description adds behavioral context beyond annotations: the mailbox is temporary by default, the domain falls back to the tenant default, and the owner is always tied to the API key. Since annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, this supplementary context is valuable and non-redundant.

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

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

Two tight sentences, front-loaded with the core action, and each clause adds a distinct piece of information. No filler or repeated schema 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 create operation with an output schema and fully documented optional parameters, the description covers the important defaults and ownership semantics. The mutual exclusion between expiresIn and noExpiration is left to the schema, which is acceptable because schema coverage is complete.

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

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

Schema description coverage is 100%, so every parameter is already documented. The description reinforces that domain defaults to the tenant default but does not explain tag, expiresIn, recoverable, or noExpiration beyond the schema. This is exactly the baseline-3 case.

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

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

States a specific verb and resource ('Create a new temporary mailbox') that clearly distinguishes it from sibling operations like mailboxes.list, mailboxes.get, and mailboxes.delete. The qualifier 'temporary' aligns with the service default, and the rest of the sentence adds meaningful scope.

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

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

No explicit when-to-use or when-not-to-use guidance, nor a named alternative. The context about domain defaults and API-key ownership is helpful, but the agent must infer usage purely from the resource type and title rather than from stated 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?

The description adds meaningful behavioral context beyond the annotations by explicitly noting that the mailbox's contents are also deleted, effectively disclosing cascading deletion. The destructiveHint=true annotation already signals danger, and the description aligns with it without contradiction.

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

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

The description is a single, compact sentence that front-loads the key action, resource, and scope. Every word contributes meaning, 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 one-parameter destructive operation with a fully documented schema and an output schema present, the description is largely complete. It covers the essential cascade behavior, though it omits any note about permanence, recovery, or authentication requirements.

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

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

Schema description coverage is 100%, so the schema already documents mailboxId as 'Mailbox ID'. The description only echoes 'by ID' and adds no additional parameter semantics, which matches the baseline for high schema coverage.

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

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

The description states a precise action ('Delete'), the exact resource ('a mailbox'), and the scope ('and its contents'), while specifying the lookup method ('by ID'). It clearly distinguishes this single-item delete from the sibling mailboxes.delete_bulk.

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 prefer this tool over mailboxes.delete_bulk or other delete operations, nor any mention of irreversibility or prerequisites. The intended use is implied by the name and brief description but not explicitly stated.

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

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

The description's 'Delete' mirrors the destructiveHint=true annotation without adding additional behavioral context such as irreversibility, partial failure handling, or whether any dependent resources are affected. With annotations already declaring the destructive nature, the description provides minimal extra behavioral value but does not contradict anything.

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. It front-loads the primary verb and resource, then adds the scope qualifier needed for correct selection.

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 one-parameter bulk deletion tool with a complete input schema, an output schema, and annotations already declaring destructive behavior, the description is sufficiently complete. It could mention behavior on invalid IDs or partial failures, but those details are not essential for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100% and the only parameter, 'ids', is already described as 'Mailbox IDs to delete'. The description adds only the phrase 'by ID' and the bulk qualifier, which slightly reinforces the parameter's role but does not add meaningful semantic detail beyond the schema.

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

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

The description states a clear action ('Delete') and a specific resource ('mailboxes'), with the bulk qualifier and the ID-based input distinguishing it from the sibling mailboxes.delete. An agent can immediately understand this is the multi-object counterpart to single mailbox deletion.

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?

'Delete several mailboxes at once by ID' clearly implies the tool should be used when deleting multiple mailboxes, which differentiates it from the single-mailbox delete sibling. It does not explicitly name the alternative or state exclusions, but the context is clear enough for 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds no extra behavioral traits such as error behavior, permissions, or rate limits, so it provides no context beyond the annotations—worth a 3 given the lower bar set by rich annotations.

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

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

A single, front-loaded sentence that states the operation and target with zero filler. Every word earns its place; this is appropriately concise for a simple get-by-ID 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 one-parameter read operation with an output schema present and annotations covering idempotency and non-destructiveness, the description is fully sufficient. An agent has everything needed to invoke it correctly; the sibling list also disambiguates it from related mailboxes tools.

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

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

Schema description coverage is 100%, with mailboxId already described as 'Mailbox ID'. The description merely repeats the idea of fetching by ID without adding format, example, or relationship details, so it does not meaningfully raise understanding beyond the schema.

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

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

Description uses a specific verb ('Fetch') and resource ('a single mailbox'), and the qualifier 'by ID' plus 'single' clearly distinguishes it from mailboxes.list and mailboxes.create/delete. An agent can immediately tell this is a targeted read operation without opening the sibling schemas.

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

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

The description clearly implies this tool is for retrieving one specific mailbox when an ID is available, which provides adequate usage context. It does not explicitly name alternatives like mailboxes.list, but the 'single' vs. implied multiple distinction is strong enough that no exclusion is strictly necessary.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds meaningful behavioral context: only active mailboxes are returned, and the mailbox owner is derived from the API key (tenant scoping). It also discloses exact-match semantics for the optional address parameter.

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

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

Two tightly packed clauses in one sentence: the core action and scope come first, followed by the optional single-lookup behavior. No filler.

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

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

For a 1-parameter, read-only, idempotent list tool with an output schema and full schema descriptions, the description covers the key unknowns: scope, active filter, and exact-match behavior. It could explicitly state the default when no address is given, but this is strongly implied by 'optionally.'

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

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

The input schema has 100% description coverage for the only parameter, so baseline is 3. The description's mention of 'exact address' restates what the schema already says and adds no new semantic detail.

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

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

States a specific verb ('List'), resource ('tenant's active mailboxes'), and scoping (owner derived from API key, active only). The optional single-address lookup is also noted, which distinguishes it from a pure list-all tool and from mailboxes.get by describing what happens with the address parameter.

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

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

The description provides clear usage context: it lists tenant mailboxes or can look up a single one by exact address. It does not explicitly mention alternatives or when not to use it, but the optional behavior and scoping make the intended use obvious.

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

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

The description adds no behavioral context beyond the annotations, which already mark the operation as destructive and non-idempotent. It does not disclose whether deletion is permanent, reversible, or has side effects, so the agent gains no extra safety-relevant information.

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 wasted words. It conveys the essential action and scope immediately while leaving details to the schema and annotations.

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 low-complexity tool with two fully documented required parameters, an output schema, and annotations covering destructiveness, the description is largely sufficient for correct invocation. It lacks only explicit sibling guidance, which is already accounted for in the usage dimension.

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 already provides 100% coverage with descriptions for both required parameters. The tool description does not add any meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific action ('Delete') on a specific resource ('a single email'), making the tool's purpose immediately clear. The word 'single' hints at a distinction from sibling tools like mails.delete_bulk, but it does not explicitly name the 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?

Usage is implied by the qualifier 'single': use this tool to delete one email rather than multiple. However, there is no explicit guidance about when to prefer alternatives such as mails.delete_bulk or how this relates to archived delete operations.

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

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

Annotations already communicate destructive behavior via destructiveHint: true and readOnlyHint: false, so the bar for additional disclosure is lower. The description adds scope context—deleting multiple emails from one mailbox—but does not disclose whether the deletion is permanent, reversible, or how failures are handled.

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 or repetition. Every word earns its place, and the key facts—bulk, resource, and mailbox scope—are stated immediately.

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 two-parameter bulk delete tool with an output schema and destructive annotation, the description is nearly complete. It could be stronger by explicitly noting permanence or naming the single-delete sibling, but nothing essential is missing for basic 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 100%, so the params are already documented. The description adds useful relational meaning beyond the schema by clarifying that the deletion targets several mail IDs within one mailbox, tying ids to mailboxId. It stops short of explaining ID formats or edge cases like empty arrays.

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 ('Delete'), a clear resource ('several emails'), and a scope ('of one mailbox at once'). This clearly distinguishes it from mails.delete (single mail) and from bulk operations on other resources such as attachments.delete_bulk.

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 phrasing 'several emails of one mailbox at once' implies the intended use case: batch-deleting multiple mails within a single mailbox. However, it does not explicitly mention when to avoid this tool, such as for deleting a single mail, nor does it name mails.delete as the alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the body/attachment-metadata scope, but does not provide further behavioral context such as error behavior or authorization needs. This is adequate but not rich.

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, target, and relevant response content without any filler or repetition.

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

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

For a simple get-by-ID operation with fully documented parameters, a complete output schema, and safety annotations, the description is sufficient. No critical information needed to invoke the tool correctly is missing.

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

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

Schema description coverage is 100% and both parameters are simple strings with basic descriptions. The tool description does not add further parameter semantics, so the baseline of 3 applies.

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

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

The description states a specific verb ('Fetch'), a clear resource ('a single email by ID'), and the expected content ('body and attachment metadata'). This clearly distinguishes it from sibling tools like mails.list or attachments.get.

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

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

The description clearly implies this tool is for retrieving one specific email when its ID is known. It does not explicitly name alternatives or exclusions, but the single-email-by-ID framing provides sufficient context to select it over listing or mutation tools.

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

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

Annotations already cover read-only, destructive, and idempotency hints, so the description's main job is to add context. It does so by disclosing that the operation is a simulation, requires multipart upload, and does not send external mail. No contradiction with annotations is present.

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

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

The description is two sentences with no filler. The core action is front-loaded, followed by the testing purpose and the key distinction that no external mail is sent.

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 presence of a rich input schema and an output schema, the description only needs to supply the tool's intent and behavior. It does that well. A minor gap is that it does not mention any side effects within the mailbox or limitations on attachment handling, but these are largely covered by the schema.

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

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

All parameters have schema descriptions with 100% coverage, so the description does not need to re-document them. The phrase 'multipart upload' hints at how attachments are handled, but the description adds no parameter-level meaning beyond the schema.

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

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

The description identifies a specific verb and resource: 'Inject a simulated inbound email into a mailbox.' It clearly differentiates the tool from the mails.get/mails.list/mails.delete siblings by emphasizing the simulated, inbound nature and the 'multipart upload' mechanism.

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

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

The description explicitly states when to use it: 'use this to simulate inbound mail for flow testing.' It also clarifies what it is not for: 'No external mail is sent.' It does not name an alternative tool, but the sibling list makes the placement clear.

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

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

Annotations already cover the safety profile with readOnlyHint, idempotentHint, and destructiveHint. The description adds one useful behavioral trait, 'newest first', but provides no further detail about pagination, limits, or response scope.

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?

A single, front-loaded sentence states the action, object, scope, and ordering with no filler. Every word earns its place.

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 one-parameter, read-only list tool with an output schema and clear annotations, the description is sufficient for an agent to select and invoke it. Pagination or limit details would be nice but are not essential given the schema and tool complexity.

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

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

The input schema has 100% description coverage for the single required parameter, mailboxId. The description's phrase 'in a mailbox' reinforces the parameter's purpose but adds no new format, validation, or semantics.

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 ('List'), a clear resource ('the emails'), and a scope ('in a mailbox'), plus an ordering trait ('newest first'). This is enough to distinguish it from sibling tools like mailboxes.list or mails.get.

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 basic use case is implied clearly: use this to list emails in a mailbox. However, it does not explicitly mention alternatives or when not to use it, leaving the agent to infer distinctions from sibling names.

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?

Discloses the non-obvious one-time return of the plaintext clientSecret, which materially changes how an agent should capture the response. This adds behavioral context beyond annotations, which already mark it as non-read-only, non-idempotent, and non-destructive.

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

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

Two compact sentences lead with the operation and then surface the critical one-time secret behavior. Every sentence earns its place, and no content is repeated from the title or 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?

For a four-parameter create tool with full schema coverage, an output schema, and annotations, the only missing contextual risk is the one-time secret, which the description explicitly discloses. An agent has enough information to decide to call it and to handle the response correctly.

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

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

The input schema covers all four parameters with descriptions and enum values, so the description carries no parameter burden under the baseline. It doesn't add meaning beyond the schema, such as validation behavior or how providerType affects secret generation.

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

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

States a specific action and resource ('Register an OAuth client') and adds scope ('for mock identity flows'), so an agent knows what entity is being created. It does not explicitly contrast with sibling operations such as rotate_secret or identities.create, relying on the create/delete/list split already present in the tool name.

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?

'for mock identity flows' provides clear intended context and implies a test environment, but the description doesn't say when to choose this over sibling operations like oauth.clients.rotate_secret or oauth.clients.get. No explicit exclusion or alternative is given.

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

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

Annotations already declare destructiveHint=true, and the description merely restates the action without adding any behavioral context beyond that (e.g., whether tokens are revoked, if the deletion is permanent, if any side effects occur). The description adds no value over the annotation, so it fails to enhance transparency.

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

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

The description is a single, concise sentence with no fluff. It is front-loaded with the action and resource, and every word is functional. This is an exemplar of conciseness.

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 delete tool with one parameter, an output schema, and annotations covering destructiveness, the description is minimally sufficient. However, it misses any mention of irreversible consequences or potential authorization requirements, which would be useful contextual detail for an agent. It is not misleading but leaves some gaps.

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

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

Schema coverage is 100%, with the parameter 'clientId' clearly described as 'Public OAuth client ID'. The description repeats this identifier but does not add additional semantics beyond the schema. Baseline 3 applies since the schema already documents the parameter adequately.

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 the action 'Delete' with a specific resource 'OAuth client' and the key identifier 'public client ID'. This precisely distinguishes it from sibling tools like oauth.clients.get, oauth.clients.list, oauth.clients.create, and oauth.clients.rotate_secret without ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives, no mention of prerequisites, consequences, or situations where it should not be used. For a destructive operation, some context (e.g., 'use when you need to permanently remove a client') would be helpful, but it is 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate those. The description adds no extra behavioral context (e.g., not-found behavior, permission requirements, or data redaction), but it also does not contradict the annotations.

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

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

The description is a single, focused sentence that front-loads the action, resource, and lookup key. 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?

For a simple get-by-ID tool with one well-documented parameter, an output schema, and robust annotations, the description is sufficiently complete. Nothing else about invocation or behavior is needed for a capable agent.

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

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

The input schema has 100% coverage, with the parameter 'clientId' described as 'Public OAuth client ID'. The description merely repeats that same semantic ('public client ID') without adding new details like format, length, or example values. Baseline 3 applies because the schema already carries the burden.

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 ('Fetch'), a specific resource ('a single OAuth client'), and a distinguishing qualifier ('by its public client ID'). This clearly separates it from sibling tools like oauth.clients.list (plural, no ID) and oauth.clients.create/delete/rotate_secret.

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 intended use case (you have a public client ID and need that one client) but does not explicitly state when to choose it over alternatives like list or rotate_secret. No exclusions or alternative routing are mentioned, so guidance 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds scoping ('tenant's OAuth clients') and purpose, but does not disclose any additional behavioral details such as pagination, ordering, or output limits. It neither contradicts nor significantly extends the annotations.

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

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

A single, front-loaded sentence of ten words says exactly what the tool does and why it exists, with no filler or repetition of the title. Every word earns its place.

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 zero parameters, rich annotations, and an existing output schema, the description is sufficient for an agent to select and invoke the tool correctly. It captures the resource scope and purpose without needing to explain return values or parameter details.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The schema coverage is trivially complete, and the description does not need to compensate for missing parameter information.

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

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

The description clearly states the action ('List'), the resource ('the tenant's OAuth clients'), and the intended purpose ('for mock identity testing'). This distinguishes it from sibling tools like oauth.clients.get, oauth.clients.create, and oauth.clients.delete without ambiguity.

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 'for mock identity testing' implies a usage context, but the description does not explicitly state when to prefer this tool over alternatives such as oauth.clients.get or identities.list. No exclusions or alternative routing are 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?

The description discloses the one-time return of the plaintext secret, which is important behavioral information not present in the annotations. However, it does not explicitly state that rotating invalidates the existing secret or that active clients using the old secret will be affected, which is a significant omission for a security-sensitive mutation.

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

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

The description is two short sentences with no filler. It front-loads the core action and immediately follows with the most critical operational caveat ('returned once'), making it efficient and scannable.

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 output schema exists and there is only one parameter, the description is mostly sufficient. However, for a state-changing, non-idempotent operation, it lacks explicit disclosure of the side effect (invalidating the old secret) and any authorization or recovery notes, leaving the agent without full awareness of consequences.

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

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

Schema coverage is 100% and the only parameter, clientId, is already described as the 'Public OAuth client ID' in the schema. The description adds no further meaning about the parameter, so the baseline of 3 applies as the schema handles the documentation.

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 ('Rotate') and resource ('an OAuth client's secret'), and adds the critical detail that the new plaintext secret is returned only once. This clearly distinguishes the tool from siblings like oauth.clients.create or oauth.clients.get, and there is no other rotate 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?

No guidance is given on when to use this tool versus alternatives, such as when a secret is compromised or needs periodic rotation. The description does not mention any prerequisites, nor does it contrast with oauth.clients.create or oauth.clients.get, leaving the agent to infer the appropriate context.

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

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

The description adds useful behavioral context by noting that an SMTP invite is sent by the team service, which is a side effect not captured by the annotations. It does not mention duplicate handling or idempotency behavior, but the provided side-effect note adds meaningful transparency.

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

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

The description is one concise, front-loaded sentence with no filler or repetition. Every word contributes to the tool's meaning.

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

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

The tool is simple: one required parameter, full schema coverage, and an output schema available. The description plus annotations provide enough context to invoke it correctly. The main gap is the lack of explicit differentiation from team.members.add, which could matter in a real agent workflow.

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

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

Schema coverage is 100%, and the only parameter 'email' is described as 'Invitee email address' in the schema. The description merely restates that the invitation is for an email address, so it adds no additional semantic depth beyond the schema.

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

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

The description clearly names the action ('create'), the resource ('team invitation'), and the target ('an email address'). It does not explicitly contrast with siblings like team.members.add, but the resource is specific enough to convey the primary 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?

No guidance is given about when to use this tool versus alternatives such as team.members.add or team.invitations.list/delete. The intended use must be inferred entirely from the name and the action verb.

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

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

The annotation destructiveHint=true already discloses that this is a destructive operation. The description's 'Revoke' is consistent with that and adds slight context about the nature of the action, but does not go beyond the annotation. No additional behavioral traits (e.g., irreversibility, cascading effects) are disclosed, which is acceptable given the annotation coverage.

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 communicates the exact action without any filler. It is front-loaded with the verb and resource, making it easy to parse quickly.

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 one parameter and a clear destructive action, this description is sufficient. An output schema exists (though not shown in the prompt), so return values are covered. The description covers the core purpose, and annotations handle safety semantics. Minor missing details like idempotency are not critical for this simple operation.

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

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

The schema description coverage is 100%, so the parameter invitationId is fully documented in the schema. The description does not add any parameter-specific meaning beyond the schema, which meets the baseline for high coverage.

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

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

The description uses a specific verb ('revoke') and resource ('team invitation'), clearly distinguishing this from sibling tools like team.invitations.create and team.invitations.list. The action is unambiguous and cannot be confused with other tools.

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?

While the description does not explicitly name alternatives or when-not-to-use, the purpose is so self-evident from the tool name and description that an agent would know to use it for canceling an invitation. The sibling list reinforces that this is the delete operation for invitations, but explicit routing guidance is absent, so a 4 is appropriate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond the fact it lists invitations. It does not mention any additional behaviors like default limits, ordering, or access requirements. Given the simple nature, this is acceptable, but it relies heavily on annotations.

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

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

A single concise sentence that states the action and resource. No fluff, no repetition. It is perfectly front-loaded and efficient.

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

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

The description is complete for a tool with no parameters and an output schema. It tells the agent what it does and implies the return will be a list of invitations. There is nothing missing that an agent needs to invoke it correctly.

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

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

The tool has zero parameters, so there is nothing to explain. The baseline for 0 params is 4, and the description adds no unnecessary details. The schema is empty, so no further semantic help 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 clearly states the verb 'List' and the resource 'the tenant's team invitations', which is specific and unambiguous. It distinguishes itself from sibling tools like team.invitations.create and team.invitations.delete by focusing on listing. No ambiguity.

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 it (when you need to see team invitations) but does not explicitly mention alternatives or when not to use it. Since it's a simple list operation, the use case is obvious, but there is no guidance on edge cases like filtering or pagination. Adequate but not explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint all false, so the agent knows it's a non-idempotent mutation. The description adds the behavioral trait that the add bypasses invitations, which is useful, but it doesn't disclose side effects (e.g., whether an email is sent, whether the team must exist, or what happens on duplicate adds). The description adds some value beyond annotations but not rich detail.

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 zero waste. It front-loads the core action (Add) and the key differentiator (directly, no invitation flow) without any filler. Perfect length for an MCP tool definition.

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 mutation tool with fully documented parameters and an existing output schema, the description covers the essential behavior (direct add, no invitation). It does not mention prerequisites like team context or error handling, but those are either implicit (team is in the tool name) or handled by the output schema. The description is adequate and nearly complete for an agent to use it correctly.

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

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

Schema description coverage is 100%, so every parameter (email, status, user_id, username) already has a clear definition. The description does not add any extra meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'Add' with the resource 'team member' and clarifies the mechanism with 'directly (no invitation flow)'. This clearly distinguishes it from sibling tools like team.invitations.create, team.members.delete, etc., so an agent can tell exactly what it does without opening the schema.

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

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

The phrase 'no invitation flow' implicitly contrasts with the invitation-based alternative (team.invitations.create), providing clear context for when to use this tool. However, it does not explicitly state when to prefer invitations over direct adds, so it stops short of explicit exclusions or alternatives.

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

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

The description merely paraphrases the title and adds no behavioral detail beyond what the annotations already provide. It does not explain consequences such as irreversibility, cascading effects on related resources, or required authorization, though it does not contradict the destructiveHint annotation.

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

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

The description is one short, front-loaded sentence with no wasted words. It is concise, though it borders on simply restating the title.

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, non-idempotent mutation, the definition is too thin. It does not state whether removal is permanent, what happens to related team invitations or memberships, or what prerequisites must hold before calling the tool. The annotations and schema cover only the basic safety and input details.

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 has 100% coverage for the single parameter, describing memberId as 'Member ID'. The description adds no additional meaning about where to obtain the ID or what form it takes, so the baseline score of 3 is appropriate.

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

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

The description states a clear action ('Remove') and resource ('a team member'), so an agent can immediately tell what the tool operates on. It does not explicitly distinguish this from the many sibling delete tools, but the resource is specific enough to avoid confusion.

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 team.members.add, archived.delete, or other delete tools. The intended usage is only implied by the wording and is not supported by any context, exclusions, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Fetch' is consistent with those. The description adds no extra behavioral context such as 404 behavior, authentication requirements, or response details, but the output schema and annotations reduce the burden.

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

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

The description is one short, front-loaded sentence with no filler. Every word contributes to understanding what the tool does and what it operates on.

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 with one fully documented required parameter, full annotations, and an output schema, the description is complete enough for an agent to invoke the tool correctly. No additional context is necessary.

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

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

Schema coverage is 100% and the single required parameter memberId is described as 'Member ID'. The description adds no further meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Fetch'), a specific resource ('a single team member'), and the identifying input ('by ID'). It clearly distinguishes this tool from the sibling team.members.list, team.members.add, and team.members.delete operations.

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

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

The phrase 'single team member by ID' implies the right context for use: when you have a specific member ID. However, it does not explicitly say when to prefer team.members.list for multiple members or mention any exclusions, leaving the usage guidance only implied.

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 annotations already declaring readOnlyHint, idempotentHint, and destructiveHint, the description doesn't need to repeat those. It adds the tenant scope but doesn't disclose pagination or ordering behavior. This is an acceptable minimal addition given strong annotations.

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

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

A single, clear sentence that conveys the full purpose without any redundant wording. It is appropriately sized for a parameterless list 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 zero-parameter, read-only list operation with an output schema and comprehensive annotations, the description is fully sufficient. Nothing critical is missing for an agent to select and invoke the tool correctly.

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

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

The input schema has zero parameters, so there is no parameter meaning to document. The baseline of 4 applies; the description provides all necessary semantic context for invoking this no-argument tool.

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

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

States the specific verb 'List', the resource 'team members', and the scope 'tenant's'. This clearly distinguishes it from sibling tools like team.members.get, team.members.add, and team.members.delete.

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

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

The description clearly indicates this is the list-all operation for team members. It doesn't explicitly mention when to use team.members.get for a single member, but the context of the sibling tools makes the intended usage obvious.

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