Mailgi

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so safety is covered. The description adds real context beyond that by enumerating what is destroyed — the agent, its mailbox, and all its API keys — which is exactly the blast-radius information an agent needs before calling a destructive tool.

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

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

One sentence, front-loaded with the permanence warning and the cascade, with zero filler. Nothing could be removed without losing information.

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 destructive tool with no output schema and annotations carrying the safety profile, the description covers the essentials: permanence and blast radius. It omits behavior on failure (e.g., unknown/already-deleted agent) and whether deletion is immediate or asynchronous, which would round it out.

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?

Zero parameters, so the baseline is 4; there is no parameter surface the description needs to explain, and the implicit 'this agent' target matches the parameterless 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?

A specific verb ('Permanently deletes') plus a specific resource ('this agent') with the cascade scope spelled out (mailbox and API keys), which implicitly sets it apart from mailbox_delete and apikey_revoke. It stops short of naming those alternatives explicitly, so the distinction must be inferred.

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 word 'Permanently' signals this is the nuclear option, and the cascade disclosure implies you should only use it for full teardown. But there is no explicit when-to-use / when-not-to-use guidance and no pointer to narrower siblings like apikey_revoke or mailbox_delete for partial cleanup.

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 state readOnlyHint=true and openWorldHint=false, so safety behavior is covered. The description adds the returned profile fields, but does not disclose authentication requirements, error behavior, or other operational context beyond what annotations provide.

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 with no filler. It states the result and the key returned fields 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 zero-parameter read tool whose annotations already cover safety, the description gives enough context by listing the primary returned fields. Since there is no output schema, a fuller field-by-field return description could add value, but the current description is adequate 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 tool has zero parameters, so there are no parameter semantics to document. The description correctly implies the operation targets the current agent without requiring identifiers.

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

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

The description uses a specific verb and resource — “Returns this agent's profile” — and names the returned fields: addresses, label, and domain. This clearly distinguishes agent_get from sibling operations such as agent_delete and agent_usage.

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 “this agent's profile” implies it fetches the current agent, but the description provides no explicit when-to-use guidance and does not mention alternatives such as agent_usage or org_me.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds a useful behavioral caveat that the latest day is partial, which is not present in structured data and affects interpretation of returned counters.

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?

It is a single front-loaded sentence with no redundant or filler content. The key caveat about partial data is included efficiently.

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 usage tool with two optional, fully documented parameters and no output schema, the description is nearly complete. It conveys what is returned and a key caveat, though it could briefly clarify the counters' structure or granularity.

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 both optional date parameters fully documented as inclusive ISO dates and defaults. The description adds no parameter-specific detail, so 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 uses a specific verb ("Returns") and resource ("this agent's daily send and API counters"), clearly distinguishing it from siblings like domain_usage and org_usage. An agent can identify the tool's output domain without inspecting 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 gives no explicit when-to-use guidance, prerequisites, or alternatives. It does not tell the agent to choose this over domain_usage or org_usage, leaving selection to inference from the name.

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 (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower. The description nonetheless adds the single most important behavioral fact: "The key is shown once" — the secret is returned at creation and cannot be retrieved later, which materially changes how the agent must handle the response.

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

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

Two short sentences, zero filler, with the core action stated first and the one-time-secret warning immediately after. Nothing could be removed without losing information.

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

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

With no output schema, the description should say what the create call returns (presumably the secret plus key metadata) and whether the new key inherits the agent's scopes. "Shown once" covers the secret's lifecycle but the returned payload remains unspecified.

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

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

Schema description coverage is only 50%: expiresAt is documented as an ISO 8601 date-time, but `label` has no description anywhere. The description adds no meaning to either parameter — it doesn't explain what a label is for or what happens if expiresAt is omitted (no expiry? default?). At 50% coverage the description needed to compensate and does not.

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

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

"Creates another API key for this agent" gives a specific verb (creates) and resource (API key), and the word "another" signals this is additive to existing keys, implicitly separating it from apikey_list and apikey_revoke. It does not explicitly name those siblings, so it stops short of a 5.

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 only implied: an agent can infer "call this when you need a new credential." There is no explicit statement of when to use this versus apikey_list/apikey_revoke, no prerequisites, and no note on whether key count or permissions are limited.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context with 'Key values are never shown again', warning the agent that secrets are not retrievable through this call. It stops short of describing whether revoked keys appear or what metadata fields are returned.

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

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

Two short sentences, zero waste. The scope statement comes first and the critical caveat about key values is front-loaded as the second sentence.

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 no-parameter, read-only list tool with no output schema, this covers the essentials plus the important secret-visibility caveat. The only gap is that it never hints at what the returned records contain (key IDs, names, creation dates) or whether revoked keys are included, which the agent needs to chain into apikey_revoke.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; baseline 4 applies. Schema coverage is 100% and empty, consistent with the description.

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 (Lists) and resource (API keys) and scopes it to 'this agent's', which distinguishes it from org-wide key or registration-token listings. It does not explicitly name the sibling alternatives (apikey_create, apikey_revoke, regtoken_list), but the verb/resource pair makes the read-only enumeration purpose unmistakable.

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 name and description: enumerate existing keys to find IDs for later revoke operations. There is no explicit statement of when to use this versus regtoken_list or org-level key tools, and no prerequisites or exclusions 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 declare destructiveHint=true and readOnlyHint=false, so the description's main job is to add detail beyond that. 'Immediately' usefully signals there is no grace period or delayed propagation, but it omits whether revocation is permanent, whether a revoked key can be restored, and whether in-flight requests using the key are affected.

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

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

One short, front-loaded sentence with no filler. It is efficient, though the brevity is partly under-specification rather than tight writing.

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 an irreversible destructive mutation with no output schema, the description should say what gets destroyed, whether the action is permanent, and what the identifier refers to. None of that is present, leaving key operational questions unanswered despite the annotations covering only the safety flag.

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

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

Schema description coverage is 0% and the single parameter keyId has no description anywhere. The description does not explain the identifier format (key ID vs. key value), which is exactly the ambiguity that would cause a failed call.

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 (revokes) and resource (API key), which cleanly separates it from apikey_create and apikey_list in the key-management family. It does not explicitly name those siblings, but the name plus description leave no ambiguity about the operation.

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 revoke versus regenerate or rotate a key, no prerequisites (e.g., ownership/permission requirements), and no mention of siblings such as apikey_create for replacement. The agent must infer the workflow entirely.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by previewing the payload (balance, prices, top-up guidance), but says nothing about freshness, currency, or whether prices are per-message rates — behavioral detail an agent would want for a billing read.

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 identity of the resource and then lists the returned fields. No filler, no 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?

With no parameters, no output schema, and read-only annotations, the description does the necessary work by enumerating what the response contains. It stops short of saying whether the balance is scoped to agent vs organization or what units prices are in, but it is close to sufficient for a simple getter.

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 is empty (0 parameters) with 100% coverage, so the baseline is 4. The description correctly implies no input is required, consistent with a no-arg wallet lookup.

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?

Names a specific verb and resource ('Returns the wallet') and scopes it to 'this agent spends from', which implicitly separates it from the org-level sibling org_billing_get. It also enumerates the returned contents (balance, prices, top-up instructions), but never names the sibling it differs from explicitly.

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 only implied: an agent can infer this is the pre-spend balance check, and the mention of 'how to top up' hints at a follow-up with billing_topup or topup_start. There is no explicit when-to-use, when-not-to-use, or named alternative vs org_billing_get, billing_transactions, or topup_status.

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 disclose readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds useful human-payment context but does not clarify important behavior such as whether repeated calls create multiple links, whether the link expires, or what authentication is required.

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, front-loaded sentences with no wasted words. It states the action and the human-payment purpose 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 one-parameter tool with annotations and no output schema, the description is largely complete. It could mention amount-related context or routing to topup_status, but the schema and annotations carry most of the missing weight.

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?

There is only one parameter and schema description coverage is 100%, with the schema documenting that amountUsd is in USD and the minimum is obtainable from billing_get. The description itself adds no further 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 and resource: 'Creates a card payment link for this agent's wallet.' It is clear what the tool does, but it does not explicitly distinguish itself from related sibling tools such as topup_start, topup_status, or org_billing_topup.

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?

'Give it to a human to pay' gives clear usage context that the generated link is intended for a human payer. However, it does not describe when to choose this over org_billing_topup or mention any 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 and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — results are ordered newest first — but says nothing about pagination behavior, default page size, or whether the ledger is truncated, which matters for a list endpoint with limit/offset.

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

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

One sentence, front-loaded with the verb and resource, with no filler. It is efficient but borders on under-specified for a paginated list endpoint — the brevity comes at the cost of the pagination detail an agent needs.

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 list tool with annotations covering safety and no output schema, the bar is modest, and the ordering hint helps. Still missing is any signal of ledger scope (personal vs org) and pagination/default-limit behavior, which the 0%-coverage schema cannot supply.

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

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

Schema description coverage is 0%: neither 'limit' (1-100) nor 'offset' (>=0) is documented in the schema, and the description does not compensate. Only the ordering is implied; the agent gets no statement of the default page size, max page size, or how offset interacts with the newest-first ordering.

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 ('Lists the wallet ledger') plus an ordering guarantee ('newest first'), so the agent knows exactly what comes back. It does not, however, distinguish itself from the similarly named sibling org_billing_transactions or from billing_get, leaving the agent to infer which scope each covers.

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 when-to-use guidance at all — nothing says whether this is the personal wallet ledger versus the org ledger in org_billing_transactions, nor when to prefer billing_get or topup_lookup. The agent must guess from the name alone.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the mutation profile is known. The description adds useful context by disclosing that the call returns DNS records, but says nothing about failure modes, whether domains must be unique per org, or whether attaching an unverified domain has side effects.

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

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

A single tight sentence with the action and its return value front-loaded. Nothing superfluous.

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 2-param mutation with no output schema, the description covers what the tool does and hints at the return payload, but omits the verification follow-up and any handling of the returned DNS records. Annotations carry the safety profile, yet the workflow context around domain_verify 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 (orgId, domain) are documented in the schema including the pointer to org_list. The description adds no further meaning about either parameter, so the 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?

States a specific verb ('Attaches') and resource ('custom domain') and adds the outcome ('returns the DNS records to publish'). The attach/detach/verify name family makes the distinction from siblings self-evident, though no sibling is named explicitly.

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 only implied: an agent infers this is the first step of onboarding a new domain. There is no explicit statement of prerequisites, no mention of the follow-on domain_verify step, and no exclusion of domains already attached (which a caller must use domain_list for).

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 safety profile is covered, but the description adds nothing beyond a restatement. For a destructive mutation it should disclose consequences: whether mail flow stops, whether inboxes/DNS records are removed, and whether the operation is reversible.

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 with no filler. It is efficient, though the brevity comes at the cost of the missing consequence information rather than being deliberately tight.

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 destructive, two-required-parameter mutation with no output schema and no explanation of side effects or error conditions. An agent knows what it does nominally but not what it breaks or what it gets back.

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 (orgId, domainId) are documented in-schema with source hints pointing at org_list and domain_list. The description adds no extra semantics, which is acceptable given the schema does the work.

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 verb 'Detaches' and resource 'custom domain from the organization' are specific and unambiguous. It does not, however, distinguish itself from adjacent siblings such as domain_attach, domain_verify, or domain_get, so an agent must infer the boundary on its own.

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 detach versus verify or delete, no stated preconditions (e.g., domain must be verified / inboxes must be removed first), and no mention of the alternative operation. The agent is left to infer everything from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by stating what the tool returns, which is important because no output schema is present, though it does not mention errors or permissions.

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 return value and contains no filler. Every word contributes to understanding what the tool provides.

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 lookup with fully documented parameters and read-only annotations, the description gives enough context to call the tool correctly. It could be more complete by clarifying how this differs from domain_verify or domain_list, but the core behavior and return content are covered.

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 orgId and domainId are documented in the schema with references to org_list and domain_list. The description adds no parameter-specific 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 resource and return value: a domain's verification status and required DNS records. It clearly describes what the tool returns, but it does not explicitly distinguish this from siblings such as domain_list or domain_verify.

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 stated return value: an agent would use this to inspect a domain's verification state and DNS records. However, there is no explicit when-to-use guidance and no mention of alternatives or 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 disclose this is a non-readonly, non-idempotent, non-destructive mutation. The description adds one genuinely valuable behavioral fact not in the annotations: the API key is shown only once, which implies irreversibility after the call. It omits other relevant traits such as required permissions, whether the domain must be verified, and quota implications.

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

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

Two short sentences, front-loaded with the action and followed by the one non-obvious fact (one-time API key). 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?

There is no output schema, and the description does not describe the returned inbox object or clarify whether the API key is returned in the same response. It also leaves out prerequisites for a non-idempotent create on a domain. Adequate but with clear gaps for a creation tool.

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

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

Schema coverage is 75%, with orgId, domainId, and localPart each documented (including a localPart example), so the schema does most of the work. The description only implies the localPart@domain composition and adds no syntax or constraint detail beyond the schema; unchanged 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?

States a specific verb and resource ('Creates an inbox') plus the scoping detail that the address is chosen on a domain. It is clear in itself, but it does not distinguish itself from the sibling mailbox_create, which an agent could easily confuse with inbox creation.

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

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

No guidance on when to use this vs mailbox_create, no prerequisites stated (e.g. the domain presumably needs to be attached/verified first, given domain_attach/domain_verify exist), and no mention of alternatives or exclusions. The description only describes the action, not the decision to take 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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description does add one non-obvious fact beyond annotations: the deletion cascades to the inbox's mail. It says nothing about irreversibility, required permissions, or what happens to existing agents/mailboxes bound to the inbox.

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 with no filler, and the cascade scope is stated up front. It is efficient but the brevity comes at the cost of missing operational detail rather than being optimally sized.

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?

Placeholder check: re-evaluating, this is a destructive tool with no output schema and no description of return values, permission requirements, or recoverability. Given annotations only cover the destructive flag, the description is under-specified for a three-parameter irreversible 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?

Schema coverage is 67%: orgId and domainId carry provenance hints (from org_list / domain_list), but the required agentId has no description anywhere. The description mentions no parameters at all, so it fails to compensate for the documented gap.

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 ("Removes an inbox and its mail") and scopes it to a domain, which is more precise than the title alone. It does not differentiate from adjacent siblings such as mailbox_delete or domain_detach, so an agent must infer which deletion surface applies.

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

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

There is no guidance on when to use this versus mailbox_delete or domain_detach, no prerequisites, and no warning about when not to call it. The agent must infer selection purely from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful equivalency that an 'inbox' is an 'agent', but says nothing about permissions, pagination, or result size, so it is adequate rather than 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?

A single front-loaded sentence with no filler, and the parenthetical clarification earns its place. It is arguably too terse given the information an agent still needs, keeping it off a 5.

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

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

For a simple read-only list tool with fully documented params and no output schema, the description is minimally sufficient. It omits return shape and whether the list is paginated or complete, which an agent would want to know.

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 both parameters documented (orgId from org_list, domainId from domain_list), so the baseline is 3. The description adds only the inbox/agent equivalency and no additional parameter syntax or format 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 and resource ('Lists the inboxes') and scopes it to a domain, plus a useful clarification that inboxes are agents. It does not explicitly distinguish itself from siblings such as agent_get or domain_inbox_create, so it stops short of a 5.

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 statement, and no named alternative. The domain scoping and required orgId/domainId imply the context (enumerating inboxes for a given domain), but the agent must infer 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 and openWorldHint=false, so the safety profile is covered. The description adds only that results are org-scoped custom domains; it says nothing about pagination, ordering, or whether unverified/pending domains are included, which is the kind of context that would earn a 4 or 5 here.

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 with no filler. It is appropriately sized for a simple list tool, though its brevity comes partly from omitting useful detail rather than from tight editing of rich 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 read tool with full annotation coverage this is close to sufficient, but there is no output schema and the description says nothing about the shape of the returned domain list or whether filtered/unverified entries appear. Minimal viable, with clear remaining gaps.

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

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

Only one parameter exists and the schema documents it fully, including the provenance hint 'Organization ID from org_list.' The description adds nothing beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific verb and resource ('Lists ... custom domains') scoped to an organization, which lets an agent distinguish it from domain_get, domain_attach, or domain_verify. It does not explicitly name a sibling alternative, so it stops short of a 5.

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 org-scoping ('an organization's') implies you call it with an org context rather than listing all domains, and the name makes the list-vs-get distinction evident. But there is no explicit when-to-use statement, no mention of alternatives such as domain_get for a single domain, and no prerequisites 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful content beyond that by naming the returned counters and their daily granularity, but says nothing about date-range defaults, the agent breakdown option, or result size/limits.

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 with no filler; the return contents are front-loaded and nothing is wasted.

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

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

With no output schema, the description must convey the return shape, and it does so at a basic level (daily send/receive/API counters). Combined with the fully documented input schema and safety annotations, an agent has enough to call it, though the breakdown dimension and date-window behavior go unmentioned.

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%, including date defaults, ID sourcing hints, and the breakdown enum, so the schema carries parameter meaning entirely. The description only echoes the daily granularity and counter types, adding little 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?

Specific verb ('Returns') and specific resource ('send, receive and API counters for one domain'), with granularity ('daily') stated. The 'one domain' scoping implicitly separates it from org_usage and agent_usage, though those siblings are never named.

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

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

No when-to-use guidance, no prerequisites, and no explicit routing between this and the closely related org_usage/agent_usage tools. The agent must infer from the tool name which usage scope it needs.

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 that this mutates state (readOnlyHint=false), is idempotent, and is non-destructive. The description adds that it triggers a fresh DNS lookup and only verifies on success, but omits what happens on failure (error vs. staying unverified), propagation timing, and any rate limits.

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 with no wasted words. It is efficient, though arguably too terse to carry the behavioral detail a state-changing verification tool needs.

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

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

There is no output schema, so the description should say what the caller gets back — e.g., verified status, whether it returns the updated domain object, or error behavior when records are wrong. The conditional 'verifies it if they are correct' hints at this but leaves the failure path unspecified.

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 orgId and domainId fully documented including their source tools, so the schema carries parameter semantics. The description adds nothing about parameters; 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?

States a specific verb (re-checks/verifies) and resource (domain DNS records), and clarifies that verification is conditional on records being correct. It is distinguishable from domain_get and domain_list, though it doesn't name the boundary explicitly.

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 only implied — an agent can infer you call this after configuring DNS records. No explicit when-to-use/when-not-to-use guidance, no mention of alternatives like domain_get for a read-only check, and no prerequisites 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description's added value is the disclosure that the check spans three distinct subsystems (API, database, mail server). It doesn't say whether the check is deep or shallow, whether failures are reported as errors or as status fields, or anything about latency/rate limits — relevant since a DB+SMTP probe can be slow.

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, leading with the verb and immediately qualifying the scope. Nothing repeats the name or title verbatim in a wasteful way.

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 probe the description covers what is checked and where, which is the core need. The one gap is return semantics: with no output schema and no statement about response shape, an agent can't tell whether a downed mail server surfaces as an error or as a field in a success payload.

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

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

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline for a no-param tool applies, and the description correctly avoids inventing parameter discussion.

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 ('Checks') and enumerates the exact resources covered: the API, its database, and the mail server. That scope detail clearly separates it from every sibling tool, none of which perform availability checks. It stops short of 5 only because it doesn't say what the check produces (an aggregate status vs. per-component results).

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 rather than stated — an agent can infer this is the tool to call to verify the service is reachable, and no obvious alternative exists among the 60+ siblings. But there is no explicit 'use before X' or 'do not use for Y' guidance, so it sits at the implied-usage tier.

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=false, idempotentHint=true, and destructiveHint=false, lowering the burden. The description adds the useful detail that the token originates from an invite email, but says nothing about what happens on success (joining the org), permission errors, or token expiry.

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

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

One short sentence with the action and the parameter's source front-loaded; nothing redundant or padded.

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-token operation with a clear safety profile in annotations and no output schema, the description covers what an agent needs to invoke it. Only minor gaps remain, such as the result of a successful acceptance.

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

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

Schema coverage is 0% and the single parameter is only typed as a string, so the description must compensate. It does so by clarifying that the token is the one from the invite email, which is meaningfully more than the schema provides, though format/expiry details are absent.

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 (accepts) and resource (organization invitation), which is unambiguous among siblings like org_invite_create, org_invite_list, and org_invite_revoke. It doesn't explicitly name or contrast with those siblings, keeping it just short of a 5.

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 'with the token from the invite email' implies the usage context (redeeming an emailed invitation) but gives no explicit when/when-not guidance or alternatives such as org_invite_create for issuing invites or org_login_verify for other token flows.

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 disclose that this is a non-read-only, non-idempotent, non-destructive write operation. The description confirms creation and optional nesting but adds no further behavioral context such as duplicate-name handling, parent-existence requirements, permissions, or response 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?

The description is a single front-loaded sentence with no wasted words. It states the action and optional nesting 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 create tool with full parameter documentation and clear annotations, the description is minimally adequate. However, with no output schema, it does not explain what creation returns, and it omits error or duplicate-handling context that could matter for a non-idempotent write.

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 both parameters are already documented by the schema. The phrase 'optionally nested under another' reinforces the parentId relationship but does not add meaning beyond the schema's 'Parent folder ID for nesting.'

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 gives a specific verb and resource: 'Creates a folder', and adds the key scope detail that it can be nested. It is clear enough to distinguish from sibling operations like mailbox_delete and mailbox_rename, but it does not explicitly say 'mailbox folder' or otherwise differentiate itself from other create-style 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?

The only usage guidance is that nesting is optional, which really describes a parameter rather than when to choose this tool. It does not name alternatives, prerequisites, or conditions such as when to use mailbox_create versus other create 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 declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the constraint that only custom folders qualify, which is genuinely useful beyond the annotations. However, it says nothing about whether contained messages are deleted, whether deletion is reversible, or whether system folders are rejected.

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 with no filler; the destructive action is the first word. It borders on under-specification rather than verbosity, but it wastes nothing.

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 mutation with no output schema and an undocumented parameter, the description should cover cascade behavior, reversibility, and the id's provenance. None of that is present, leaving an agent to guess about the consequences of an irreversible action.

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?

One parameter with 0% schema description coverage; 'id' could plausibly be a message id, mailbox id, or folder id given the many siblings using 'id'. The phrase 'custom folder' narrows it to a folder identifier, which is the main semantic value added. It still does not state the id format or source (e.g. from mailbox_list).

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: 'Deletes a custom folder.' The word 'custom' distinguishes it from deleting messages (mail_delete) or system folders, though it never explicitly names a sibling alternative. An agent can identify what the tool does at a glance.

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

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

There is no guidance on when to use this instead of mail_delete, domain_inbox_delete, or mailbox_rename, nor any prerequisite or precondition. The only implied context is that the target must be a custom folder, which the agent has to infer from the adjective 'custom'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact – that system folders (Inbox, Sent, Trash) appear in the result alongside any custom ones – but says nothing about ordering, pagination, or whether undeletable system folders are marked.

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 with no filler; the enumerated folder types carry the only extra information worth including in this space.

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-argument read-only lister the description is serviceable, and annotations cover safety. With no output schema, however, it never indicates what a returned folder looks like (name vs. id), which matters because sibling tools like mailbox_rename and mailbox_delete presumably need that identifier.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and the empty object schema confirms no inputs are required.

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 concrete verb and resource ('Lists all folders') and enumerates the notable members (Inbox, Sent, Trash), so the agent knows exactly what comes back. It does not explicitly separate itself from adjacent listers like mail_list or domain_inbox_list, but the folder-scoped noun makes the distinction inferable.

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 statement, and no alternative is named. Usage is only implied by the read-only 'list folders' nature, e.g. call it before mailbox_rename or mailbox_delete to discover folder 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — not whether the old name becomes invalid, whether collisions with existing names error out, or whether this affects mail routing. With annotations present the bar is lower, but zero added context still warrants a 2.

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 zero waste and front-loaded, but it is under-specified rather than genuinely concise. There is room to add clarifying clauses without bloat.

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

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

For a mutation tool with no output schema and 0% parameter coverage, the description should explain the identifier semantics, name constraints/conflict behavior, and permission requirements. None of that is present, so an agent cannot call this correctly without guessing.

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

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

Schema description coverage is 0% for both required params, so the description carries the full burden and fails it. It never clarifies that `id` identifies the mailbox to rename or that `name` is the new name (and not, say, a display label or a lookup key). One clause would have closed this gap.

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 ("Renames a folder"), so the basic operation is inferable. But it essentially restates the title "Rename folder" and introduces a terminology mismatch: the tool is mailbox_rename, yet the description says "folder," leaving unclear whether a mailbox is the folder being renamed. No differentiation from siblings like mailbox_create or mailbox_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?

There is no guidance on when to use this versus alternatives, no prerequisites (e.g., ownership or permissions needed to rename), and no mention of what happens to mail already in the mailbox. Usage must be entirely inferred from the name.

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=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds one genuinely new behavioral fact — the message lands in Trash, i.e. the deletion is non-destructive — but says nothing about what happens to an already-trashed id or where the result is reported.

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

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

One short sentence, front-loaded with the verb and outcome, with no filler. It is efficient but so terse that the brevity is closer to under-specification than to economy.

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 tool with no output schema and reasonable annotation coverage, this is close to minimally sufficient — an agent can probably call it correctly. The missing pieces (id format, behavior on repeat calls, recoverability) are small individually but leave the definition at the minimum viable level.

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

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

Schema description coverage is 0% for the single parameter, so the description carries the burden and adds nothing: 'a message' only loosely implies that 'id' identifies the message to trash. It never says whether that is an internal message id or an RFC Message-ID, so an agent must guess the format.

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 outcome ('Moves a message to the Trash folder'), which usefully clarifies that mail_delete is a recoverable soft delete rather than a permanent one — a real distinction from what the name 'delete' implies. It does not, however, distinguish itself from the sibling mail_move, which plausibly does the same thing with an arbitrary folder.

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

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

There is no guidance on when to use this versus mail_move (moving to an arbitrary folder) or mailbox_delete (deleting a whole mailbox). No preconditions, no notes on whether an already-trashed message is accepted, and no mention that the operation is reversible.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description usefully adds that the full text and HTML body are returned, giving the agent the return payload shape in the absence of an output schema. It says nothing about not-found errors, body size/truncation, or whether reading marks the message as seen.

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

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

One short sentence with the return payload front-loaded and no filler. It is efficiently sized, though it leaves value on the table that a second clause could have carried cheaply.

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 single-item get with full parameter documentation and readOnly annotations, the description covers what is returned. Missing only edge-case behavior (missing ID, large bodies), which is minor at this complexity level.

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?

Single parameter with 100% schema description coverage, so the schema already explains 'id' and even points at mail_list as its source. The description adds no further meaning about the identifier, so baseline 3 applies.

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

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

States a specific verb and resource ('Returns one message') plus the payload ('full text and HTML body'), which clearly separates it from mail_list in the sibling set. It stops short of naming the list sibling explicitly, but the singular-object scope 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 is only implied: 'one message' versus a list. The workflow hint lives in the schema param description ('Message ID from mail_list'), not the description itself, and there is no statement of when not to use this or what happens with an invalid/deleted ID.

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 establish readOnlyHint=true and openWorldHint=false, and the description adds genuinely useful context beyond them: results are headers rather than full messages, and the default ordering is newest first. It stops short of describing pagination behavior or the exact header fields returned.

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 verb and resource, then tacks on the two most decision-relevant facts (default ordering, folder filter). Nothing is wasted.

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

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

For a read-only list tool with zero required parameters, full schema coverage, and annotations covering safety, the description covers what an agent needs to call it correctly. The absence of an output schema means the return shape would ideally be sketched out in more detail than 'message headers'.

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 all four parameters are already documented, including mailboxId's 'Folder ID from mailbox_list. Omit for all mail.' The description only adds the default sort semantics ('newest first by default'), which is a minor supplement rather than new depth, so the 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 gives a specific verb ('Lists') and resource ('message headers in the mailbox'), and the word 'headers' implicitly separates it from mail_get, which returns full messages. It does not name any sibling explicitly, so it falls just short of a 5.

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?

'Filter by folder with mailboxId' and the default newest-first ordering imply the main usage context, but there is no explicit when-to-use guidance, no mention of when to reach for mail_get or mailbox_list instead, and no stated 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=false, idempotentHint=true, and destructiveHint=false, so safety is covered structurally. The description restates only that a move happens and adds nothing beyond annotations: no note that the message disappears from the source folder, no cross-domain/mailbox restrictions, no error behavior when the folder is missing.

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

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

A single front-loaded sentence with zero filler. It is efficient, but its brevity comes partly from omitting information rather than from disciplined editing.

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 mutation with no output schema, the description should still say what the message ID refers to and whether the move is a copy or a relocation. With one of two params undocumented and no behavioral detail beyond annotations, the definition is under-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 coverage is only 50% and the description does not compensate. 'another folder' loosely maps to mailboxId, which the schema already documents, while the required `id` parameter is completely undocumented in both schema and description (message ID vs. something else is left to inference).

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 (moves) and resource (a message) with the destination (another folder). An agent can distinguish it from mail_set_flags, mail_delete, and mail_get, though no sibling is named explicitly.

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

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

No guidance on when to use move versus alternatives such as mail_delete followed by mail_send, or versus mail_set_flags. Prerequisites (does the destination folder need to exist? what permissions?) are unstated.

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 readOnly=false, openWorld=true, idempotent=false, destructive=false, so the safety profile is covered. The description adds two non-obvious facts not in the annotations: the From address is fixed to the agent's own address, and mail to outside addresses incurs a wallet charge. It stops short of delivery behavior, rate limits, or irreversibility (no unsend), which keeps it below 5.

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

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

Two short sentences, zero filler, with the core action front-loaded and the cost caveat second. Nothing is repeated from the title or 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 7-parameter mutation with no output schema, the description covers purpose, sender identity and cost, which is the essential shape. It omits what the call returns (message id?), what happens on invalid/undeliverable recipients, and whether both body fields may be supplied — gaps that matter for an open-world side-effecting call.

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 57%: to, replyTo, htmlBody and textBody are documented, while cc, bcc and subject are bare. The description contributes one meaningful parameter fact — that no From/from address can be supplied because the sender is fixed — but says nothing about cc/bcc, the html-vs-text body relationship, or subject's requiredness. Baseline 3 fits given the partial 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?

States a specific verb and resource ("Sends an email") plus the scope of the sender identity ("from this agent's address"). It is clearly distinguishable from the read/manage siblings (mail_get, mail_list, mail_delete, mail_move) by the send verb, though it never names a sibling explicitly.

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 billing sentence implies a when-to-care condition (external recipients cost money), which is useful decision context. However, there is no explicit when-to-use/when-not guidance, no mention of prerequisites (verified domain? mailbox must exist?), and no routing to alternatives — usage is 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?

Annotations already declare non-read-only, idempotent, non-destructive behavior, so the description only needs to add context. It does add which flags are changed, but it omits important behavior such as what happens when seen or flagged is omitted, and whether auth or ownership restrictions apply.

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 no wasted words, and it front-loads the core action and affected flags.

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 mutation tool with no output schema, the description conveys the core purpose and flag meanings. However, it omits the required message id and the semantics of omitted boolean parameters, which are necessary for fully correct invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It partially explains the seen and flagged booleans through the phrases 'seen or unseen' and 'flagged or unflagged', but it does not mention the required id parameter or clarify omitted-flag behavior, leaving substantial gaps.

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 ('Marks') and resource ('a message') and names the exact flags affected (seen/unseen, flagged/unflagged). It is clear what the tool does, though it does not explicitly distinguish itself from siblings like mail_move or mail_delete beyond the flag-setting 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 implies the tool is used to change seen or flagged status, but it gives no guidance on when to use it versus alternatives or any preconditions. There are no exclusions or comparisons to sibling tools such as mail_get or mail_list.

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

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

readOnlyHint=true and openWorldHint=false already establish this as a safe, closed read, so the description only needs incremental value. It adds the return contents (balance, prices, top-up instructions), which matters because there is no output schema, but says nothing about permissions or freshness of the figures.

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 with the verb, resource, and payload listed in priority order. No filler, no 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 one-parameter read with readOnlyHint annotations and no output schema, the description covers what comes back and its scope. The only real gap is routing versus the sibling billing tools, which is a usage-guidance issue rather than a completeness one.

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 orgId property already explains it comes from org_list. The description adds no parameter meaning beyond that, so the 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?

States a specific verb and resource ('Returns the organization's shared wallet') and enumerates the payload (balance, prices, top-up guidance). It does not name the nearest siblings (billing_get, org_billing_transactions, org_billing_topup), so the 'shared wallet' scope is the only differentiator.

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 'organization's shared wallet' framing implies this is the org-level counterpart to the personal billing tools, but there is no explicit when-to-use statement, no exclusions, and no sibling named. Usage must be inferred from the scope adjective alone.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds that the operation creates a card payment link (implying no immediate charge), which is useful context beyond annotations. But it does not disclose link expiry, whether the link is single-use, or required auth scope, leaving meaningful behavioral gaps.

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 zero waste. It is appropriately sized, though its brevity contributes to the missing guidance noted elsewhere.

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

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

For a mutation tool that generates a payment link, the description omits critical context: what the link does, whether it expires, how it relates to topup_status or topup_lookup, and auth requirements. With no output schema and only 50% parameter coverage, the description should carry more weight than this one sentence provides.

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 50%: orgId is described ('Organization ID from org_list'), but amountUsd has no description beyond its name and numeric bounds. The description adds no parameter semantics whatsoever, failing to compensate for the undocumented amountUsd parameter (e.g., currency meaning, whether it is a charge or a limit).

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: 'Creates a card payment link for the organization wallet.' An agent can tell this is a link-generation tool for org funding. However, it does not differentiate this from sibling tools such as billing_topup or topup_start, which likely overlap in purpose.

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

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

There is no guidance on when to use this tool versus alternatives. Siblings like billing_topup and topup_start are not mentioned, and there is no indication of prerequisites, exclusions, or context that would route the agent 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact — results are ordered newest first — but says nothing about pagination behavior, default page size, or total counts, which matters for a ledger tool with limit/offset.

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 resource and the ordering guarantee. Nothing redundant, nothing padded.

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 paginated ledger tool with no output schema and partially documented parameters, the description should explain page size defaults, pagination semantics, and what a ledger entry contains. None of that is present, so the agent has to probe.

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 only 33%: only orgId is documented (and its 'from org_list' hint lives in the schema, not the description). The description adds no meaning for limit or offset — no default limit, no max-page guidance, no statement of whether offset pagination is stable against new transactions arriving.

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 (Lists) and resource (organization wallet ledger) plus an ordering guarantee (newest first). However, it does not distinguish this from the sibling billing_transactions, which presumably lists the personal wallet ledger, leaving the agent to infer the scope difference from the name alone.

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

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

There is no guidance on when to use this tool versus org_billing_get (balances), billing_transactions (personal ledger), or org_billing_topup. No exclusions or prerequisites are stated, so the agent must guess from naming conventions.

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 the mutation is non-read-only, non-idempotent, and non-destructive. The description adds the behavioral detail that the signed-in user becomes owner, but omits auth requirements, slug handling, and failure modes.

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 with no wasted words. The core action and owner side effect are conveyed 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 mutation tool with no output schema and 0% schema description coverage, the description is too sparse. It covers the basic outcome but leaves gaps around parameters, slug behavior, and when the operation should be chosen over alternatives.

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

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

Schema description coverage is 0%, and the description says nothing about the 'name' or 'slug' parameters. It does not compensate for the missing schema documentation, leaving parameter meaning entirely to inference from the parameter names.

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

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

The description names a specific verb and resource ('Creates an organization') and adds a relevant side effect ('the signed-in user becomes its owner'). It is clear but does not explicitly differentiate from sibling tools such as org_list or org_rename.

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 states only the bare action, with no explicit when-to-use guidance, prerequisites, or comparison to alternatives like org_list or register_agent. A user must infer that this is the tool for creating new organizations.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond 'returns' – no mention of behavior when the org is missing, authorization requirements, or what data is included in the returned organization.

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

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

One short sentence with zero wasted words, and the purpose is front-loaded. Its brevity is efficient, though it edges toward under-specification.

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 operation with annotations covering safety and a fully documented parameter, the description is minimally adequate. However, with no output schema, the description should say more about what the returned organization contains or what happens on an invalid orgId.

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 includes a clear provenance note ('from org_list'). The description adds no meaning beyond the schema, so baseline 3 applies.

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

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

The description states a verb and resource ('Returns one organization'), which is clear on its own but does not distinguish it from siblings like org_list or org_me. An agent cannot tell from this sentence whether the tool returns the caller's own org or an arbitrary org by ID.

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

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

There is no guidance on when to use this tool versus org_list, org_me, or org_usage. The only routing hint is the schema's note that orgId comes from org_list, which is not part of the description.

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=false, idempotentHint=false, and openWorldHint=true; the description adds the concrete side effect that an email is actually dispatched, which is useful. It does not explain the consequences of the non-idempotent flag (repeated calls likely send duplicate emails) or permission requirements for a mutation tool.

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

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

A single tightly-worded sentence with zero redundancy and the key effect front-loaded. It is not padded, though the brevity is under-specification rather than efficient coverage.

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?

A mutation tool that sends external email, with no output schema and no explanation of the return value (invite ID? token?), default role behavior, duplicate handling, or permission requirements. For a 3-parameter write tool, the description is too thin to let an agent call it confidently.

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

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

Schema description coverage is only 33% — only orgId carries a description. The description adds nothing about 'email' or the 'role' enum (admin vs member), nor what role is applied when it is omitted (only 2 of 3 params are required). This gap is left entirely unaddressed.

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 effect: 'Emails an invitation to join the organization.' An agent can distinguish this from org_invite_list, org_invite_revoke, and invite_accept without opening a schema, though it never says it creates a pending invite record that must later be accepted.

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

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

No guidance on when to use this versus invite_accept or regtoken_create, and no prerequisites such as required admin role on orgId or what happens if the invitee already exists. The agent must infer all selection logic from the name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered structurally. The description adds the 'pending' filter semantics, which is genuinely useful, but says nothing about pagination, ordering, or whether revoked/expired invites are excluded.

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

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

One short, front-loaded sentence with no waste. Appropriately sized for a simple list tool, though it borders on under-specification rather than elegant brevity.

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

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

For a simple one-param read tool with annotations and full schema coverage, the essentials are present. Missing are return shape hints (no output schema) and any note on pagination or result ordering, which an agent would need to use it reliably.

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?

Single required parameter orgId is fully documented in the schema (100% coverage), including its source ('from org_list'). The description adds nothing beyond that, so baseline 3 applies.

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

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

States a specific verb and resource ('Lists ... invitations') and narrows scope with 'pending'. It is distinguishable from org_invite_create and org_invite_revoke by virtue of being read-only, though it doesn't explicitly contrast with org_member_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?

No indication of when to use this versus org_member_list or org_get, and no prerequisites mentioned. The agent must infer context entirely from the name.

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=false and destructiveHint=true, so the destructive nature is covered structurally. The word 'pending' adds real context beyond annotations (only unaccepted invites can be revoked), but reversibility, required permissions, and whether the invitee is notified are unstated.

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

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

One front-loaded sentence, zero filler and no repetition of the title. It is efficient rather than padded; the brevity is under-specification rather than verbosity.

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, irreversible-sounding mutation with no output schema and an undocumented required inviteId, the description should say what happens after revocation and how to obtain the ID. As written, an agent can only guess at preconditions and outcomes.

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

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

With only 50% schema description coverage, only orgId is documented ('Organization ID from org_list.'). inviteId has no description anywhere, and the tool description does not explain it or note that it comes from org_invite_list — a gap the description should compensate for but does not.

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

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

States a specific verb and resource (revoke an invitation) and narrows scope with 'pending'. It does not distinguish itself from near-siblings such as org_member_remove or regtoken_revoke, which also revoke access objects, so an agent gets a clear action but no sibling routing.

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

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

No guidance on when to use this versus org_member_remove (already-joined member) or invite_accept, and no hint that inviteId must first be obtained via org_invite_list. Nothing tells the agent what condition selects 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful access-scoping detail (results are limited to the signed-in user's memberships), which implies an auth requirement, but says nothing about ordering, pagination, or result shape.

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 the scoping qualifier front-loaded and no filler. Nothing is repeated from the title or 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 zero-parameter read tool with annotations covering safety and no output schema, this is essentially enough to call correctly. Only minor gaps remain, such as whether the list is empty when the user has no memberships.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline applies. The description correctly signals that no filter arguments are 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?

States a specific verb (Lists) and resource (organizations) with a clear scope: only the ones the signed-in user belongs to. It is distinguishable from org_get, which fetches a single organization, though it does not name that sibling explicitly.

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 scope: call it to discover which organizations the caller can act in. No explicit when-to-use, prerequisites, or pointer to alternatives like org_get/org_me 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?

Beyond the annotations, the description discloses that an external email is sent and that an account is created on first login. This adds useful behavioral context for a non-read-only, open-world operation. It still omits rate limits, code expiry, and the expected response, so it is not fully comprehensive.

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 the primary action front-loaded. Every sentence adds relevant information without repetition 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 simple one-parameter tool with annotations and no output schema, the description covers the core action and account-creation side effect. It is still missing the login flow context, especially that org_login_verify is the likely next step and what the caller should expect in response.

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

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

There is one parameter, email, and schema description coverage is 0%. The description partially compensates by indicating that the email is a human's address to which the code is sent, but it does not explicitly describe the parameter or clarify account identity beyond that.

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

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

The description uses a specific verb and resource: it emails a 6-digit dashboard login code to a human's address. It also states the account-creation side effect on first login. It is clear, but it does not explicitly distinguish itself from the sibling org_login_verify.

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

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

The description implies the tool is for initiating a human dashboard login, especially for first-time users because it creates the account. However, it gives no explicit when-to-use guidance, no exclusions, and does not name org_login_verify as the follow-up verification step.

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=false and idempotentHint=false, so the write/non-repeatable nature is covered structurally; the description usefully adds that the code is consumed to mint a session token. It does not disclose code expiry, single-use failure behavior, or what happens on an invalid code, which for a security-sensitive auth step is a real gap.

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

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

A single front-loaded sentence with zero filler and the input/output transformation stated immediately. It is efficient, though its brevity is part of why other dimensions fall short.

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

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

There is no output schema, and the description partially compensates by naming the returned session token. However, with 0% parameter documentation and no annotation coverage of auth-specific behavior (code lifetime, failure modes), the description is only minimally sufficient for an authentication tool.

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

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

Schema description coverage is 0% for both parameters, so the description carries the full burden — yet it only obliquely references the code ('emailed login code') and never mentions the required email parameter at all. The 6-character code constraint resides solely in the schema with no reinforcing explanation.

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?

Names a specific verb ('exchanges') and both resources involved: the emailed login code as input and the dashboard session token as output. It is clearly distinguishable from org_login_request_code, but the description never explicitly contrasts the two, so the differentiation is inferred rather than stated.

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 'emailed login code' implies the prerequisite flow (a code must first be requested via org_login_request_code), but the ordering is never stated and no alternative or exclusion is given. An agent can infer the login flow, but nothing is 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?

The annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds useful scope beyond the annotations by specifying that the target is the current dashboard session token, though it does not state auth requirements or whether other sessions are unaffected.

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?

It is a single front-loaded sentence with no wasted words. The action and target 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 zero-parameter logout tool with annotations covering safety and idempotency, and no output schema, the description provides the essential action and target. It could optionally clarify post-revocation behavior, but it is complete enough 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 tool has zero parameters, so the baseline is 4 under the scoring rules. The description correctly does not invent parameter semantics where none exist.

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

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

The description uses a specific verb plus resource: 'Revokes the current dashboard session token.' This clearly distinguishes it from login, identity, and other org tools in the sibling list without requiring the agent to infer the action.

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 use case (ending the current dashboard session), but it does not explicitly say when to use it versus alternatives such as org_login_verify or org_me. For a single-purpose logout tool the intent is inferable, so it is minimum viable rather than fully guiding.

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 establish that this is a read-only, non-open-world operation, lowering the disclosure burden. The description adds that the result includes the signed-in user and their organizations, but it does not mention authentication requirements, error behavior, or any structural detail about the returned 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, front-loaded sentence with no wasted words. It immediately conveys the core identity and scope of the 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 no-parameter identity tool, the description covers the essential purpose, but with no output schema it only minimally describes return values and does not clarify relationships to sibling tools or authentication context. It is adequate but leaves meaningful gaps for an agent deciding between this and org_get or org_list.

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 parameter semantics are inherently simple and the baseline is 4. The description does not need to explain any input parameters, and the empty schema is consistent with the no-argument nature of the 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?

The description states a specific verb ('Returns') and resource ('the signed-in user and the organizations they belong to'), making the tool's purpose immediately clear. It does not explicitly differentiate itself from nearby siblings like org_get, org_list, or org_member_list, so it falls short of a 5.

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 description: call this when you need the current signed-in identity and its organization memberships. However, there is no explicit when-to-use guidance, no exclusions, and no reference to alternative tools such as org_get or org_list.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only that roles are included in the result, and says nothing about pagination, result size, or ordering for a potentially large member 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 front-loaded sentence with zero filler; the verb and resource come first and nothing needs trimming.

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, read-only list tool with annotation coverage and no output schema, the essentials are present. Still missing are return shape hints (pagination, whether role names or IDs are returned) that would help an agent consume the result 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% and the single orgId parameter is documented with a clear provenance hint ('Organization ID from org_list.'). The description merely implies this parameter and adds no syntax or sourcing detail beyond what the schema provides, so the 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?

States a specific verb ('Lists') and a precise resource ('an organization's members and their roles'), which unambiguously separates it from mutation siblings such as org_member_remove and org_member_set_role. It does not explicitly name any sibling or scope boundary, so it stops short of a 5.

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 read-only listing purpose implies when to call it (inspecting membership), and the sibling names make the alternatives guessable. However, the description never states a when-to-use condition, prerequisites, or a named alternative, leaving usage to inference.

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 covered. The description adds useful behavioral context that userId equal to your own means leaving the organization, but it does not disclose permission requirements, irreversibility, or effects on resources owned by the removed member.

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 definition is a single tight sentence with the main action front-loaded and the self-leave special case immediately after. There is no wasted text.

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 two-parameter mutation with no output schema, the description covers the core action and the self-leave behavior. However, it omits important operational context such as required role/permissions, whether the action is reversible, and where to obtain the target userId.

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 50%: orgId is documented as coming from org_list, while userId has no schema description. The description partially compensates by explaining that userId set to your own account changes the operation into a self-leave, but it does not explain how to obtain another user's ID or any other userId constraints.

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 ('Removes a member from the organization') and adds the important special case of self-removal as leaving. It is clearly distinguishable from siblings like org_member_set_role and org_member_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 implies when to use the tool by naming the removal action and the self-leave case, but it does not explain when to choose this over alternatives such as org_invite_revoke, nor does it state prerequisites like admin/owner permissions.

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=false, destructiveHint=true, and idempotentHint=true, so the safety profile is known. The description adds nothing beyond that: it does not explain what happens to the previous role, whether owner promotion transfers ownership, whether the last owner can be demoted, or what errors occur on permission failure.

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 four-word sentence is technically efficient and front-loaded, but for a destructive three-parameter mutation it is undersized rather than concise; the one sentence does not earn its place as a usable 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 destructive, non-reversible-privilege mutation with 33% schema coverage and no output schema, the description should explain permission requirements and role semantics. Neither is present, leaving the agent dependent on the annotations and the partially documented 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?

Schema coverage is only 33% – only orgId carries a description ('Organization ID from org_list'). The description mentions no parameters at all, so it does not compensate for the undocumented userId or clarify that 'role' accepts exactly owner/admin/member or what each role grants.

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 'Changes a member's role' is essentially a paraphrase of the tool name (org_member_set_role) and title ('Change member role'), which is the definition of tautology. It does identify a verb and resource, but adds no distinguishing information such as which org/user scope applies or how it differs from org_member_list or org_member_remove.

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

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

There is no guidance on when to use this tool versus siblings like org_member_remove or org_invite_create, and no mention of prerequisites such as caller permissions (owner/admin required to change roles). The agent must infer everything from the name alone.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, and the description adds nothing beyond that — no note on whether the old name becomes available, uniqueness constraints, or what permissions are required. No contradiction with the annotations, but zero added behavioral value.

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

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

A single short sentence with no wasted words, but the brevity is under-specification rather than economy — there is no front-loaded scoping detail to anchor the call.

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 mutation tool with no output schema and only 50% parameter documentation; the description should at least cover required permissions, name constraints, and whether the change propagates to domains/mailboxes under the org. None of that is present.

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 50%: orgId carries a cross-reference to org_list, but the name parameter has only maxLength=80 and no semantic guidance. The description contributes nothing about naming rules, uniqueness, or character restrictions, so it fails to compensate for the gap.

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?

"Renames an organization" essentially restates the tool name org_rename and the title "Rename organization" — no scope, no mention of what identifies the org or what the rename affects. There is no differentiation from siblings such as org_create or mailbox_rename beyond the resource noun.

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 statement of when to use this versus alternatives, no prerequisites (e.g., admin role), and no exclusions. The agent must infer everything from the name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that counters are daily and aggregate send/receive/API metrics, but omits return shape and how the 'breakdown' option alters behavior, leaving the mutation of output undocumented.

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 verb, resource, metrics and scope with zero filler. Nothing is repeated from the title beyond the necessary resource name.

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?

Annotations cover read-only safety and the schema fully documents inputs, but with no output schema the description should say what the counters look like or how the agent breakdown changes the response. Omitting that leaves a moderate gap for an analytics-style tool.

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

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

Schema coverage is 100%, so all four parameters including defaults and the breakdown enum are documented structurally. The description adds only the 'daily' notion of granularity and nothing on date semantics or the agent split, so 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?

States a specific verb (returns) and resource (daily send, receive and API counters) with organization-wide scope, which separates it from agent_usage and domain_usage by implication. It never names those siblings, so differentiation is inferred rather than explicit.

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 scope phrase 'across the organization' hints at when to pick this over agent_usage/domain_usage, but there is no explicit when-to-use, prerequisite, or exclusion statement. Usage is implied only.

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=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior — an outbound HTTPS POST fired when mail arrives — but says nothing about duplicate registrations, whether a signing secret is issued, or whether the endpoint must be verified first.

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 carrying the verb, the artifact created, and the trigger condition, with zero filler. Nothing in it is redundant with 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 4-parameter mutation tool with no output schema, the definition covers what is created and what fires it, which is enough to call it correctly. The remaining gap — no mention of the created resource's identifier or secret — is modest and partially inferred from the required parameters.

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 75%: url, orgId and agentId are documented, but `eventTypes` has no schema description. The description implies the notification event (mail arrival) yet does not enumerate accepted event-type values, so it fails to compensate for the one undocumented 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?

Specific verb ('Registers') plus resource ('an HTTPS URL') plus scope ('organization's inboxes'), so the agent knows exactly what is created and what triggers it. However, it never distinguishes itself from the sibling `webhook_create`, which appears to be the non-organization variant, leaving the agent to infer which one applies.

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 'at one of the organization's inboxes' implicitly scopes this to org-level, inbox-scoped webhooks, which hints at the split from `webhook_create`, but there is no explicit when-to-use statement or exclusion. No prerequisites (auth/role, URL verification, limits) are mentioned.

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 description need only add context — yet it adds nothing about irreversibility, whether pending deliveries or history are discarded, or what happens on a bad/unknown id.

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

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

One short, front-loaded sentence with no waste, but its brevity comes at the cost of under-specification rather than 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?

A destructive, irreversible mutation with no output schema and a 2-param schema where one param is undocumented — the description should at minimum say what is destroyed and how to obtain the id, and it says neither.

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 only 50%: orgId carries a description, but 'id' is undocumented in both schema and description, and the description gives no hint that it is the webhook endpoint identifier to delete.

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 ('Deletes a webhook endpoint'), but the title's distinguishing word 'organization' is dropped, so it reads as a near-paraphrase of the title and does not separate it from the sibling webhook_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?

No guidance on when to use this versus webhook_delete or the other webhook siblings (list, enable, resend, deliveries), and no preconditions such as needing the webhook ID from org_webhook_list.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that results are 'recent delivery attempts,' implying a bounded, time-ordered result set, but it never explains how many are returned, whether pagination exists, or what failure information a delivery record carries. With annotations carrying the read-only signal, this is an adequate but thin contribution.

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, and the operative noun ('delivery attempts') lands early. It is efficient, though its brevity edges toward under-specification rather than maximal information density.

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

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

There is no output schema, so the description should describe what a delivery record contains, how many are returned, and whether results are truncated or paginated. None of that is present, and with one of two parameters undocumented the definition leaves an agent guessing about the return shape and result bounds.

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 50%: `orgId` is documented against `org_list`, but `id` has no description at all. The phrase 'for a webhook endpoint' implies that `id` is the webhook endpoint identifier, which is a real but marginal addition over the bare schema. Baseline 3 is appropriate given the schema does half the work.

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: 'Lists recent delivery attempts for a webhook endpoint.' An agent can immediately tell this is the read side of webhook diagnostics. It does not, however, distinguish this from the sibling `webhook_deliveries`, which appears to serve the same function on a different scope (org webhook vs. webhook).

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 when-to-use guidance, no exclusion clauses, and no mention of the sibling `webhook_deliveries` or of `org_webhook_resend`, which is the natural follow-up action. The agent must infer from the name alone that this is scoped to org-level webhooks rather than individual ones.

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 disclose that this is a non-read-only, idempotent, non-destructive operation. The description adds useful context about the failure state that caused the webhook to be disabled, but it does not explain what re-enabling changes, whether failure counters reset, or what happens if the webhook is already enabled.

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 front-loads the operation and immediately explains the context in which it applies.

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 annotations cover the safety profile and idempotency, and no output schema exists. However, the description omits the organization scope and the meaning of the id parameter, leaving gaps for a two-parameter mutation 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 description does not mention either parameter. The schema documents orgId as the organization ID from org_list but leaves id undocumented. With only 50% schema description coverage, the description should compensate by clarifying that id is the webhook endpoint ID, but it does not.

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

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

The description states a specific verb and resource: re-enabling a webhook endpoint that was switched off after repeated failures. The purpose is clear, but it does not explicitly distinguish this organization-scoped tool from the sibling webhook_enable tool.

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

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

The phrase "switched off after repeated failures" implies when the tool is appropriate. However, it does not state when not to use it or mention alternatives such as webhook_enable for non-organization webhooks.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is clear. The description adds useful scope context ('across the organization's inboxes') but does not disclose return format, pagination, or aggregation 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?

The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core purpose and scope.

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 list tool with one fully documented parameter and annotations covering the safety profile, the description is largely complete. It could be slightly stronger by clarifying the relationship to webhook_list or whether results span all inboxes, but no critical 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 orgId parameter is already documented in the schema as coming from org_list. The description adds no additional parameter meaning beyond what the schema provides, which is appropriate for a one-parameter tool with full 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 gives a specific verb ('Lists') and resource ('webhook endpoints') scoped to the organization's inboxes. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling webhook_list tool or clarify whether it aggregates across all inboxes.

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 organization-level scope: an agent can infer this is for org-wide webhook listing rather than inbox-specific listing. However, there is no explicit guidance on when to use this versus webhook_list, nor any stated prerequisites or exclusions.

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

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

The description adds useful asynchronous semantics with 'queues' beyond the annotations, which already state readOnly=false, openWorld=true, idempotentHint=false, and destructiveHint=false. However, it does not clarify non-idempotency, authorization needs, or what happens to the queued delivery.

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 single sentence is front-loaded and free of filler, but it is too terse for a mutation tool with three required identifiers. Conciseness is good, but structure and helpful detail are lacking.

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 a non-readonly, non-idempotent, open-world mutation with three required parameters and low schema coverage, the description is incomplete. It omits required identifier meanings, side effects, and any relationship to org_webhook_deliveries.

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

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

Schema description coverage is only 33%; only orgId is documented in the schema. The description contributes no meaning for id or deliveryId, so it does not compensate for the missing parameter 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 states an action ('queues') and outcome ('sent again') but never names the resource as a webhook delivery; that only comes from the name/title. It also does not distinguish this org-scoped resend from the sibling webhook_resend tool.

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

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

There is no guidance on when to use this tool versus alternatives such as org_webhook_deliveries or webhook_resend. No prerequisites, context, or exclusions are 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 establish non-readOnly, non-idempotent, non-destructive, so the bar is lower. The description adds genuinely useful behavior beyond them: the agent gets its own email address and the API key is "shown once" — i.e. non-recoverable after this call. It stops short of stating whether mailboxes/billing are provisioned or what happens on duplicate localPart.

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

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

One sentence, front-loaded with the create action and ending on the highest-value detail (key shown once). 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?

Return behavior is disclosed and there is no output schema to explain. The main gap is the zero-required-parameter case: what an agent created with no arguments actually gets, which matters because all four params are optional.

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%, including the localPart/domainToken pairing and the did:key alias note, so the schema already carries parameter meaning. The description adds no parameter-level context, which is 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?

Specific verb and resource ("Creates a new agent") plus two distinguishing outcomes (own email address, API key returned once). Clearly separable from agent_get / agent_delete / apikey_create, though it never names those siblings explicitly.

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

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

No guidance on when to register an agent versus creating a bare API key via apikey_create, no prerequisites stated, and no note that the call can succeed with zero parameters. The agent must infer all of this from the schemas.

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 this is a non-readonly, non-idempotent, non-destructive creation. The description adds a genuinely useful behavioral fact beyond them: 'Shown once', warning the caller that the token value is returned only at creation and must be captured. It omits expiry, scope, and whether multiple tokens may coexist.

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

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

Two short sentences with the core action first and the important 'Shown once' caveat second; nothing is wasted. The final fragment is terse to the point of being slightly under-explained, which is the only cost.

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 3-parameter creation tool with no output schema, the description covers purpose and one critical behavior but leaves out token lifetime, permissions required, and what the returned object contains. Enough to call it, not enough to call it confidently.

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?

orgId and domainId are documented in the schema with sourcing hints (org_list / domain_list), while label is undocumented in both places at 67% coverage. The description itself adds no parameter meaning, so the baseline of 3 for schema-led documentation 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?

States a specific verb and resource ('Creates a token') plus the effect ('lets an agent register its own address on this domain'), which distinguishes it from regtoken_list and regtoken_revoke. It never names the consuming tool register_agent explicitly, so routing is inferable rather than stated.

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 purpose sentence implies when to use it (before an agent registers on a domain), but there is no explicit when/when-not or named alternative such as regtoken_list for inspecting existing tokens. Usage is left to inference from the intent statement.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered without the description's help. The description adds only the domain scoping detail; it says nothing about pagination, ordering, or whether token secrets are returned, which are the traits that actually matter for a token-listing call.

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

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

One short, front-loaded sentence with zero filler. It is efficient but so terse that it borders on under-specification rather than optimal sizing.

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 two-parameter list tool with full schema coverage and read-only annotations, the essentials are present. However, with no output schema, the description never indicates what a returned token record contains (e.g., whether the token value is exposed) or whether results are paginated.

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 required parameters (orgId, domainId) are documented in the schema, including where to obtain the IDs. The description's phrase 'a domain's' reinforces domainId but adds nothing about orgId or ID formats, so the 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 gives a specific verb ('Lists') and resource ('registration tokens') plus a scope ('a domain's'), so the agent knows exactly what the tool retrieves. It does not name or differentiate itself from the adjacent regtoken_create / regtoken_revoke siblings, which keeps it short of a 5.

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 statement of when to use this versus regtoken_create, regtoken_revoke, or agent_list; the agent must infer that 'list' means read-only enumeration. No prerequisites (e.g., needing a verified domain) are mentioned.

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. The description adds no behavioral context beyond the title, such as irreversibility, impact on existing agents, or permission requirements.

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 single sentence is concise and front-loaded, but it is largely tautological and omits any useful structure or detail. It avoids bloat but does not earn its place beyond 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 mutation tool with three required parameters and no output schema, the description is incomplete. It does not explain effects, prerequisites, or what revocation means operationally.

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 documents orgId and domainId, but tokenId has no schema description. The description mentions no parameters, so it does not compensate for the 67% schema description coverage or the undocumented required tokenId.

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 restates the tool name and title almost exactly: "Revokes a registration token." It identifies the verb and resource, but adds no scope, constraints, or distinction from sibling revoke/list/create 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?

There is no guidance on when to use this tool versus alternatives such as regtoken_list or regtoken_create, nor any prerequisites or exclusions. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is clear. The description adds that this is a hypothetical lookup ('would credit') and mentions allowed amounts, but does not describe error behavior for unknown addresses or any auth requirements.

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 definition is a single efficient sentence with no wasted text. The key behavior is front-loaded, though the term 'Mailgi' is ambiguous and slightly undermines precision.

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 and the description covers the core return concepts (wallet and allowed amounts). Still, without an output schema, it could say more about response shape or what happens if the address has no eligible wallet.

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 address parameter is already documented as 'The agent's email or alias address.' The description's 'Mailgi address' adds little beyond the schema and contains a likely typo.

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 ('Shows') and states the resource: which wallet a top-up would credit plus allowed amounts. It is clearly a read-only lookup, though it does not explicitly distinguish itself from siblings like topup_start or topup_status.

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: this is a pre-top-up lookup to see where funds would go and what amounts are permitted. However, the description never states when to use this versus topup_start, topup_status, or billing_topup, nor does it mention prerequisites such as authentication.

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 a non-read-only, non-idempotent, non-destructive operation; the description usefully adds that the result is a link handed to a human rather than an automatic charge. It does not disclose the consequences of the non-idempotent hint (does calling twice create two payable links?), link expiry, or whether funds move before payment.

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

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

Two short sentences, zero filler, with the core action and the human hand-off requirement front-loaded. Nothing 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 mutating two-parameter tool with no output schema and no read-only safety net, the description covers what is produced (a payment link) but omits link lifetime, what happens on repeat invocation, and whether a pending top-up already exists. It is adequate but leaves real operational 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%, so both parameters are already documented, including the 'range from topup_lookup' constraint. The description's 'wallet behind any Mailgi address' reinforces that address can be an alias and that it identifies an existing wallet, but adds no format or validation 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?

States a specific verb and artifact ('Creates a card payment link') scoped to 'the wallet behind any Mailgi address', which is far more informative than the name alone. It does not explicitly contrast with topup_lookup or topup_status, so sibling differentiation is left mostly to the naming convention.

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?

'Give it to a human to pay' implies the human-in-the-loop flow and its intended purpose, but there is no explicit when-to-use guidance relative to topup_lookup (pre-check amount range) or topup_status (poll payment state). The reader must infer the sequence 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?

The annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds that the result indicates paid and credited status, but does not describe error cases, session expiry behavior, or possible return values beyond that single condition.

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 immediately communicates the core return semantics.

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 status check with one fully documented parameter and annotations covering safety, the description is largely complete. It could be improved by naming alternatives or clarifying return states, but 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 description coverage is 100%, so the single sessionId parameter is fully documented in the schema. The description does not add any parameter meaning beyond what the schema already provides, which is the baseline expectation at full 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 and resource: it returns whether a top-up payment has been paid and credited. This distinguishes it from topup_start, but it does not explicitly differentiate it from topup_lookup or other sibling 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?

The description states what the tool returns but gives no guidance on when to use it versus alternatives such as topup_lookup or topup_start. The agent must infer the use case from the tool name and sibling list.

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