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 reveals that a mailbox will be created; it does not mention permissions required, potential side effects, idempotency, or whether creating a shared/room mailbox has different requirements. For a mutation tool, this is a meaningful 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 compact, front-loaded line with no filler. It efficiently conveys the action, resource, and type categories, though the shorthand 'user/shared/room' is slightly cryptic. Still, it is appropriately sized for what it attempts to communicate.

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 six-parameter creation tool with no output schema and no annotations, this one-liner is not sufficient for an agent to call it correctly. It lacks parameter semantics, behavioral expectations, prerequisites, and return-value information, leaving too much to inference.

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

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

Schema description coverage is only 17%, with solely 'shared' having a description, so the description needed to compensate by explaining parameters like name, alias, database, userPrincipalName, and room. The phrase 'user/shared/room' hints at the room and shared booleans, but it does not clarify the required 'name' or the roles of the other 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 states a specific verb ('Create'), a resource ('mailbox'), and the supported mailbox types ('user/shared/room'), which clearly distinguishes the create operation from sibling list, get, set, and remove tools. It also references the underlying New-Mailbox cmdlet. It is not a full sentence but conveys the essential purpose without tautology.

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 verb 'Create' implies the tool is for provisioning new mailboxes, and the 'user/shared/room' hint indicates the common variants. However, there is no explicit guidance about when to choose this over exchange_set_mailbox for modifications or how to handle existing mailboxes. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read operation by saying 'Get,' but it does not explain return format, error behavior, authentication requirements, or any side effects. This is minimal behavioral context for an agent invoking the 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 short sentence with no redundant words. The main purpose is front-loaded, and the parenthetical adds useful specificity. It is concise and well-structured for the amount of information it conveys.

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

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

With no annotations, no output schema, and an undocumented parameter, the description is too sparse to fully prepare an agent to invoke the tool correctly. It lacks key operational details such as identity format, response behavior, and when this tool should be selected over similar getter 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?

The schema has one parameter, 'identity', with no description, and schema description coverage is 0%. The description does not explain what format identity should take (e.g., email address, alias, GUID) or how it relates to the mailbox. The parameter is somewhat inferable from context, but the description does not compensate for the missing schema 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 names a specific verb ('Get'), a specific resource ('Client Access mailbox settings'), and the relevant protocols ('ActiveSync, OWA, MAPI'), which distinguishes it from general mailbox getters like exchange_get_mailbox. It does not explicitly differentiate from a sibling, but the parenthetical clarifies the tool's focus well.

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

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

There is no guidance about when to use this tool versus alternatives such as exchange_get_mailbox or exchange_get_virtual_directory. The description implies a use case through its purpose, but it never states conditions, prerequisites, or exclusions, leaving the agent to guess when this tool is the right choice.

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' and does not explain whether one or many DAGs are returned, how the optional identity affects behavior, or what permissions or errors may be relevant.

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 sentence with no wasted words and expands the acronym DAG. However, the brevity borders on under-specification, so it does not earn a top score.

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 optional parameter and no output schema, the description is underspecified. It does not clarify the identity parameter's semantics or the tool's relationship to sibling database/DAG tools, leaving key usage details to inference.

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

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

The schema description coverage is 0%, and the description does not mention the sole 'identity' parameter. The agent gets no help understanding whether omitting identity lists all DAGs or how the identity value should be formatted.

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: retrieving Database Availability Groups. It is clear enough to distinguish it from mailbox, server, and queue tools, though it does not explicitly contrast it with closely related siblings such as exchange_get_database_copy_status or exchange_get_mailbox_database.

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 the many related get/list tools. There is no mention of prerequisites, whether identity is required, or what scenarios call for this tool instead of a sibling.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, what output to expect, how the wildcard identity behaves, or any permission requirements. The single sentence simply restates the tool's basic purpose.

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 brief and front-loaded, with no wasted words. However, it verges on under-specification rather than achieving genuinely effective conciseness, so it earns a middle score.

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 status tool the description is not jempty, but it omits essential context such as the role of 'server', the meaning of the parenthetical 'DAG health', and what the returned status data looks like. With no output schema or annotations, these gaps hurt usability.

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

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

The schema documents 'identity' as 'DB name or * for all', but the description adds no meaning for either parameter. In particular, the 'server' parameter is left entirely undocumented, and the description does not compensate for this gap.

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

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

The description clearly states a specific verb and resource: 'Get database copy status', with the parenthetical 'DAG health' adding useful context. However, it does not explicitly differentiate this from sibling tools like exchange_get_dag or exchange_get_mailbox_database, so it stops 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 on when to use this tool versus alternatives such as exchange_get_dag or exchange_get_server_health. The phrase 'DAG health' hints at one use case, but no explicit context, prerequisites, or exclusions are provided.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read operation, but the description does not disclose return shape, pagination, permission requirements, or what happens if the identity does not resolve to a distribution 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 description is extremely concise, with no wasted words, but it is underspecified rather than efficiently informative. Front-loading is good, yet the single fragment fails to provide enough 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?

For a one-parameter tool with no annotations and no output schema, the description should at least clarify the meaning of 'identity' and what the caller can expect from the result. It does neither, leaving the agent to make assumptions about how to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not. The single required parameter 'identity' remains undocumented; the tool name and description strongly imply it is the distribution group identity, but this is never stated explicitly, and the description does not clarify whether it expects a group ID, alias, or display name.

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 distribution group members' names a specific verb ('get') and resource ('distribution group members'), making the core purpose identifiable. It does not explicitly differentiate from sibling tools like exchange_list_distribution_groups, which are about listing groups rather than members, but the intent is largely clear.

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

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

The description implies usage: an agent should call this tool when it needs members of a distribution group. However, it offers no explicit guidance on when to prefer this over related tools such as exchange_list_distribution_groups or exchange_list_dynamic_distribution_groups, and it names no alternatives 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, the description carries full responsibility for behavioral disclosure. It only says 'Get' and 'expiry monitoring,' so it implies a read operation but does not disclose whether it returns all certificates, how the optional server parameter affects results, or what response shape/status to expect.

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 phrase with no fluff, and the core verb/resource are front-loaded. It earns a high score for efficiency, but it is so brief that it leaves behavioral and parameter details unstated.

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

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

For a one-parameter tool with no output schema and no annotations, the description is minimal. It tells the agent what domain the tool covers but not how to use the server parameter, what data comes back, or what makes this distinct from other monitoring tools like exchange_get_server_health.

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 mention the 'server' parameter at all. The property name alone hints at a target server, but without required/optional semantics or effect on the returned certificates, the description does not compensate for the missing schema documentation.

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

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

The description uses a specific verb ('Get') and resource ('Exchange certificates') and adds a clear use-case parenthetical ('expiry monitoring'). It distinguishes the tool from its many mailbox/connector/queue siblings by resource, though it doesn't state whether this returns all certificates or a filtered set.

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, and there are dozens of sibling tools. The agent is left to infer that certificate-related monitoring is the intended niche; there are no exclusions or explicit conditions.

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

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

With no annotations, the description carries the behavioral burden. 'Get health report' implies a read-only query, and 'rollup per server/DAG' indicates an aggregation behavior. However, it does not disclose output shape, whether all health sets are included by default, or how the rollup is structured, leaving notable gaps for a tool with no annotation safety hints.

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 filler. The parenthetical cmdlet name adds precision, and the dash-delimited scope note is efficient. It loses one point because 'Get health report' largely repeats the tool name, though the overall structure remains focused.

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 two undocumented optional parameters, no annotations, no output schema, and a cluster of similar health-related sibling tools, this description is too minimal. It leaves the agent without enough information to know what the report contains, how parameters affect the query, or how this differs from superficially similar health 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 explain either 'server' or 'healthSet'. 'Per server/DAG' vaguely hints that 'server' can identify a server or DAG, but it provides no detail on valid values, defaults, or what 'healthSet' means. The description does not compensate for the empty 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 and resource ('Get health report') and clarifies the scope as a 'rollup per server/DAG', which helps distinguish it from sibling health-related tools. It could be slightly stronger by explicitly contrasting with exchange_get_server_health or exchange_test_service_health, but the core purpose is clear.

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 'rollup per server/DAG' implies this is for aggregate health reporting at the server or DAG level, which gives some usage context. However, it does not explicitly state when to prefer this tool over related health-check siblings, nor does it mention any exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Get', which implies a read operation. It does not mention side effects, permissions, identity format limitations, errors, or return behavior, adding little beyond 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?

The description is five words with no filler, front-loading the verb and resource. Every word contributes meaning, and the structure is clean and scannable.

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

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

For a tool with one parameter, no annotations, and no output schema, an agent needs more context to invoke it correctly. The description is too minimal: it lacks identity value guidance, sibling differentiation, and any indication of the returned mailbox details.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented 'identity' parameter. Saying 'by identity' only restates the parameter name and confirms it is the lookup key; it does not explain acceptable formats such as UPN, SMTP address, alias, or GUID.

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 ('Get') and a specific resource ('mailbox details') with a selection mechanism ('by identity'). It is distinct from listing siblings like exchange_list_mailboxes, though 'details' is somewhat generic and could be more specific about what is returned.

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 instead of siblings such as exchange_get_mailbox_statistics or exchange_get_mailbox_permissions. The phrase 'by identity' mildly implies a single-object lookup, but no alternatives, exclusions, or decision criteria are given.

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

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

No annotations are present, so the description carries the full burden for behavioral disclosure. It only states 'Get mailbox database details' and adds no information about read-only behavior, required permissions, error conditions, or what 'details' entails. It provides little beyond what the tool name already implies.

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 short, but this is under-specification rather than effective conciseness. It is a single generic clause that adds almost no information beyond the tool's name and fails to justify its brevity with useful 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 tool with one required parameter, no output schema, and no annotations, the description is too thin to be complete. It does not explain what the returned details will include, how identity should be specified, or how this operation behaves, leaving an agent with insufficient information to call it confidently.

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

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

Schema description coverage is 0%, and the only parameter, 'identity', has no description in the schema or the tool description. The description fails to explain the expected format, purpose, or constraints of the identity parameter, providing no value beyond the schema's type and required fields.

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: 'Get mailbox database details'. It identifies that the tool retrieves information about a specific mailbox database, which distinguishes it from enumeration tools like exchange_list_mailbox_databases, though it doesn't explicitly compare against siblings.

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

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

The description gives no guidance on when to use this tool versus alternatives such as exchange_list_mailbox_databases or exchange_get_database_copy_status. Usage is only vaguely implied by the verb 'Get' and the required 'identity' parameter, but no explicit context or exclusions are provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get,' which implies a read operation, but it does not mention return shape, whether results are filtered, permission requirements, or any side effects.

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

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

The description is a single compact sentence and front-loads the core action and object. It has no filler, though it omits useful details that could be added without bloating it.

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

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

With no annotations and no output schema, the description should explain more about what the caller gets back and how to provide identity, but it does neither. The tool is simple, so the gap is moderate, but the definition is still under-specified for an agent to invoke with 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 description coverage is 0%, and the only parameter, identity, is not explained in the description. The property name is somewhat self-evident, but the description does not clarify acceptable formats or whether it refers to a mailbox alias, UPN, GUID, or other identifier.

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-resource pair, 'Get mailbox permissions,' and adds concrete examples (FullAccess, SendAs), so an agent can tell what the tool retrieves. It does not explicitly differentiate from siblings like exchange_get_mailbox or exchange_get_cas_mailbox, but 'permissions' is a distinct target.

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 wording implies the tool is used when mailbox permission details are needed, but it gives no explicit guidance about when to prefer it over other mailbox-related getters. No alternatives or exclusions are mentioned.

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

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

With no annotations, the description carries the full burden. It implies a read-only operation via 'Get' and enumerates the returned statistics, but it does not disclose permissions, failure modes, or how 'DB' or 'last logon' should be interpreted.

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

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

A single, front-loaded sentence conveys the operation, result fields, and intended use with no filler.

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

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

The tool is simple (one parameter, no output schema), and the description covers purpose and return fields. However, the undocumented 'identity' parameter is a significant gap for an agent trying to invoke it correctly, and no output schema exists to fill that void.

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 provides no description for 'identity' (0% coverage), and the description does not compensate by explaining accepted identity formats such as alias, UPN, or GUID. The agent is left to guess what value to pass.

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-resource pair ('Get mailbox statistics') and enumerates the exact data returned (size, item count, last logon, DB), making the tool's purpose immediately clear. This is distinct from sibling tools like exchange_get_mailbox or exchange_list_mailboxes, which focus on mailbox objects rather than statistics.

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 'troubleshooting storage/quota' provides a clear context in which this tool is the right choice. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. 'Search' implies a read operation, and 'troubleshooting delivery' suggests intent, but the description does not disclose any behavioral traits such as result format, time window constraints, retention limits, or how filtering behaves. This is a significant gap for a diagnostic/search 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 and avoids waste, but it is under-specified rather than genuinely concise. A single phrase with a parenthetical does not provide enough structural information for a tool with seven parameters and no annotations.

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

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

With no output schema, no annotations, and a very low parameter coverage, the description needed to explain the tool's inputs, output, and search behavior. It only states the resource and purpose. This is not enough for an agent to invoke the tool correctly, especially because there are no required parameters and the semantics of the optional ones are 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 only 14%, with a single 'ISO datetime' note on 'start'. The description itself provides no guidance on how to use start, end, sender, recipients, messageSubject, server, or resultSize, and does not clarify that all parameters are optional. The description fails to compensate for the sparse 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: 'Search message tracking logs.' The parenthetical 'troubleshooting delivery' adds a clear purpose, and the resource name distinguishes it from siblings like exchange_search_admin_audit_log or exchange_test_mailflow. It doesn't explicitly differentiate from alternatives, but the object is specific enough that an agent can tell what it operates on.

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 a clear usage context: troubleshooting delivery. This implies when an agent should consider this tool. However, it provides no exclusions or alternatives, so it stops short of fully guiding tool selection among the many sibling tools.

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

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

No annotations are provided, so the description carries the behavioral burden. The word 'Get' and the parenthetical 'probes/monitors/responders' make the read intent and resource type clear. However, it does not disclose whether the result is a list, how healthSet affects the output, or any pagination/filtering behavior.

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

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

The description is a single concise sentence with no wasted words. The action and key qualifier are front-loaded, making it easy to parse.

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

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

With no annotations, no output schema, and two undocumented parameters, the one-sentence description is too thin. It lacks parameter semantics, return expectations, and guidance on how this tool fits among the many health-related sibling 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 only loosely mentions 'health set' without tying it to the healthSet parameter or explaining accepted values. The required server parameter is entirely undocumented, so the description does not compensate for the missing parameter information.

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

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

The description uses a specific verb ('Get') with a clear resource ('monitoring items') and qualifies the scope ('for a health set'). It identifies what the tool does, though it does not explicitly distinguish it from sibling health-related tools like exchange_get_server_health or exchange_get_health_report.

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. The sibling list contains several health/monitoring tools, but the description provides no conditions, exclusions, or alternative routing.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the 'get' operation from the name and does not disclose whether output is a list of queue objects, whether a server is required, or any permissions/impact details.

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. 'Get transport queues' is the core action and 'key for troubleshooting mail flow' adds brief, useful context without bloating the text.

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

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

For a tool with no annotations and no output schema, this description is too thin to fully inform an agent. It leaves unclear what the return data looks like, which server scope applies, and how this relates to the queue digest and queue-management siblings.

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

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

The schema already describes both parameters (filter and server), including an example PowerShell filter, so schema coverage is 100%. The description adds no parameter-level detail, so it earns the baseline 3 rather than extra credit.

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 transport queues') and identifies the PowerShell cmdlet (Get-Queue), so an agent knows what object is being acted on. It does not differentiate from the sibling exchange_get_queue_digest, which is also queue-related.

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?

'Key for troubleshooting mail flow' gives a general context in which the tool is useful, but it does not state when to prefer this over queue digest, retry queue, or suspend queue tools. Usage guidance is implied rather than explicit.

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

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

With no annotations, the description must carry behavioral details. The 'Get' verb and 'digest' wording reasonably signal a read-only, aggregate operation across the DAG, but the description does not disclose what data the digest contains, whether it is aggregated, or any permission/error 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?

One short sentence front-loads the action, resource, and scope with no filler or redundant explanation. The parenthetical cmdlet name adds useful canonical context without bloating the description.

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

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

For a low-complexity tool with one optional parameter and no output schema, the description is minimally sufficient: an agent can infer it returns a DAG-wide queue summary and may pass a dag value. However, the missing parameter semantics and lack of any output description keep it from being fully complete.

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

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

Schema description coverage is 0%, so the description needed to explain the dag parameter, but it only repeats the word DAG. It does not clarify whether dag is a filter, how to format a DAG identifier, or what happens when the parameter is omitted.

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 ('Get') and resource ('queue digest') with an explicit scope ('across DAG'), making it distinguishable from the more targeted sibling exchange_get_queue. It would be a 5 if it explicitly described what a digest contains or contrasted itself with queue-level retrieval.

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 guidance is provided. The description does not say when to use this instead of exchange_get_queue, exchange_suspend_queue, or the other siblings, nor does it specify conditions or exclusions; the only contextual signal is the 'across DAG' scope.

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 verb 'List' signals a read-only operation with no side effects, and the parenthetical clarifies that the output is permission-related. With no annotations provided, this is enough context for a parameterless list operation, though it does not disclose pagination or exact return fields—minor gaps for such a simple 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, front-loaded, information-dense phrase. Every word adds value: 'List' communicates the operation, 'role groups' the resource, and 'RBAC — Permissions' the contextual category.

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

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

For a parameterless list operation, the description is largely complete: it names the resource and the domain. It does not mention return value shape or whether all role groups are returned, but given the low complexity and absence of parameters, these are acceptable omissions.

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

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

The input schema has zero parameters, so there is no parameter meaning for the description to add. The baseline for 0-parameter tools is 4, and the description correctly focuses on the tool's purpose rather than inventing unnecessary parameter 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 states a specific action ('List') and resource ('role groups'), and the parenthetical 'RBAC — Permissions' clarifies the domain. This cleanly distinguishes it from the many other exchange_list_* sibling tools that deal with mailboxes, groups, connectors, or 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?

No explicit when-to-use or alternative guidance is provided, but the resource name makes the use case inferable: enumerate RBAC permission groups. Among the sibling tools there is no competing role-group listing tool, so the lack of an explicit alternative is not a major issue.

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 burden of behavioral disclosure. It only says server details are retrieved; it does not clarify read-only nature, required permissions, output shape, or any side effects or sensitivity.

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 short and front-loaded, but it is under-specified rather than adequately concise. It essentially restates the tool name and carries no additional information.

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

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

With no annotations, no output schema, and many closely related siblings, the description is incomplete. An agent cannot tell what details are returned, how identity should be formatted, or when this tool is the right choice among server-related getters.

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 one required string 'identity' with 0% description coverage, and the description adds no explanation of what identity should be (server name, FQDN, GUID?). The tool name weakly implies a server identifier, but this is not enough for an agent to confidently construct a valid 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 states a clear verb ('Get') and resource ('Exchange server details'), so an agent knows the basic operation. However, 'details' is broad and does not distinguish it from closely related siblings such as exchange_get_server_health or exchange_get_server_component_state.

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. It does not mention exchange_list_servers for enumeration or the health/state getters, and provides no prerequisites or typical use cases.

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 burden of behavioral disclosure. The verb 'Get' implies a read-only operation and the parenthetical shows possible output content. However, it does not describe the return shape, whether the state is live or cached, or any prerequisites, though the simple read-only nature reduces the severity of these gaps.

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

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

One short, efficient sentence with no filler. The parenthetical example adds useful specificity without bloating the description. 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?

With no annotations and no output schema, the description should explain the return context more fully. It does not say what component states can appear, what the output looks like, or how to specify the server. For an agent selecting and invoking this tool, there are meaningful gaps beyond the one-liner.

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 one required server parameter with no description, and schema description coverage is 0%. The description never mentions the parameter or explains whether 'server' expects a hostname, FQDN, or Exchange identity. The parameter name is somewhat self-explanatory from the tool name, but no meaningful additional semantic context is 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?

States a clear verb and resource: it gets server component states, with an example state value (ServerWideOffline) to add specificity. It does not explicitly differentiate itself from health-related siblings like exchange_get_server_health, but the resource is distinctive enough.

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?

Provides no guidance on when to use this tool versus alternatives. Given many sibling tools deal with server health, monitoring, and transport service state, the description gives an agent no basis for choosing this over a nearby alternative.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the cmdlet and Managed Availability health sets, but does not state whether this is a read-only operation, what data is returned, whether permissions are needed, or any side effects. This is a significant gap for a tool with zero annotation coverage.

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

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

The description is a single, compact sentence that front-loads the operation and includes a clarifying parenthetical. It is appropriately brief with no filler, though it could arguably include a bit more utility without becoming bloated.

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

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

For a tool with no annotations, no output schema, and an undocumented optional parameter, the description is too thin. It lacks details on the healthSet parameter, expected return shape, and when to prefer this over related sibling health tools, leaving an agent under-informed.

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

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

Schema description coverage is only 50%: the server parameter has a basic description, but healthSet has none. The tool description adds no information about what healthSet accepts or how it affects results, so it does not compensate for the undocumented parameter.

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

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

The description clearly states the verb 'Get' and resource 'server health', and adds specificity with 'Managed Availability health sets', which distinguishes it from generic health queries. However, it does not explicitly differentiate from sibling tools like exchange_get_health_report or exchange_test_service_health, so it falls short of a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives such as exchange_get_health_report, exchange_test_service_health, or exchange_get_server_component_state. An agent has to infer the use case from the tool name and terse 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 exist, so the description carries the full burden of behavioral disclosure. It only says 'Get', which implies a read, but it does not say whether it returns a list or a single object, whether permissions are required, or whether there are any limitations. This is minimal for an unannotated tool.

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

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

The description is a single concise sentence with no filler. The parenthetical clarification adds value without bloat, and the core operation is front-loaded.

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

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

For a zero-parameter read tool, the invocation surface is trivial, so this is minimally viable. However, with no output schema and no annotations, the description does not clarify return shape/volume or any prerequisites, leaving some context 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?

The input schema has zero parameters, so there is no parameter documentation burden for the description to carry. The baseline of 4 applies because the description does not need to compensate for undocumented parameters.

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

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

The description uses a specific verb ('Get') and a specific resource ('transport rules'), with the parenthetical 'mail flow' clarifying the domain term. This resource is unique among the sibling tools, so an agent can distinguish this tool from other Exchange getters.

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 instead of alternatives, nor any exclusions or related-tool references. The resource name only implies a use case; no explicit selection context is provided.

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

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

There are no annotations, so the description must carry the entire behavioral burden. 'Get' implies a read-only action, but nothing is said about what a config consists of, what the response looks like, or whether any side effects or prerequisites exist. For a no-annotation tool, 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 text is short and front-loaded with the key action, with no wasted words. However, it is so terse that it sacrifices useful context; it reads more like a label than a genuinely informative description.

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

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

The tool has no output schema and no annotations, and the description does not explain the return value, the optional server input, or how 'transport service config' should be interpreted. Given a one-line description, an agent would likely need to probe or guess to use the tool correctly.

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

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

The single 'server' parameter has zero schema description coverage and is not mentioned in the description. The agent cannot infer whether server is required, what format it should take, or its role in selecting the transport service. The description adds no parameter meaning beyond the bare schema 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?

States an unambiguous verb 'Get' and a specific resource, 'Transport service config', which is distinct from sibling tools like exchange_get_transport_rules. It tells an agent what object is being retrieved, though it doesn't explicitly contrast with related getters.

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

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

No when-to-use or alternative guidance appears; the description is a bare statement of the operation. There is no mention of when exchange_get_transport_service should be selected over siblings like exchange_get_server or exchange_get_transport_rules, and no exclusions are given.

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

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

With no annotations, the description carries the full burden. The verb 'Get' implies a read-only operation, and the resource is clearly identified, but there is no disclosure of default behavior when parameters are omitted, whether a server filter is needed, permissions, or output format. This is acceptable for a simple getter but lacks deeper 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 clear sentence with no fluff, and the supported protocol types are front-loaded in parentheses for quick scanning. It is appropriately sized, though it could sacrifice some brevity to explain parameter behavior.

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 no required parameters, no output schema, and no annotations, the description is too thin. It does not explain what happens when no type or server is provided, what the response contains, or any constraints on the server parameter. An agent cannot confidently know the full behavior from this description alone.

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 parameters. It names the protocol types that map to the 'type' enum, but that information is already present in the schema. The 'server' parameter is entirely undocumented in both the schema and description, so the description adds little semantic 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 uses a specific verb ('Get') and a clear resource ('virtual directories'), with a parenthetical enumerating the relevant protocol types (OWA/ECP/EWS/ActiveSync/MAPI). This clearly distinguishes it from all sibling tools, none of which target virtual directories.

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

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

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about when it would be the appropriate choice. It is only a bare statement of what the tool does, leaving the agent to infer 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. 'List' implies a read-only, non-destructive operation, but the description does not mention output format, pagination, or any operational caveats.

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 three words and is front-loaded with the action and resource. Every word earns its place, and there is no filler or redundant 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 zero-parameter list, the minimal description is mostly adequate, but the lack of an output schema and any clarification of what counts as an accepted domain leaves room for inference. A bit more context about the return value or how this differs from remote domains would make it complete.

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

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

The tool accepts zero parameters, and the input schema already documents this with an empty properties object. With 0 parameters, the baseline is 4, and no additional parameter explanation is needed.

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

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

The description uses a specific verb ('List') and a clear resource ('accepted domains'), so an agent can understand the core operation. However, it essentially restates the tool name and does not differentiate it from sibling tools such as exchange_list_remote_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?

No guidance is provided about when to use this tool versus alternatives like exchange_list_remote_domains. There are no prerequisites, exclusions, or contextual cues beyond the resource 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'List distribution groups' and does not explain whether the optional filter is applied, how results are returned, or any access requirements. The read-only nature of 'List' is the only inferred behavioral trait.

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 it omits essential guidance about filtering and sibling differentiation. This is under-specification rather than appropriate 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?

With no annotations, no output schema, and an undocumented parameter, a single clause is insufficient. The description leaves the filter semantics undefined and fails to distinguish static distribution groups from dynamic distribution groups, making it incomplete for safe invocation.

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

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

Schema description coverage is 0%, and the description does not mention the optional 'filter' parameter at all. An agent must guess what values filter accepts and how filtering affects the result set, making the description unhelpful for parameter understanding.

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

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

The description uses a specific verb ('List') and resource ('distribution groups'), making the core intent clear. However, it does not differentiate from the sibling exchange_list_dynamic_distribution_groups, so an agent may not know which listing tool 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 exchange_list_dynamic_distribution_groups or other list/read tools. There are no exclusions, prerequisites, or alternative mentions.

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 the basic operation. It does not reveal what the response contains, whether any filtering or paging applies, or any side effects beyond the implied read-only listing.

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

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

The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to identifying the operation, making it appropriately concise.

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 no annotations and no output schema, the description leaves important gaps: it does not explain what a 'dynamic distribution group' listing returns, nor does it differentiate itself from the very similar sibling 'exchange_list_distribution_groups'. The agent receives just enough to guess the operation, but not enough to invoke it confidently.

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

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

The tool takes zero parameters, so the empty schema covers 100% of the input surface. The baseline for zero-parameter tools is 4, and the description does not need to contribute parameter details that do not exist.

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

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

The description uses a clear verb ('List') and a specific resource ('dynamic distribution groups'), making the core action unambiguous. The term 'dynamic' helps differentiate it from the sibling 'exchange_list_distribution_groups', though the distinction is not explicitly stated.

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

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

The description gives no guidance on when to use this tool versus closely related alternatives such as exchange_list_distribution_groups. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer selection criteria from the name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states a read-only listing action and does not mention scope, pagination, what the includePreExchange2013 flag affects, or any other behavioral characteristics.

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 and front-loaded, with no filler words. However, it is under-specified to the point of being terse: it omits parameter meaning and usage context, so the brevity is not fully effective.

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

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

For a simple one-parameter listing tool, the description is incomplete. It does not explain the optional includePreExchange2013 parameter, the expected output, or when to select this tool over related siblings. With no output schema, the description should have provided more 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 does not explain the only parameter, includePreExchange2013. The parameter name hints at including pre-Exchange 2013 databases, but its effect, default value, and usage are entirely undocumented.

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

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

The description 'List mailbox databases' uses a specific verb and resource, clearly indicating a collection-level listing operation. It does not explicitly differentiate from the sibling exchange_get_mailbox_database, but the plural 'databases' versus singular sibling names provides a reasonable distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives such as exchange_get_mailbox_database or exchange_get_database_copy_status. There are no stated conditions, exclusions, or recommended use cases.

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 is the only behavioral disclosure. It reveals the admin scope and optional filter/recipient-type support but says nothing about permissions, result size limits, pagination, or whether it returns a summary vs full objects. This is minimal for a no-annotation tool.

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

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

One compact sentence with the core operation front-loaded and no filler. Extra context is limited but 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 no annotations and no output schema, the description is thin: it doesn't state return shape, error behavior, or the effect of resultSize. The admin qualifier and supported filters are useful, but an agent would still be guessing about several invocation details.

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

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

The description calls out filter and RecipientTypeDetails, mirroring two of the three schema parameters, but uses a different term ('RecipientTypeDetails' vs 'recipientType') and adds no meaning beyond the schema. It omits resultSize entirely, so the 67% schema coverage gap is not closed.

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 and resource ('List mailboxes') and signals an administrative scope, distinguishing it from single-mailbox get/set operations among siblings. It does not enumerate what is returned, but 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?

The description says the tool lists mailboxes for admins but gives no guidance on when to choose it over exchange_get_mailbox or the other list_* siblings. There are no exclusions or alternative routing conditions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List mail contacts' only weakly implies a read-only operation and does not disclose pagination behavior, result limits, or whether all contacts are returned. The description adds little beyond 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?

The description is extremely concise and front-loaded, containing no filler or redundant wording. While it is terse, it effectively communicates the core action in three words, which is appropriate for the low parameter count.

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

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

The tool has no annotations and no output schema, so the description must provide context. It fails to explain the optional resultSize parameter, return format, or distinctions from sibling list tools. Given the minimal schema, an agent may still be uncertain about expected behavior.

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 the resultSize parameter at all. The schema only provides a type of 'number', leaving the agent without any explanation of what resultSize controls, its default, or its maximum.

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

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

The description clearly states the verb 'List' and the resource 'mail contacts', which is a specific Exchange object type. Among sibling tools like exchange_list_mailboxes and exchange_list_mail_users, the resource term helps distinguish it, though it does not elaborate on scope or exact meaning of 'mail contacts'.

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 sibling alternatives such as exchange_list_mail_users or exchange_list_distribution_groups. No prerequisites, exclusions, or selection criteria are provided, so the agent must rely only on naming conventions.

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

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

With no annotations, the description carries the full burden but only implies a read-only list operation. It gives no information about pagination, result limits, response shape, required permissions, or whether all mail users are returned.

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

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

The description is short but not usefully concise; it is under-specified. It has no structure or elaboration that would help an agent decide whether to invoke it.

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 one undocumented parameter, no output schema, and a large group of similar sibling tools, a single restatement of the tool name is far from complete enough. Key details such as resultSize semantics, return value shape, and differentiation from other list tools are missing.

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

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

The only parameter, resultSize, has no schema description and is not mentioned in the tool description. An agent cannot determine what resultSize means, whether it is a maxium, an offset, or something else.

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 'List mail users' essentially restates the tool name 'exchange_list_mail_users' and provides no additional meaning. It does not clarify what counts as a mail user or how this differs from sibling tools like exchange_list_mailboxes or exchange_list_mail_contacts.

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 prefer this tool over the many sibling list/get tools. No use conditions, exclusions, or alternatives are mentioned.

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

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

With no annotations, the description carries the full burden. It transparently indicates a listing operation and that the server parameter is optional for scoping. It does not disclose additional behavioral details such as permissions, output shape, or what happens when the server parameter is omitted, but the operation itself is low-risk and clearly read-oriented.

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

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

The entire description is one short, front-loaded sentence with no filler. It conveys the core action, the resource, and the optional scoping behavior efficiently.

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

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

For a simple list tool, the description is mostly adequate, but it could be more complete. It does not specify whether omitting the server returns all receive connectors, which identifier formats are accepted for the server, or what output is returned. Since there is no output schema and no annotations, a bit more context would help.

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 provides only a bare 'server' string with no description, so the phrase 'optionally per server' adds meaningful semantics: the parameter is optional and filters the listing to a particular server. This compensates for the 0% schema coverage for a single simple parameter.

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

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

The description uses a specific verb ('List') and a specific resource ('Receive connectors'), and it also notes the optional server scoping. It clearly identifies the tool's function, though it does not explicitly contrast it with sibling tools like exchange_list_send_connectors.

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 usage context is implied: use this tool when you need to list receive connectors, optionally scoped to a server. However, there is no explicit guidance about when to prefer this tool over related list tools, nor any exclusion criteria.

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 carries the full burden. 'List' implies a read-only, non-destructive operation, and with zero parameters there is little behavioral complexity to disclose. However, it does not explicitly mention absence of side effects, required permissions, or output characteristics, leaving some implicit.

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 phrase with no redundancy or fluff. It is front-loaded and efficient, though extremely minimal rather than richly informative. It earns a solid score for 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 zero parameters and low complexity, the description is minimally viable for invocation. However, it does not explain what remote domains are, differentiate them clearly from accepted domains, or indicate what data is returned. The absence of an output schema increases the need for such context, which 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?

The input schema has zero parameters, so there are no parameter semantics to explain. The description does not need to add anything about parameters, making the baseline score of 4 appropriate.

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

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

The description 'List remote domains' uses a specific verb and resource, making the operation clear. It distinguishes from sibling tools by naming 'remote domains' as opposed to 'accepted domains' or 'mailboxes'. However, it is essentially a restatement of the tool name and adds no additional context.

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. With over 40 sibling tools including exchange_list_accepted_domains and exchange_list_servers, the description does not state any conditions, 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?

No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, but the description does not disclose return format, pagination, scope, or any other behavioral characteristics. It adds almost nothing beyond 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?

The description is extremely short and front-loaded, with no filler words. However, its brevity borders on under-specification rather than deliberate conciseness, so it does not earn a 5.

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

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

Given there is no output schema and no annotations, the description should provide more context about what the returned list contains or how to distinguish this from related list tools. 'List Send connectors' is minimally functional but leaves the agent without enough context for confident selection and interpretation.

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 the input schema is empty. There is nothing for the description to clarify, so the baseline of 4 applies. The description does not need to explain parameter meaning because no parameters exist.

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

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

The description states a specific verb ('List') and resource ('Send connectors'), which clearly identifies the operation and differentiates it from sibling tools like exchange_list_receive_connectors. However, it essentially restates the tool name without adding further context or detail, so it stops short of a 5.

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

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

There is no guidance about when to use this tool versus alternatives, nor any exclusions or prerequisites. The only implied usage is that sending-related connector enumeration should use this tool, which is not explicitly stated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. 'List' and 'Get-ExchangeServer' signal a read-only enumeration, but the description does not state the output shape, server scope, or any prerequisites. For a zero-parameter read operation this is adequate but minimal.

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 the action and resource front-loaded. The parenthetical cmdlet adds grounding without unnecessary verbosity.

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

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

For a zero-parameter list command, the description is mostly complete: no input is required, and the intent is clear. It could be improved by explicitly mentioning the alternative exchange_get_server or clarifying that it returns all servers, but no critical invocation detail 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?

The tool has zero parameters, and the schema already documents an empty parameter set. The description does not add parameter detail, but none is needed, so the baseline of 4 applies.

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

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

The description clearly states the verb 'List' and the resource 'Exchange servers', and adds the underlying PowerShell cmdlet name for grounding. However, it does not explicitly distinguish itself from the closely related sibling exchange_get_server, which could cause mild ambiguity about list-all versus get-one behavior.

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 usage is implied: use this tool when you want to enumerate Exchange servers. There is no explicit when-not-to-use guidance, and the related alternative exchange_get_server is not mentioned, leaving the agent to infer the distinction from the tool names 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 burden of behavioral disclosure. The verb 'Remove' and the parenthetical 'delete' correctly signal a mutating/destructive operation, but the description does not state whether the mailbox data is purged, whether the operation is reversible, whether the associated Active Directory user is affected, or what the difference between 'disable' and 'delete' actually is. This is a significant 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 compact and front-loaded with the action verb, containing no filler words. However, the brevity crosses from conciseness into under-specification for a destructive tool with two undocumented parameters; six words of description are not an appropriately sized payload for the decisions an agent must make.

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 absence of annotations, an output schema, and any parameter documentation, the description needed to supply the semantics of the destructive operation and its parameters. It only covers the action itself. Missing are the meaning of 'permanent', the expected identity format, the default behavior, the side effects on user/mailbox data, and any return value, leaving an agent unable to call the tool correctly with 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 description coverage is 0%, so the description must compensate, but it explains neither parameter. 'identity' could be a UPN, email address, GUID, or distinguished name — unspecified. 'permanent' is a boolean whose semantics are highly ambiguous: does false mean a soft-delete that can be restored, or a disable that keeps the mailbox object? The description's '(disable/delete)' hints at this distinction but never connects it to the parameter.

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

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

The description uses a specific verb ('Remove') with a clear resource ('mailbox') and the parenthetical '(disable/delete)' elaborates on what the action entails. It is readily distinguishable from the sibling set: exchange_create_mailbox, exchange_set_mailbox, and exchange_get_mailbox are clearly different operations. It loses the fifth point because the description never explains how 'disable' and 'delete' differ behaviorally or which is the default.

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. With over 35 siblings including exchange_set_mailbox and exchange_create_mailbox, an agent receives no hint about whether this is the right tool for deprovisioning a user, hiding a mailbox, or permanently purging data. No exclusions, prerequisites, or alternative names are mentioned.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It states the operation is a retry, but omits side effects, permissions, idempotence, or whether it affects all messages in the queue.

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, but it is closer to under-specification than to genuinely helpful conciseness. The parenthetical "troubleshooting" is marginal and does not provide useful structure.

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

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

With no annotations and no output schema, the description must explain enough for an agent to call the tool correctly. It does not clarify what a retry does, what the required identity must look like beyond the schema example, what the server parameter is for, or what the return value indicates.

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

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

Schema description coverage is only 50%, with the server parameter undocumented, and the description adds no parameter-level meaning. The identity parameter's format example comes from the schema, not the description, so the description fails to compensate for the missing server semantics.

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

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

"Retry a queue" names a specific verb and resource, and the troubleshooting hint makes the operation's intent reasonably clear. It does not explicitly contrast with siblings like exchange_suspend_queue, but the action is not ambiguous enough to be considered vague.

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. "Troubleshooting" only implies a broad context and does not mention queue states, suspended queues, or related sibling 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, the description must carry the behavioral disclosure burden. 'Search' implies a read-only operation, but the description does not explicitly state that it makes no modifications, nor does it mention default behavior, date handling, pagination, or permissions. This is insufficient for an audit-log 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 compact sentence with no fluff, and the core verb+resource pair is front-loaded. It loses a point for omitting useful structure such as a parameter overview or usage note, but as a concise statement it works.

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 four undocumented parameters, no annotations, no output schema, and a large sibling set, this one-line description is far from complete. An agent cannot determine parameter formats, defaults, return data, or constraints, making successful invocation uncertain.

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

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

The input schema has four parameters with 0% description coverage, and the description does not explain startDate, endDate, userIds, or resultSize. The agent is left to infer semantics from parameter names alone, which is not enough given 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 states a specific verb and resource: 'Search admin audit log', and the parenthetical '(compliance)' signals the primary use case. It is clearly distinguishable from siblings like exchange_get_message_tracking_log because the resource differs, though it does not explicitly contrast them.

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

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

There is no guidance on when to use this tool versus alternatives. The word 'compliance' hints at a context but does not explain when to choose this over message tracking, mailbox queries, or other search 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 full burden of behavioral disclosure. It indicates mutation via 'Set', but does not explain side effects, whether unspecified properties are reset, permission requirements, or what response to expect. This is similar to other minimally-described mutation tools.

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 front-loads the action. It is appropriately concise, though the vague 'etc.' reduces precision slightly.

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

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

The tool is a mutation operation with no annotations and no output schema, and the description provides only the broad action. It omits critical context like which mailbox is being modified, how quota values should be formatted, and whether this replaces all mailbox properties or only the specified ones.

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

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

Schema coverage is 0%, so the description must compensate, but it only names one actual parameter (prohibitSendQuota) and mentions 'retention', which does not appear in the schema. It does not explain 'identity', 'issueWarningQuota', or 'customAttribute1', nor their expected formats such as quota values.

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

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

The description states a specific verb ('Set') and resource ('mailbox properties'), and names example properties. It distinguishes the tool from sibling get/list/create/remove tools through the verb 'set', though it does not explicitly contrast with exchange_create_mailbox.

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

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

The description implies this is for modifying properties on an existing mailbox, which is a clear usage context. However, it gives no explicit guidance on when not to use it, nor does it mention alternatives like exchange_create_mailbox for new mailboxes or exchange_get_mailbox for reads.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Suspend a queue' with no explanation of effects, reversibility, or whether suspending stops message processing. The agent is left to infer the behavior from the tool name alone.

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 filler, and the main action is front-loaded. However, it is so terse that it sacrifices useful detail, though conciseness itself is not the issue.

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

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

For a tool with one parameter and no annotations, the description should at least explain what suspension does and identify the expected identity value. The sibling tools imply a queue-management context, but the description alone does not provide enough for correct invocation.

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

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

The schema has a single required 'identity' string parameter with no description and 0% schema description coverage. The tool description does not clarify what identity refers to, whether it is a queue name, ID, or path, or how to obtain it.

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 'Suspend a queue' has a specific verb and resource, and the action is distinct from sibling tools like exchange_retry_queue and exchange_get_queue. It clearly identifies the operation but does not specify what suspending entails or what kind of queue is targeted, 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?

There is no guidance on when to use this tool versus alternatives such as exchange_retry_queue or exchange_get_queue. The description gives no context about queue state, prerequisites, or the lifecycle relationship between suspending and retrying a queue.

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 clearly identifies the tool as diagnostic and non-mutating by using words like 'diagnose' and 'tests,' and specifies the components being checked. It could add more detail about outputs or failure modes, but for a connectivity test tool this is adequate.

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

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

Two tight sentences deliver the core function, the specific checks, and the recommended invocation scenario. Every word earns its place, and the key usage guidance is front-loaded.

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

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

For a low-complexity tool with one optional parameter and no output schema, the description provides everything needed to decide when and why to call it. It is self-contained and actionable.

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

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

Schema coverage is 100%: the parameter 'target' has an enum and a clear description ('Which endpoint to test, default all'). The tool description adds some color by connecting the 'powershell' endpoint to the PowerShell virtual directory and mentioning auth, but does not substantially extend the schema's 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 names a specific action ('Diagnose Exchange connectivity') and enumerates exactly what it tests: endpoint reachability, PowerShell virtual directory, and auth. This clearly separates it from sibling tools like mail flow tests or health checks.

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 an explicit trigger condition: 'Use when all tools return 404.' This is clear context for when to invoke the tool. It does not name alternative test tools or explicitly state when not to use it, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It merely repeats the tool name and gives no information about side effects, permissions, scope, or what 'testing mailflow' actually does.

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 fluff, but this is under-specification rather than effective conciseness. It does not earn its place because it adds no information beyond the tool name.

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

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

With no annotations, no output schema, zero parameter documentation, and a tautological description, this tool definition is far from complete. An agent cannot reliably determine what this tool does, why it exists, or how 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 does not mention sourceMailbox or targetMailbox at all. The agent is left with only the parameter names, which are suggestive but not explained.

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 'Test mailflow (Test-Mailflow)' states a verb and a resource, but it is essentially a restatement of the tool name. It does not define what 'mailflow' means or distinguish this tool from sibling test_* tools like exchange_test_connection or exchange_test_service_health.

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. The description provides no conditions, exclusions, or context for selecting it over the many sibling testing tools.

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

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

No annotations exist, so the description carries the full burden of behavioral disclosure. It only says a health test runs; it does not state whether the operation is read-only, what side effects it might have, what permissions are needed, or what output to expect.

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 the core action. The parenthetical repeats some wording but adds DAG context and a cmdlet-style name, so it is not wasted.

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

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

For a one-parameter tool with no annotations and no output schema, this description is too thin. It omits what 'server' refers to, what the health result looks like, and when this test should be run, leaving significant gaps for an agent.

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

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

The schema has one parameter, 'server', with zero description coverage, and the description does not explain it at all. With the schema providing no parameter details, the description needed to compensate and did not.

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

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

States a specific verb ('Test') and resource ('replication health'), and the DAG parenthetical adds Exchange-specific scope that helps distinguish it from siblings like exchange_test_mailflow and exchange_test_connection. It is clear but could more explicitly differentiate it from related health/database-copy tools.

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

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

No when-to-use guidance, prerequisites, or exclusions are provided. The DAG mention implies a context, but with many sibling health/test tools, an agent gets no help choosing this tool over alternatives.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'checks required services' and does not explain what services are checked, what success/failure looks like, whether it is read-only, or what the output 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 short and front-loaded, which is good, but the second clause 'checks required services' largely restates the tool's name and adds little new information. It is concise without being informative.

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

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

With no annotations, no output schema, and minimal parameter information, this description is not complete enough for an agent to know what the tool returns, when to use it, or how to interpret the result. The abundance of similar sibling health tools increases the need for contextual clarity.

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 sole parameter 'server' is completely undocumented. The description does not mention this parameter or give any hint about its format, meaning, or optionality, so an agent has no guidance for setting it.

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 'Test' and the resource 'service health', so an agent can grasp the basic purpose. However, it does not distinguish this from sibling tools like exchange_get_server_health or exchange_get_health_report, which also relate to health.

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, nor any exclusions. An agent must infer that this is for checking required services, but the description never explains why this would be preferred over other health-related tools.

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