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

With no annotations provided, the description carries the full burden of behavioral disclosure, yet it only restates the action. It does not reveal whether adding is additive or overwrites existing ranges, what happens on duplicate ranges, whether the change is immediately enforced, or what the response contains. For a mutating tool with zero annotation coverage, this is a significant gap.

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

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

The single sentence is tight, front-loaded with the verb, and contains zero wasted words. However, for a tool with four required parameters and no schema descriptions, this brevity borders on under-specification rather than disciplined conciseness.

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

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

Given four required parameters, 0% schema description coverage, and no annotations, a one-sentence description is inadequate. The output schema helps with return values, but the description fails to explain zoid semantics, IP range format, role association, and the relationship to the get_allowed_ips/delete_allowed_ips lifecycle.

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

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

Schema description coverage is 0% and the description does not compensate. While from_ip_range and to_ip_range are partially self-explanatory, the format of the IP values is unspecified, the meaning of zoid is cryptic, and the relationship between role_id and the IP range (does the role gain access to that range?) is entirely unexplained.

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

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

The description states a specific verb ('add'), a specific resource ('allowed IP range'), and a scope ('for organization'), and it is clearly distinct from the sibling tools get_allowed_ips and delete_allowed_ips by virtue of the verb. However, it does not explicitly name or contrast the sibling alternatives, and it omits the range semantics (from/to) hinted at in 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 provides no guidance on when to use this tool versus get_allowed_ips or delete_allowed_ips, no prerequisites (e.g., a valid zoid, existing organization), and no context about whether to check existing ranges before adding. An agent must infer all usage context from the tool name alone.

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

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

No annotations are provided, so the description carries the full disclosure burden, but it only states the intent to add. It fails to disclose behavioral implications of a catch-all: whether it changes routing for all unaddressed mail, whether it can replace an existing catch-all, whether the address must already exist as a mailbox, or whether domain verification 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 a single efficient sentence with the action verb front-loaded and zero wasted content. It earns a 4 rather than 5 because the brevity sacrifices information that a slightly longer phrasing could have absorbed 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?

Despite an output schema existing (so return values need not be explained), the description is incomplete for a mutating email-routing tool with three undocumented parameters and no annotations. Missing context includes behavioral side effects, prerequisites, idempotency, and what distinguishes a valid catch-all setup.

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

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

Schema description coverage is 0%, so the description must compensate, but it only implicitly maps 'domain' to domain_name and 'catch-all address' to catch_all_address. The zoid parameter is entirely unexplained, and there is no hint about what format catch_all_address should take (e.g., existing mailbox vs. arbitrary address).

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 ('Add'), resource ('catch-all address'), and scope ('for domain'), which clearly conveys what the tool does and distinguishes it from siblings like delete_catch_all_address. It falls short of a 5 only because it states the bare action with no elaboration on what a catch-all address accomplishes.

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

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

The description provides zero guidance on when to use this tool, when not to, or how it relates to the closely-related sibling tools (delete_catch_all_address, add_domain_alias, verify_domain). An agent is given no context about prerequisites such as domain verification or when a catch-all is the right mail-routing strategy.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says an add operation occurs, with no mention of permissions, side effects, duplicate handling, required preconditions, or whether changes are 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?

The description is a single, front-loaded sentence with no wasted words. However, it is so minimal that it under-specifies behavior; brevity is achieved at the expense of useful context.

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

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

Given this is a mutation tool with three required parameters and no annotations, the description is incomplete for reliable invocation. It does not explain the meaning of the parameters, prerequisites, or expected outcomes, even though an output schema exists.

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

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

Schema description coverage is 0% and the description adds no parameter-level information. It does not clarify the meaning of domain_name or admin_email, leaving ambiguity about whether these refer to the child organization or the partner portal.

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 ('Add') and resource ('child organization to a partner portal'), making the core purpose clear. It is not a tautology and names a distinct context, though it does not elaborate on what a child organization is or how it relates to the partner portal.

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

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

No guidance is given about when to use this tool versus alternatives, prerequisites, or scenarios where it should be avoided. Sibling tools like add_user or add_domain exist, but the description does not distinguish this tool's use case from them.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and only states the bare action. It does not disclose side effects such as whether setting is_default=true alters the domain's default DKIM key, whether existing DKIM settings are overwritten, or whether the change is reversible. For a mutating tool with zero annotation coverage, this is a substantial gap.

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

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

The six-word sentence is front-loaded with the verb and contains zero fluff, which is structurally sound. But the brevity reflects under-specification rather than deliberate compression: a five-parameter mutation tool with side effects and sibling ambiguity needs more than one sentence to justify this level of conciseness.

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

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

For a tool with five parameters, 0% schema coverage, no annotations, and four DKIM-related siblings, this one-liner is severely incomplete. The output schema mitigates the return-value burden, but input semantics (notably zoid), prerequisites, side effects, and sibling differentiation are all missing, so an agent cannot reliably invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate, yet it adds nothing about any of the five parameters. The DKIM/domain context helps interpret selector, key_size, is_default, and domain_name, but zoid is completely opaque—neither the schema nor the description explains what it refers to.

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 pairs a specific verb ('Add') with a specific resource ('DKIM details') and target ('domain'), so the basic function is clear. However, it provides no differentiation from DKIM sibling tools such as set_default_dkim, regenerate_dkim_key, verify_dkim_key, and delete_dkim_detail, so an agent cannot tell which DKIM operation this is from the description 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?

The description gives no guidance on when to use this tool versus the DKIM-related alternatives, and states no prerequisites such as the domain already existing via add_domain. No workflow ordering is hinted either—for instance, whether one should add DKIM details before or after verify_dkim_key or set_default_dkim—so there is no help choosing among siblings.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Add domain to organization' merely restates the operation and gives no information about side effects, verification workflows, domain-existence conflicts, idempotency, or required 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 sentence is brief and front-loaded with zero wasted words. However, the brevity reflects under-specification rather than deliberate editing, and the lack of any additional structured content limits its usefulness.

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?

An output schema exists, so return values need not be described, but critical operational context is missing. For an unannotated mutation tool, the description should at least clarify the meaning of zoid, the nature of the domain being added, and how this step relates to other domain-management siblings; none of this 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 description coverage is 0%, so the description must compensate, but it does not. 'Zoid' is completely unexplained and the expected format of domain_name is unspecified (e.g., bare domain vs. protocol-prefixed), leaving an agent without enough information to correctly populate required arguments.

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 ('add') and resource ('domain') with a target ('organization'), making the core action clear. However, it does not differentiate this from domain-related siblings such as add_domain_alias, verify_domain, or set_primary_domain, so an agent must inspect other tools to disambiguate.

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 exclusions, and no mention of alternatives despite many closely related domain tools in the sibling list. The description also omits sequencing details, such as whether domain ownership must be verified before or after calling 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Add domain alias' only implies a mutation and reveals nothing about side effects, required preconditions, idempotency, or whether the alias needs verification. This is a very thin disclosure.

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 three-word imperative with no filler, and the core action is front-loaded. It is efficient, though it lacks the supporting detail that a tool with no annotations should carry.

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 three required parameters, no annotations, and no parameter-level help, a single phrase leaves too much unspecified. An agent cannot infer valid inputs, operational effects, or expected output, making the description inadequate for correct invocation without external knowledge.

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

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

The schema has three required parameters with zero description coverage, and the tool description adds no parameter detail whatsoever. The agent is left to guess what 'zoid' means and what formats are expected for 'domain_name' and 'domain_alias', so the description fails to compensate for the schema 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?

The description states a clear verb ('Add') and resource ('domain alias'), and the sibling tool 'remove_domain_alias' makes the primary action distinguishable. However, it does not clarify what a domain alias is or how this differs from 'add_domain', so it is slightly under-specified.

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

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

No guidance is given on when to use this tool over alternatives like 'add_domain' or 'remove_domain_alias'. There are no conditions, prerequisites, or exclusions, so the agent must infer usage solely from the tool 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?

No annotations are provided, so the description carries the burden of disclosing behavior. 'Add' implies a write operation, but there is no mention of side effects, idempotency, permissions, failure behavior, or what happens if the address already exists.

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

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

The description is a single short sentence with no filler, but it is too terse to provide meaningful operational guidance. It is concise but under-specified rather than well-structured for an agent.

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 three required parameters and no annotations, yet the description offers only the barest summary. Essential context about the domain association, the notification address semantics, and operational implications 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 0%, and the description does not compensate. 'domain' and 'notification address' are echoed from the parameter names, but the format or purpose of notification_address is not explained, and zoid is left completely undefined.

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

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

The description clearly states the action ('add') and the resource ('notification address') scoped to a domain. This distinguishes it from siblings like delete_notification_address and add_domain, though it does not explain what a notification address is.

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

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

No guidance is given about when this tool should be used, what prerequisites exist, or how it compares to related domain-management tools. The agent must infer usage entirely from the name and the single sentence.

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

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

With no annotations provided, the description must disclose behavioral implications, but it only restates the core action of adding a task. It does not mention permissions, side effects, how the task is scoped, or whether existing tasks or groups 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?

The single sentence is concise, but it is not appropriately sized because it omits essential parameter and scoping details. The ambiguous 'group/personal' phrasing also reduces clarity rather than adding 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?

Given the nested task_data object, required zgid parameter, and no schema descriptions, this one-line description is insufficient for correct invocation. An agent cannot determine required task fields, the group/personal distinction, or how zgid should be used.

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 never mentions zgid or task_data. Because task_data is an unconstrained nested object, the lack of any parameter guidance leaves the agent without enough information to construct a valid payload.

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

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

The description clearly names the verb 'Add' and the resource 'task', and it distinguishes this creation action from the task-related siblings that get, update, or delete tasks. However, the 'group/personal' qualifier is ambiguous and does not explain how the two variants are selected.

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

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

No guidance is provided on when to use this tool versus alternatives, when a task counts as 'group' vs 'personal', or what the required zgid parameter represents. The description does not mention any exclusions or preconditions.

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 does state that this adds a user, which clearly implies mutation, but with no annotations provided the description carries the full burden of behavioral disclosure. It does not explain whether the operation is idempotent, what side effects occur, what permissions are required, or what happens on duplicate or invalid input.

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 filler. It is concise, though it achieves conciseness by omitting information that other dimensions need; as a pure conciseness measure this is acceptable.

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

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

For a tool with two required parameters, one of which is undocumented and a free-form nested object, the description is far too thin. An output schema exists, so the description need not cover return values, but it still leaves crucial invocation details, especially the meaning of zoid and the expected shape of user_data, entirely 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 0%, and the description adds no meaning to the parameters. 'zoid' is left entirely unexplained, and 'user_data' is a free-form object with no structure or example, so an agent has no way to construct a valid call beyond guessing.

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 ('Add'), a specific resource ('user'), and a target scope ('to organization'). It is clear enough to understand the core operation, but it does not differentiate from sibling tools such as add_child_organization or get_all_users, so an agent would need extra inference to know exactly which operation is intended.

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

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

No guidance is given about when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or related tools, leaving the agent to guess whether this is the right operation for a given user-management task.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it states only the bare action. It does not disclose side effects of creating a bookmark in a group, whether the operation appends or creates fresh, any permission requirements, or what the response contains. This is the same gap as the LOW calibration case 'Process' — no behavioral information at all.

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 three-word description is under-specification rather than genuine conciseness. Every word restates the tool name, so no sentence earns its place by adding information. The description is short but empty, and it lacks the structure needed to convey any useful guidance.

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 tool has a nested object parameter, a free-form bookmark_data schema, zero schema descriptions, and no annotations, making it relatively complex to invoke correctly. Even though an output schema exists, the entire input contract is undocumented, so an agent could not construct a valid bookmark payload. The description is completely inadequate for its complexity.

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

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

Schema description coverage is 0% and the description mentions neither group_id nor bookmark_data. bookmark_data is an open object (additionalProperties: true), giving an agent no way to infer the required fields of a bookmark. Since coverage is far below 50%, the description was required to compensate but provides nothing, leaving both parameters essentially undefined.

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 'Create a bookmark.' restates the tool name create_bookmark almost verbatim, which makes it tautological under the rubric. It does identify the verb and resource, so it is not missing, but it adds no detail about what a bookmark contains or how this operation relates to sibling tools like get_all_bookmarks, get_bookmark_details, and delete_bookmark.

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

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

The description provides zero guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., whether an existing group is required), when creation is appropriate versus retrieval or deletion, or any context for choosing among the 89 sibling tools. There is no exclusionary language and nothing to route an agent toward correct usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that a folder is created, without mentioning effects like duplicate handling, required permissions, folder_data structure, or any side effects. This is minimal and leaves important behavior undisclosed.

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 only one sentence and front-loaded, but it is under-specified rather than concise. It omits essential information about both parameters and the expected behavior, so the brevity is a weakness rather than a strength.

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

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

Given the tool has two required parameters, one being a free-form nested object, and no annotations, this description is severely incomplete. An agent cannot determine what folder_data should include or how account_id should be used. The presence of an output schema does not make up for missing invocation guidance.

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

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

Schema description coverage is 0%, and the description does not compensate. It does not explain what account_id represents or what folder_data should contain. Since folder_data is an unconstrained object with additionalProperties true, the agent receives no structural or semantic guidance for constructing valid input.

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

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

The description states a clear verb and resource: 'Create a new folder.' This distinguishes it from sibling tools like delete_folder and rename_folder. However, it is very terse and does not add any scoping detail about the account or folder data, so it stops just short of a top score.

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

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

The description gives no guidance on when to use this tool versus alternatives, no context for selecting it, and no exclusions. An agent must infer from the name that this should be used when a folder needs to be created.

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

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

No annotations are provided, so the description carries the full burden. 'Create a new group' discloses that the operation creates a resource, but nothing else: no mention of uniqueness constraints, side effects, required permissions, idempotency, or what happens if the group already exists. This is minimal but not misleading.

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

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

The description is short and front-loaded, with no unnecessary words. However, it is under-specified for a tool with an opaque required object parameter and no schema descriptions, so the brevity comes at the cost of usefulness.

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?

Although an output schema exists, the definition still leaves critical gaps: the meaning of 'zoid', the expected shape of 'group_data', and the relationship to other group-related tools. For a tool with a nested object parameter and zero schema description coverage, this is not enough context for an agent to invoke it correctly.

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

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

Schema description coverage is 0% and the description provides no parameter meaning at all. The 'zoid' parameter is opaque, and 'group_data' is an open object with additionalProperties allowed, so the agent has no way to know what fields are expected. The description fails to compensate for the missing schema descriptions.

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

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

The description clearly states the verb 'Create' and the resource 'group', so an agent can identify the basic purpose. However, it does not define what a 'group' represents in this system (e.g., task group, user group), which prevents it from fully distinguishing the concept from other group-adjacent operations.

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

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

There is no guidance about when to use this tool versus alternatives. It does not reference related tools like get_all_groups, get_group_details, or add_task, nor does it explain the intended workflow. The agent must infer usage entirely from the tool name and minimal 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the primary action (creating a label) but does not disclose side effects, required account context, potential duplicate behavior, or any other operational traits such as idempotency 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 description is a single, front-loaded sentence with no filler. Every word contributes to stating the action, making it appropriately concise for a simple CRUD tool.

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

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

Despite having an output schema, the tool lacks annotations and parameter documentation, and the description is too minimal to be complete. It does not explain the role of account_id, how display_name and color are validated, or any behavioral context needed to confidently invoke the tool on the first try.

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

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

Schema description coverage is 0%, so the description must compensate for the absence of parameter documentation. It does not: no parameter is mentioned, and the agent is left to infer meaning solely from names like account_id, display_name, and color. This falls short of what is needed when the schema provides no descriptions.

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

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

The description 'Create a new label' uses a specific verb and resource, making the tool's core function clear. It distinguishes itself from the sibling label tools (update_label, delete_label, get_label_details) by naming the create action, though it adds no detail beyond the tool name.

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

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

There is no guidance about when to use this tool versus alternatives, and no prerequisites are mentioned. The only implication is the obvious one from the verb 'create,' but nothing explicitly addresses context, exclusions, or why to choose this over related label 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, yet it only states the bare action. It doesn't mention the group association requirement, what happens if group_id is invalid, whether the operation is reversible, or any authorization needs. The 'create' verb inherently implies mutation, but no additional behavioral context is disclosed.

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 five-word sentence with zero filler, making it maximally concise and front-loaded. However, the brevity comes at the cost of semantic content—it states only the bare action and omits the usage and parameter context that would make it genuinely useful.

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?

Despite having an output schema, the description is incomplete for a tool with a required nested object parameter (note_data) and a required group_id. It doesn't clarify the relationship between the note and the group, what note_data should contain, or when this tool should be invoked relative to sibling tools like get_all_groups. The free-form note_data with additionalProperties: true amplifies the need for explanatory context that is entirely absent.

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

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

Schema description coverage is 0%, and the description does nothing to compensate. Neither group_id (what kind of group, where to obtain it) nor note_data (expected structure, allowed fields, required properties) is explained anywhere. With additionalProperties: true on note_data, the agent has no way to construct valid arguments, making this a critical 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?

The description uses a specific verb ('create') and a specific resource ('note'), making the primary action unambiguous. The verb inherently differentiates it from siblings like edit_note, get_all_notes, and delete_note. However, it doesn't explicitly mention that the note is created within a group context, which the required group_id parameter reveals.

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

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites such as needing an existing group_id retrieved via get_all_groups or get_group_details, nor when edit_note would be the appropriate choice for modifying an existing note. Usage is only implied by the tool name and one-line 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?

No annotations are provided, so the description must carry the full behavioral disclosure burden. It only states that an IP range is deleted, but does not disclose whether the deletion is permanent, what side effects occur, what permissions are needed, or what the response contains. This is insufficient for a destructive operation.

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

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

The description is short and free of filler, which is structurally clean. However, it is under-specified for a 5-parameter destructive tool, so the brevity is not fully appropriate for the task complexity.

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

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

For a mutation tool with no annotations and no parameter guidance, the one-sentence description is not sufficient for an agent to reliably construct a correct call. The presence of an output schema helps with returned values, but input semantics and side-effect behavior remain largely unexplained.

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 tool description does not explain any of the five parameters. It fails to clarify the relationship between from_ip_range and to_ip_range, the purpose of optional ip_id, the meaning of zoid, or why role_id is required. The description adds essentially no meaning beyond the parameter titles in the schema.

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

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

The description states a specific action ('Delete') and a resource ('allowed IP range') scoped to an organization. This clearly distinguishes it from sibling tools like add_allowed_ips and get_allowed_ips without ambiguity.

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

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

The description gives no guidance on when to choose this tool over alternatives, no prerequisites, and no mention of checking existing allowed IP ranges before deleting. Usage is only implied by the verb 'Delete'; there are no explicit exclusions or alternative recommendations.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Delete,' which implies a destructive mutation, but it does not state whether deletion is permanent, whether deleting a bookmark affects associated data, or whether special permissions are 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 a single short sentence with no wasted words, which is concise. However, it is under-specified to the point of being almost purely a restatement of the tool name, so the brevity is not earned through informative 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?

Although the tool is simple and an output schema exists, the description is too thin for a destructive operation with two opaque parameters and no annotations. It does not explain the role of group_id in deletion, mention any side effects, or provide enough context for an agent to confidently invoke it correctly.

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

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

Schema description coverage is 0% and the description adds no meaning to the two required parameters, group_id and bookmark_id. The agent gets no explanation of what these identifiers represent or how they relate to the bookmark being deleted, so the description completely fails to compensate for the schema's silence.

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: 'Delete a bookmark.' It clearly communicates the action and differentiates from bookmark creation and retrieval siblings like create_bookmark and get_bookmark_details, though it largely repeats the tool name without adding extra scope or nuance.

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

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

No guidance is provided about when to use this tool versus alternatives, nor are prerequisites or exclusions mentioned. The description does not clarify which sibling tools should be preferred for checking bookmarks before deletion, such as get_all_bookmarks or get_bookmark_details.

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

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

There are no annotations, so the description must carry the full behavioral disclosure burden. It only states the deletion action and does not mention whether the operation is irreversible, what side effects it has on email routing or existing messages, or whether special permissions are required. This is insufficient for 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?

The description is very brief and front-loaded, containing no filler. However, it is too minimal to serve as an adequate tool description, bordering on under-specification rather than elegant conciseness.

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

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

For a destructive operation with two required parameters and no annotations, the definition is not complete enough. It does not explain what a catch-all address is, why someone would delete one, what the consequences are, or how the parameters relate to the operation. An agent would struggle to invoke this correctly without external knowledge.

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

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

Schema description coverage is 0%, and the description does not mention either required parameter. The parameter 'zoid' is particularly non-obvious and is left completely unexplained, while 'domain_name' is only vaguely inferable. The description provides no help in understanding how to populate the arguments.

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 'Delete catch-all address.' simply restates the tool name with spaces instead of underscores; it is a tautology that adds no new semantic information. It does indicate the verb and resource, but since the name already conveys exactly this, the description does not meaningfully clarify purpose.

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

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

No usage context is provided. The description does not say when to use this tool versus alternatives such as add_catch_all_address or delete_notification_address, nor does it mention prerequisites or conditions. Any usage guidance is only implied by the name itself.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, yet it only restates the destructive verb 'Delete' that is already evident from the tool name. It does not disclose what happens to email authentication after deletion, whether the operation is reversible, or what the output confirms.

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 phrase is short, but this is under-specification rather than conciseness. There is no meaningful structure to evaluate; the description is a placeholder that omits all operational substance.

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 operation with three required parameters, zero annotation coverage, and 0% schema description coverage, a one-phrase description is grossly inadequate. The agent lacks the context to know what a DKIM detail is, what 'zoid' refers to, what consequences deletion has, and where this tool fits among the DKIM sibling operations.

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 contributes zero parameter information. The three required parameters—especially the opaque 'zoid'—are left completely unexplained, and the description does nothing to compensate for the schema's silence.

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 'Delete DKIM detail' is a word-for-word transliteration of the tool name delete_dkim_detail, which makes it a tautology that restates the name rather than explaining the resource. It does nothing to differentiate this tool from the many DKIM-related siblings (add_dkim_details, set_default_dkim, regenerate_dkim_key, verify_dkim_key) or from the broader delete_* family.

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

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

The description provides no guidance on when this tool should be used versus alternatives. An agent cannot determine under what conditions a DKIM detail should be deleted, or why it would choose this over regenerate_dkim_key or set_default_dkim.

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

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

With no annotations, the description carries the full burden of explaining behavior. It indicates that a domain is removed, but it does not disclose whether removal is irreversible, what happens to associated records, aliases, or email hosting, or whether permissions are required. For a destructive operation, this is a significant transparency gap.

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

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

The description is one short sentence with no redundant words. It communicates the primary purpose immediately and front-loads the core action, so it is highly concise and well-structured for its length.

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

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

For a domain deletion tool with zero annotations and no parameter descriptions, the description is too sparse. It omits critical context such as whether deletion is reversible, whether primary domains can be deleted, and what effects occur on related domain features. An agent cannot fully assess the operation's impact from the available information.

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

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

The schema has no parameter descriptions, and the description only vaguely implies that 'domain' maps to domain_name and 'organization' relates to zoid. It does not explain what zoid is, what format domain_name should take, or how the two parameters relate to the operation.

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

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

The description states a specific action ('Remove') and a resource ('domain from organization'), which makes the core purpose understandable. It is mostly clear but does not specify what kind of domain or what removal entails, so it stops short of being fully self-contained.

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

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

The description gives no guidance on when to use this tool versus alternatives like remove_domain_alias or delete_domain_alias. There is no mention of prerequisites, restrictions, or when not to use it, so an agent must infer usage from context 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It says only 'Delete an email.' and does not mention whether deletion is permanent, whether it moves to trash, how the expunge flag affects server-side deletion, or what side effects may occur. This is especially serious for a destructive mutation tool.

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

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

The description is short, but this is under-specification rather than effective conciseness. It simply restates the tool name and omits essential behavioral and parameter context that would make the description useful.

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 four-parameter tool with no annotations and zero schema description coverage, a single tautological sentence is nowhere near sufficient. The description omits deletion semantics, expunge behavior, prerequisites, and distinctions from other email-related tools.

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

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

Schema description coverage is 0%, and the description does not compensate by explaining any parameters. In particular, the optional 'expunge' parameter is left entirely unexplained, leaving the agent to guess its effect on folder behavior.

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 'Delete an email.' is essentially a direct restatement of the tool name 'delete_email' and adds no additional meaning. It names a verb and resource, but does not distinguish this operation from related email message operations or clarify the deletion 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?

There is no guidance on when to use this tool versus alternatives like move_emails, mark_emails_as_read, or delete_folder. The description provides no context about typical workflows, prerequisites, or cases where another tool would be more appropriate.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. 'Delete a folder' conveys destructiveness but says nothing about whether deletion is permanent, recursive, or fails when the folder contains content, nor does it state any required permissions. This is a significant transparency gap for a destructive operation.

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

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

The description is brief, but brevity is not appropriate sizing here: it omits critical context such as side effects, account scoping, and folder semantics. It reads as an under-specified one-liner rather than a well-structured 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?

Although an output schema exists and the parameter count is small, the description is incomplete for a safe invocation of a destructive tool. It does not explain the role of account_id, the behavior on non-empty folders, reversibility, or any prerequisites, leaving the agent without essential context.

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

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

Schema description coverage is 0%, so the description needed to compensate, but it says nothing about account_id or folder_id. The parameter names are reasonably self-explanatory, but the description adds no meaning beyond the schema's bare 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 states a specific verb ('Delete') and resource ('folder'), making the core operation clear. It is distinguishable from sibling folder tools by the delete verb, though it does not explicitly differentiate itself from similar delete_* tools by scope or semantics.

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 like rename_folder or get_folder_details, nor any mention of prerequisites or context such as the folder existing or belonging to the given account. The description only states the action itself, so an agent must infer usage entirely from the tool 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive mutation, but the description does not say whether deletion is permanent, whether it affects associated resources, whether confirmation is involved, or what permissions are 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 a single short sentence with no filler or redundancy. It is front-loaded and easy to parse, though the brevity comes at the cost of omitting practically all behavioral and contextual detail.

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

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

For a mutating tool with no annotations and no explanatory description, this is too incomplete. Even if an output schema exists, the agent lacks information about deletion consequences, preconditions, or what makes a valid deletion request. The description alone is barely more useful than the tool name.

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 names no parameters. The agent must guess that account_id and label_id identify the target account and label; the description adds no information beyond the parameter names already visible in the schema.

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

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

The description states a specific verb and resource: 'Delete a label.' This clearly separates it from create_label, get_label_details, and update_label. It does not add any scoping (e.g., which label or account context), but the core purpose is unambiguous.

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

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

There is no guidance about when to use this tool versus alternatives like update_label or get_all_labels. No prerequisites, side conditions, or exclusion criteria are mentioned, so an agent must infer usage entirely from the name and schema.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action 'delete' without any information about side effects, irreversibility, permissions, or cascading consequences. This is a significant gap for a destructive operation.

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

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

The description is extremely short, but this is under-specification rather than effective conciseness. While no words are wasted, the single sentence omits necessary context about parameters, behavior, and tool selection.

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

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

With two required parameters, a destructive operation, and no annotations, the description is far too sparse to give an agent enough context to invoke the tool correctly. It doesn't clarify why group_id is needed, what deletion implies for related data, or what response to expect, despite the existence of an output 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 description coverage is 0%, so the description must explain what the parameters mean. It doesn't mention note_id or group_id at all, leaving an agent to infer their roles solely from names. This is insufficient for constructing a correct 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?

The description 'Delete a note.' is a direct restatement of the function name delete_note, providing no new information beyond the name itself. It is clear in intent but tautological, and doesn't differentiate from related note operations like edit_note or get_note_details.

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

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

The description gives no guidance on when to use delete_note instead of other note operations (create, edit, get, list). It doesn't mention any prerequisites, contexts, or exclusions, so an agent is given no help selecting this tool over siblings.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It only states 'delete,' which implies destruction, but it does not disclose irreversibility, side effects on related resources, or any 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 description is extremely concise with no wasted words. The operation is front-loaded and easy to parse, though the brevity comes at the cost of necessary explanatory 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 destructive tool with two opaque required parameters and no annotations, this description is insufficiently complete. It does not explain what the parameters identify, what deletion means in this context, or what happens after deletion. The presence of an output schema does not compensate for missing parameter and behavioral context.

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

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

Schema description coverage is 0%, and the description adds no meaning to the parameters 'zoid' and 'domain_name.' Neither the tool name nor the description explains which parameter represents the notification address or how these identifiers are used, leaving the agent to guess.

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

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

The description uses a clear verb and resource: 'Delete notification address.' It is specific enough to distinguish this from sibling tools like add_notification_address and delete_catch_all_address. However, it does not clarify what a 'notification address' is or how it relates to domains.

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, nor any mention of prerequisites or context. The agent gets no help deciding between delete_notification_address and related delete operations.

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

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

No annotations are provided, so the description carries the full burden of disclosing destructive behavior. It merely says 'Delete' without noting that deletion is likely permanent, whether it cascades to related data, or what permissions are required. This is a meaningful gap for 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?

The description is one concise, front-loaded sentence with no filler or redundancy. It names the verb and resource immediately, which is appropriately sized for a simple two-parameter delete operation.

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

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

Even though the schema is simple and an output schema exists, the description is incomplete for a destructive operation. It omits irreversibility, side effects, the meaning of zgid, and how group versus personal tasks are selected. An agent would need external knowledge to call this tool with full confidence.

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 description does not define zgid or task_id beyond the schema titles. The phrase 'group/personal task' hints at a grouping concept but does not explain what zgid should be for a group task versus a personal task, nor how task_id maps to the target task.

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

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

The description clearly states the action ('Delete') and the resource ('task'), and adds a scope qualifier ('group/personal'). This is enough to tell it apart from sibling tools like add_task or update_task_title. It stops short of 5 because it never clarifies what distinguishes a group task from a personal task at the API level.

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

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

No guidance is given about when to use this tool versus alternatives. There is no mention of prerequisites like verifying the task exists, nor any suggestion to use get_specific_task first or update_task_title for editing. The only usage signal is the verb itself.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, yet it reveals only the intended action. It does not state side effects, reversibility, whether existing domains are affected, or downstream impact on email routing and domain 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?

Five words is lean, but this is under-specification rather than genuine conciseness. The only sentence merely rewords the tool name and earns no informational weight, so brevity buys 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 mutating configuration tool with two undocumented required parameters, no annotations, and a direct enable/disable sibling pair, the description leaves the agent without the basics: what the feature is, what the parameters mean, and what the operation changes. The existence of an output schema does not compensate for the missing operational semantics.

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 never mentions zoid or domain_name. The agent receives no hint about what a 'zoid' is or how domain_name should be formatted. The description completely fails to compensate for the schema's silence on both required parameters.

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

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

The description 'Disable sub-domain stripping' is a near-verbatim restatement of the tool name with spaces inserted; it adds no semantic content beyond the name itself. It conveys a verb+resource pair, so it is not entirely missing, but it never explains what sub-domain stripping is or what the operation actually affects.

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

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

No guidance is provided about when to call this tool versus its direct inverse sibling enable_subdomain_stripping, nor any prerequisites such as domain verification or existing configuration state. The single sentence offers zero context for tool selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states that the tool edits a note. It does not explain whether note_data replaces the entire note, whether partial updates are supported, what permissions are required, what side effects occur, or what the response contains.

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

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

The description is extremely short and front-loaded, but this is under-specification rather than effective conciseness. Every word merely repeats information already present in the tool name, so it does not earn its place by adding useful guidance.

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 nested required parameter (note_data) and no annotations, the description is far too thin to support correct invocation. It fails to explain required parameters, update semantics, return behavior, or any operational context needed to distinguish this from other note-related tools.

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

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

Schema description coverage is 0%, and the description provides no information about group_id, note_id, or note_data. The note_data object has additionalProperties true and is completely undescribed, so an agent has no idea what shape the data must take or how the parameters relate to the edit operation.

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 'Edit a note' is essentially a restatement of the tool name itself, providing no additional detail about what editing entails or which fields can be changed. It does not distinguish this tool from sibling operations beyond the generic verb 'edit', and lacks any specificity about the resource's editable aspects.

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

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

No guidance is given about when to use this tool versus alternatives such as create_note, get_note_details, or delete_note. The intended use is only implied by the verb 'edit', with no explicit context, 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?

With no annotations provided, the description carries the full burden of explaining behavioral consequences. It only says 'Enable' without disclosing side effects, reversibility, prerequisites, or whether this modifies DNS records or domain settings. This is insufficient for a state-changing operation.

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

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

The description is a single concise sentence with no filler or redundancy, and the action is front-loaded. However, it is concise at the expense of necessary context, so it is not a model of well-structured helpfulness.

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?

Despite having only two required parameters, the description omits essential context: what enabling email hosting entails, what zoid means, prerequisites, and how this differs from related domain tools. The presence of an output schema does not compensate for these gaps.

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

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

Schema description coverage is 0%, and the description adds almost no parameter meaning. 'domain' weakly maps to domain_name, but zoid is completely unexplained. An agent cannot determine what zoid refers to or what valid values look like.

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

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

The description states a specific action ('Enable') and a clear target ('email hosting for domain'), so the core purpose is understandable. However, it does not distinguish itself from sibling tools like add_domain or verify_domain, so an agent may not know which domain-related operation to select.

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

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

No guidance is provided about when to use this tool versus alternatives such as add_domain, verify_domain, or set_primary_domain. There are no prerequisites, exclusions, or alternative tool mentions, leaving the agent to guess the appropriate context.

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

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

With no annotations, the description carries the full burden of disclosing behavior, but it only states a mutation ('enable') without detailing side effects, reversibility, prerequisites, or impact on domain handling. This is a significant transparency gap for a configuration-changing tool.

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

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

The description is extremely short, but this is under-specification rather than effective conciseness. The single sentence merely repeats the tool name and does not use its space to convey useful operational 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 two-required-parameter mutation tool with no annotations and 0% parameter coverage, the description is far too incomplete. Even with an output schema present, the agent lacks the domain knowledge needed to call this tool correctly: what sub-domain stripping means, its effect, and any prerequisites.

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 provides no explanation of zoid or domain_name. The agent must guess that zoid identifies an organization/domain context and domain_name is the domain affected; the description adds no meaning beyond the raw parameter titles.

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 'Enable sub-domain stripping.' restates the tool name verbatim, making it tautological. It identifies an action and resource but adds no definition of what 'sub-domain stripping' is or how this tool differs from related domain operations.

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

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

No guidance is provided on when to enable sub-domain stripping, what conditions must be met, or how this tool compares to siblings such as disable_subdomain_stripping or verify_domain. The agent is left to infer usage entirely from the tool 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?

No annotations are present, so the description must carry the behavioral disclosure burden. It communicates a read-only operation through the verb 'get' but discloses nothing about authorization requirements, data sensitivity, error behavior, or other operational traits. This is minimal but not completely absent.

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

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

The description is one short sentence, but it is under-specified rather than efficiently concise. It adds little beyond the tool name and lacks the detail needed to make the description genuinely useful.

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

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

For a tool with one required parameter and no parameter documentation, the description is far too sparse. It does not explain what account details are returned, how to acquire account_id, or what distinguishes this call from similar sibling tools. Even with an output schema available, the invocation context remains incomplete.

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 account_id, its format, meaning, or how to obtain a valid value. The parameter is completely undocumented in both the description and the schema itself, so an agent has no semantic grounding for this required parameter.

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

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

The description 'Get specific account details' provides a plain read verb and resource, and the word 'specific' suggests a single-account lookup as opposed to listing all accounts. However, it never defines what constitutes 'account details' or how it relates to similarly named tools like get_organization_details or get_user_details, so it lacks real distinguishing value.

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

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

The description gives no when-to-use guidance, no exclusions, and no comparison to alternatives. With many sibling detail-getting tools, an agent cannot determine when to choose this one versus get_organization_details or get_user_details. The only implied signal is 'specific,' but that is not enough.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clarifies the scope to the authenticated user but does not mention authentication requirements, side effects, pagination, rate limits, or what the response contains. For a tool with no annotations, this leaves significant behavioral context unspecified.

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

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

The description is a single, tightly worded sentence that front-loads the action and resource. It contains no filler or redundant 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?

Given the tool has zero parameters and an output schema is present, the description is sufficient for an agent to understand what this tool does. The only gaps concern behavior such as authentication details, which are more appropriately captured by annotations and are already penalized in the behavioral transparency dimension.

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

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

The tool has zero parameters and no required parameters, so there is no parameter semantics to document. The description adds no parameter information, but none is needed; the empty schema already provides complete coverage.

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

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

The description states a specific verb ('get'), a clear resource ('all accounts'), and a scope ('authenticated user'). It also distinguishes itself from siblings like get_account_details by emphasizing the plural 'all accounts' rather than details of a single account.

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

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

The description implicitly signals when to use this tool: when all accounts of the authenticated user are needed. However, it does not explicitly state when not to use it or mention alternatives such as get_account_details for a single account.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it discloses almost nothing. It does not mention return shape, pagination, ordering, error behavior for invalid group_id, or empty-result semantics — leaving the agent to infer all behavior from the tool name.

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 wasted words, and the core idea is front-loaded. It is appropriately brief for a one-parameter list tool, though the phrasing 'in group' is grammatically awkward and the brevity borders on 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?

An output schema exists, so return values are documented elsewhere. However, the description leaves ambiguity about the meaning of 'group' (organizational group vs. bookmark collection, given siblings like get_all_groups) and offers no guidance on pagination or empty results, making it adequate but incomplete.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented group_id parameter. It adds only the inference that group_id selects which group's bookmarks are returned; it does not explain what a 'group' is, where to obtain a valid group_id, or any format 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 ('Get'), a resource ('all bookmarks'), and a scope ('in group'), which clearly conveys this is a collection-listing operation. It is implicitly distinguished from siblings like get_bookmark_details (single item) and delete_bookmark, though it does not name them 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 intended usage is implied by the name and description — call this when you need all bookmarks associated with a group_id. However, there is no explicit guidance on when to prefer it over get_bookmark_details, nor any exclusion criteria or context about alternatives.

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

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

No annotations are provided, so the description carries the full behavioral burden. "Fetch" weakly implies a read-only operation, but the description does not disclose pagination, ordering, authorization requirements, or any other runtime behavior. It adds minimal value beyond the action itself.

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

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

The definition is a single, front-loaded sentence with no filler or redundant phrasing. Every word contributes to the core purpose.

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

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

The tool is simple and has an output schema, so return values are covered elsewhere. However, the missing zoid semantics and lack of any usage or behavioral guidance leave the description incomplete for an agent that must invoke it correctly.

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

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

Schema description coverage is 0%, and the description does not explain what zoid represents or how to obtain it. With only one required parameter, the description still fails to compensate for the schema's lack of 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 uses a clear verb and resource: "Fetch all domains in organization." It communicates that this is a list-all operation, which differentiates it from siblings like get_domain_details, though it does not explicitly name any alternative.

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

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

The phrasing "all domains" implies this is for listing rather than fetching a single domain, but there is no explicit guidance about when to choose this tool versus get_domain_details or other domain-related operations. Usage context 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates a read operation with account-level scope, but it is silent on pagination, ordering, hierarchy behavior, access requirements, or whether the result includes system-generated folders.

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 clear sentence with no redundant wording. It front-loads the action, resource, and scope, and every word earns its place.

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

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

For a tool with a single required parameter and an output schema, the description is minimal but functional. However, the lack of usage guidance, parameter clarification, and behavioral context like pagination makes it incomplete for an agent choosing between many sibling tools, especially with no annotations to fill the gap.

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

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

Schema description coverage is 0%, so the description needs to explain the account_id parameter. It only says 'in account', which weakly implies account_id is the account scope, but it does not clarify what values are valid, where to find the id, or whether the id refers to a user account or organization account.

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 ('Get'), resource ('folders'), and scope ('in account'). This clearly distinguishes the tool from sibling tools like create_folder, rename_folder, and get_all_labels, although 'account' is slightly ambiguous without defining what an account is.

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 like get_folder_details or get_all_labels. The description implies a list-all use case, but it does not explicitly state exclusions, prerequisites, or scenarios where another folder tool would be more appropriate.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. 'Get' weakly signals a read operation, but the description does not mention authentication requirements, read-only guarantees, pagination, or scope limits. This is thin coverage for a list-all tool.

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

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

The description is a single sentence with no filler, and the action and resource are front-loaded. It is appropriately concise for a simple list operation, even though it omits some supporting context.

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

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

The output schema may cover the return shape, but the required zoid parameter is undocumented, there is no usage context vs siblings, and no annotations compensate. For a tool with one required parameter and a broad 'all groups' scope, the description is too minimal for an agent to call it with full confidence.

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 only parameter, zoid, has 0% schema description coverage, and the description never explains what zoid is or what format it should take. The phrase 'in organization' hints that zoid may be an organization identifier, but this is not explicit enough for reliable invocation.

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 ('Get'), a concrete resource ('all groups'), and a scope ('in organization'). This clearly distinguishes it from sibling list tools like get_all_users and get_all_domains, and from get_group_details for individual groups.

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 use when the caller needs all groups in the organization, but it provides no explicit when-to-use guidance, exclusions, or alternatives. An agent could infer the basic scenario, but nothing helps it decide between this and related group tools.

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

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

With no annotations, the description carries the burden of behavioral disclosure. The verb 'Get' implies a read-only, non-destructive operation, which is helpful, but it does not disclose anything about pagination, result limits, required permissions, or the fact that an account_id is mandatory. For a simple retrieval tool this is acceptable but not 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 a single clear sentence with no wasted words or redundant clauses. It is front-loaded and easily parsed, though the brevity contributes to missing semantic detail.

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

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

The tool is simple: one required parameter and an output schema that likely documents return values. The description is minimally sufficient to recognize this as a label-listing operation, but it lacks account-scoping context and any usage or alternative routing, so it is not fully self-contained.

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 itself says nothing about the account_id parameter. It does not explain what the account_id represents, why it is required, or how it relates to the returned labels. The description adds no meaning beyond the raw schema title and type.

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 'Get all label details' clearly identifies the verb (get) and resource (labels), and the plural 'all' differentiates it from sibling get_label_details. However, it is nearly a restatement of the tool name and does not clarify what 'details' includes or that labels are scoped to an account.

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 like get_label_details or the label mutation tools. The plural 'all' implies listing, but the description never states a use case, exclusions, or conditions that would help an agent choose among siblings.

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

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

No annotations are provided, so the description must carry the behavioral burden. 'Get all notes' clearly suggests a read-only listing operation, but the description does not disclose pagination, ordering, error behavior, or what happens when group_id does not exist. It is minimally transparent but lacks richer behavioral context.

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. The key action and scope are front-loaded, making it easy to scan.

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 with one required parameter and an output schema, so the combination of description and schema is nearly callable. However, usage guidance and sibling differentiation are missing, and the description does not clarify what 'group' means or what the returned note list contains.

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 only parameter group_id has no schema-level description. The description's 'in group' phrase adds some context by implying group_id selects the group whose notes should be returned, but it does not explain expected format, validation, or edge cases.

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 'Get all notes in group' clearly states a specific verb, resource, and scope. It distinguishes itself from singular note tools like get_note_details by indicating plural 'all notes', though it does not explicitly reference any sibling.

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

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

There is no guidance on when to use this tool versus alternatives such as get_note_details, get_specific_task, or get_all_bookmarks. The description provides no exclusions or selection criteria beyond the obvious 'get all notes' meaning.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a non-mutating read by using 'Get list,' but it does not disclose authorization requirements, whether the result is scoped by the zoid parameter, or any other behavioral traits an agent would need for safe invocation.

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

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

The description is a single, tightly written sentence with no filler or redundancy. It is concise and front-loaded, though it sacrifices helpful detail for brevity.

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

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

The presence of an output schema covers return values, but the description is still incomplete for a tool with no annotations and an undocumented required parameter. An agent cannot confidently determine what zoid is or what conditions justify calling this 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%, and the description adds no meaning to the required 'zoid' parameter. The phrase 'for organization' hints at organizational scope but never explicitly connects it to zoid, leaving the agent to guess what value to supply.

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 ('Get'), a clear resource ('allowed IP ranges'), and the organizational scope. It is immediately distinguishable from sibling tools like add_allowed_ips and delete_allowed_ips by its read-only intent and resource focus.

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

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

No guidance is given about when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The description implies a read operation, but it does not explicitly say 'use this instead of add/delete allowed IPs' or describe the calling context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get', implying a read operation, but it does not mention status filtering, scope semantics, edge cases, or response behavior. Without annotations, this is a notable gap.

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

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

The description is a single sentence with no filler and the core action is front-loaded. It is concise, though the phrasing 'group/personal tasks' is slightly awkward and could be clearer.

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 read-only tool, an output schema exists to cover return values, so the major missing pieces are parameter semantics and precise scope. The optional status parameter is entirely undocumented, and zgid semantics are only vaguely implied. The description is too thin to fully guide 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%, and the description does not explain 'zgid' or 'status'. The phrase 'group/personal tasks' hints that zgid identifies a group or personal context, but it does not clarify valid values, defaults, or how status affects the result.

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 ('Get'), a resource ('all tasks'), and a scope ('in a group/personal tasks'), which clearly distinguishes it from siblings like get_specific_task and get_all_groups. However, the phrase 'group/personal tasks' is somewhat ambiguous about whether personal tasks are a separate category or a special group.

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

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

Usage context is implied by the name and description: this tool lists all tasks, while get_specific_task retrieves one task. There is no explicit statement about when to prefer this tool over others, nor any exclusion guidance, but the intended use is reasonably inferable.

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 are absent, so the description carries the full behavioral burden, and it discloses nothing beyond the generic read verb 'Get'. It does not mention pagination for potentially large result sets, whether 'all users' includes suspended or hidden users, how results are ordered, or any permission requirements tied to zoid.

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?

Five words with zero filler: the verb leads, the resource and scope follow, and the sentence ends cleanly. Nothing could be removed without losing meaning, and nothing extraneous is present.

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 single-parameter list operation with an output schema present, the description is minimally adequate. The main gaps are operational: no pagination handling, no clarification of what 'details' means relative to get_user_details, and no indication of where zoid originates.

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

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

Schema description coverage is 0%, so the description must compensate, but it only weakly implies that zoid identifies an organization through the phrase 'organization users'. It never explicitly defines zoid, explains where to obtain it, or describes how it scopes the returned users.

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 ('Get') and resource ('all organization users'), clearly stating this is a bulk retrieval of users in an organization. The 'all' qualifier distinguishes it from get_user_details (single user). However, 'details' is vague about which user attributes are returned, and no distinction is made from the sibling get_all_accounts, which could overlap conceptually with 'users'.

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

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

No guidance is given about when to use this tool versus its many siblings, such as get_user_details for a single user, get_all_accounts for accounts, or get_organization_details for org-level information. The only hint—the word 'all' implying bulk retrieval—comes from the tool name itself, so the description adds no independent usage direction.

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

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

No annotations exist, so the description carries full responsibility for behavioral disclosure. It only says 'Get audit records' and does not mention pagination, time filtering, search semantics, or what the response contains, leaving the tool's behavior largely undisclosed.

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

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

The description is a single short sentence and is front-loaded, but it is concise at the expense of essential detail. It is not bloated, yet it does not carry enough information to be considered well-structured for an agent.

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

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

For a tool with 7 parameters, zero annotation coverage, and no schema parameter descriptions, one sentence is insufficient. The presence of an output schema reduces the need to describe return values, but the filtering and pagination parameters remain completely undocumented.

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 only hints that 'organization' maps to the required zoid parameter. It does not explain limit, start_time, end_time, search_key, last_entity_id, or last_index_time, so the description adds minimal value beyond the schema.

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

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

The description states a specific verb and resource ('Get audit records') and an organizational scope, so an agent can tell it is a read operation for audit data. However, it does not explicitly distinguish it from overlapping sibling tools like get_login_history.

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

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

No guidance is provided on when to use this tool versus alternatives. Sibling tools include get_login_history and other read-only queries, so an agent has no basis for choosing get_audit_records over them.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get bookmark details' and does not mention that it is a read-only lookup, what scope group_id imposes, what errors can occur, or that bookmark IDs are scoped to a group.

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 text is short but not meaningfully concise; it simply restates the tool name with no additional context. It is under-specified rather than efficiently structured, so it earns little credit for brevity.

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

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

Even though an output schema exists and the parameter list is short, the description is not complete for confident tool invocation. It lacks any explanation of how the two required IDs relate, and it does not clarify when this tool is preferable to get_all_bookmarks, leaving important context to guesswork.

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

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

Schema description coverage is 0% and the description adds no parameter meaning whatsoever. It does not explain that group_id identifies the parent group or that bookmark_id selects the bookmark within that group, so an agent must rely entirely on the bare property names.

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

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

The description clearly states a read operation (get) on a specific resource (bookmark details), so the agent can infer this returns information about one bookmark rather than creating or deleting one. However, it is essentially the tool name restated and does not distinguish itself from get_all_bookmarks or specify that it is scoped by group_id and bookmark_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 when-to-use guidance, no exclusion criteria, and no mention of alternatives such as get_all_bookmarks or get_specific_task. The intended use is only implied by the tool name and the required IDs.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. The word 'Get' suggests a non-mutating read operation, but the description does not mention side effects, required permissions, rate limits, or any other behavioral traits beyond the action implied by the name.

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

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

The description is a single sentence with no wasted words and is front-loaded. However, it is so terse that it sacrifices useful detail, making it minimally viable rather than genuinely well-structured.

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?

An output schema exists, so return format is not the main gap. But for a tool with two unknown parameters and no usage guidance, the description is incomplete: an agent still does not know what values to pass for zoid or domain_name or when to choose this 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%, and the description does not explain either parameter. 'zoid' and 'domain_name' are left entirely to the agent's inference, with no format, example, or semantics provided.

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

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

The description states a clear action ('Get') and a resource ('specific domain details'), which distinguishes it from batch operations like get_all_domains. However, it does not explicitly differentiate itself from other domain-related siblings such as verify_domain or set_primary_domain.

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

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

No guidance is given for when to use this tool versus alternatives like get_all_domains or verify_domain. The description provides no context about prerequisites, when this is the right choice, or when another tool should be used.

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

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

No annotations are present, so the description bears full responsibility for disclosing behavior. It only says 'Get email content' without mentioning whether the operation is read-only, whether attachments are included, what the 'include_block_content' flag affects, or how failures are handled. This is insufficient for a tool with this level of complexity.

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 highly concise and front-loaded, consisting of one direct sentence with no filler. Yet it is under-specified: it omits all contextual and behavioral detail that an agent would need, making the brevity a limitation rather than an asset.

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 an output schema present, return format is partly covered, but the surrounding context is missing: no indication of how this relates to sibling email tools, what the identifiers mean, whether the operation has side effects, or how the optional include_block_content changes the result. For a tool with 4 parameters and no annotations, this description is too sparse to be complete.

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

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

Schema description coverage is 0%, and the description adds no explanation of the parameters. The parameter names themselves (account_id, folder_id, message_id, include_block_content) are reasonably self-explanatory, and the schema provides type, required, and default information, but the description does nothing to compensate for the lack of formal schema descriptions.

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

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

The description states a specific verb ('get') and resource ('email content'), so the basic action is clear. However, it does not distinguish this tool from adjacent siblings like list_emails or search_emails, which also deal with email retrieval. It is minimally clear but not differentiating.

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

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

No guidance is provided about when to use this tool versus list_emails, search_emails, or get_account_details. The description gives no context about required identifiers, preconditions, or situations where this tool is preferred.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'Get' conveys a read-only, non-mutating operation, which is a useful behavioral signal. It does not mention authorization, scoping, or error behavior, but for a simple getter with an output schema this is a acceptable minimal disclosure.

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

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

The description is a single, front-loaded sentence with no filler words. Every word earns its place, and it is appropriately sized for a simple getter tool.

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

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

Given that there are only two required parameters with fairly clear names and an output schema exists, the description is minimally viable. It lacks usage guidance and parameter elaboration, but for a straightforward read-only tool, the combination of name, description, schema, and output schema may be enough for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description needed to compensate by explaining account_id and folder_id, but it does not. It only refers to 'specific folder details,' giving no additional meaning or relationship between the two parameters. The parameter names are somewhat self-explanatory, but no real semantic guidance is added.

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

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

The description clearly states the action ('Get') and the resource ('specific folder details'), which indicates a read operation for an individual folder. The word 'specific' helps separate this from get_all_folders, though it does not explicitly name any sibling or clarify what 'details' includes.

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 'specific folder details' implies this should be used when the agent needs information about one folder rather than the full list from get_all_folders. However, it does not explicitly state when to use this tool over alternatives or give 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?

No annotations are provided, so the description carries the full burden. 'Get' implies a read-only operation, but the description does not disclose permission requirements, error behavior for invalid IDs, or whether any scoping is applied.

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

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

The description is a single, front-loaded sentence with no filler. It is concise, though it would benefit from a little more explanatory 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?

Although the tool has a simple input and an output schema, the description lacks enough context to distinguish it clearly from get_all_groups and does not clarify the two required parameters. An agent would have to guess at zoid/zgid semantics.

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

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

Schema description coverage is 0%, and the description does not explain that zgid identifies the group or zoid identifies the parent organization. The parameter names are suggestive but the description adds no semantic detail.

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

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

The description uses a clear verb and resource ('Get ... group details') and the word 'specific' separates this from the sibling get_all_groups. It does not explicitly name that alternative, so it falls short of full differentiation.

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

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

There is no guidance about when to choose this tool over get_all_groups, create_group, or related group tools. The context is only implied by the word 'specific'.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It only restates the obvious read nature of a 'Get' call and adds nothing about what 'details' means, whether failures return errors or empty results, or any relationship between the account and label.

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 filler; the key qualifier 'specific' is front-loaded. It is efficient, though the efficiency is partly a consequence of under-specification, which is penalized in other dimensions.

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 presence of an output schema reduces the need to explain return values, and the operation is simple, but the overall context is thin: no usage conditions, no parameter semantics, and no differentiation from related label tools. An agent would struggle to know exactly when and how to invoke this correctly.

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

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

Schema description coverage is 0%, and the description does not compensate by explaining either parameter. The names label_id and account_id are self-descriptive enough to guess their roles, but the description never clarifies that the label must belong to the specified account or what format the IDs take.

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 clear verb ('Get') and resource ('label details'), and the qualifier 'specific' correctly signals single-item retrieval as opposed to get_all_labels. The pattern matches sibling detail-fetch tools like get_account_details and get_domain_details, making its role in the API surface recognizable.

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

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

No guidance on when to use this tool versus get_all_labels, create_label, update_label, or delete_label. The description gives no context about prerequisites, such as whether the label must already exist or belong to the account identified by account_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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it discloses almost nothing: no mention of pagination behavior (despite scroll_id and batch_size parameters), no statement about the access_type filter, no note on time-range semantics, and no indication of what the returned records contain. For a data-retrieval tool with zero annotation coverage, this is a significant gap.

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

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

The text is terse with zero wasted words, which is good for conciseness, but at seven words it is under-specified rather than appropriately sized given the tool's 7 parameters and 0% schema coverage. There is no front-loading of constraints, parameter hints, or usage context, so it reads as a stub rather than a deliberately concise 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?

Given the tool's complexity (7 parameters, 4 required, no annotations, 0% parameter descriptions), a one-sentence description is grossly inadequate. An agent cannot correctly construct a call without knowing what zoid, mode, access_type, and the time range represent. While an output schema exists, that does not offset the missing input-side semantics and behavioral context.

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