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

No annotations exist, so the description has to carry the behavioral disclosures. It does state the side-effect at a high level and highlights a validation requirement, but it does not mention reversibility, whether it applies unilaterally to future mail, or possible side effects. Valuable but not complete.

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 sentences with no filler; the action is front-loaded and the most important constraint immediately follows. 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?

This is a 21-parameter mutation with no output schema and no annotations. The description only covers the core action and the minimum-match-field rule. It does not explain how the optional modifiers (actionNeeded, quarantineAll, ignoringSpfCheck, matchOnlyFuture, *_Matching) interact, nor what the tool returns. That leaves a substantial part of the call surface unexplained.

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

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

Schema descriptions cover 71% of parameters, so the baseline is moderate. The description adds a crucial cross-field invariant that the schema does not capture: at least one match field from a specific list is required, which meaningfully guides agent input beyond the schema.

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

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

States a specific action and resource: 'Add a whitelist or blacklist entry.' This immediately differentiates it from the get/list/update/delete exception siblings and within exception CRUD. No ambiguity about the core purpose.

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

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

Gives a useful invocation context (at least one match field) and the verb 'Add' implies creation rather than update/delete. However, it does not explicitly say when to prefer this tool over update_exception or list_exceptions, so the choice is left inferred.

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 reveals that this is a mutating action affecting a tenant's license and add-on assignments, but it does not disclose whether existing licenses are replaced, whether the operation is reversible, what side effects occur, or what the response looks like.

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

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

The description is a single concise sentence with no filler or redundancy. It front-loads the core action ('Assign a license') and appends the optional add-on scope without wasting words.

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

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

For a straightforward mutation tool with fully documented parameters and a clear purpose, the description is minimally adequate. However, with no output schema and no annotations, an agent would benefit from knowing what the API returns, whether the assignment overwrites existing license configuration, and any permission prerequisites.

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

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

Schema description coverage is 100%, so the parameter schemas already document all four parameters and their meanings. The description adds little beyond the schema, but the baseline of 3 is appropriate because the schema carries the semantic weight.

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 ('Assign') and resource ('a license ... to an existing customer tenant'), making it clear what the tool does. It adds 'optional add-ons' and 'existing customer tenant,' which helps distinguish it from tenant-creation and license-listing siblings, though it does not name the alternatives explicitly.

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

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

The description implies the tool is used when assigning a license to an existing tenant, but it provides no explicit guidance about when to prefer this over other operations or when not to use it. There is no mention of prerequisites such as first retrieving available licenses via avanan_list_licenses.

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 behavioral burden. It explains the creation action but does not disclose response behavior, idempotency, permissions, or how the 'current MSP' is determined.

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 main action is front-loaded in one concise sentence retd. The endpoint and guide date add useful provenance but are secondary to selecting or invoking the tool.

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

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

For a creation operation with no annotations and no output schema, the description lacks important operational context such as return values, idempotency, permissions, or how the current MSP is identified. The endpoint mention is helpful but not sufficient.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds the 'under the current MSP' context but no additional parameter-level meaning.

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

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

States a specific verb and resource: creates a new child MSP partner under the current MSP. This clearly distinguishes the tool from siblings like list, delete, or create-user operations.

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

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

No guidance is provided on when to use this tool over alternatives, nor any prerequisites such as requiring the current MSP context or whether partner creation is needed before assigning tenants. The agent must infer usage from the name and sibling list.

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

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

With no annotations, the description carries the full burden for behavioral disclosure, but it only restates the creation operation. It does not mention permissions, idempotency, validation failures, whether an existing email causes an error, or any side effects beyond creating the user.

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

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

A single, front-loaded sentence states the action and resource with no filler. Every word contributes to purpose clarity.

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 schema provides complete parameter semantics, so an agent can assemble the required fields. However, with no annotations and no output schema, the description omits behavioral context such as response behavior, error conditions, or permission requirements, leaving the definition only minimally complete for a complex create operation.

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

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

Schema description coverage is 100%, so the input schema already documents all 10 parameters, including the role enum and MSPId constraint. The description adds no parameter-level detail, which is acceptable under the high-coverage baseline.

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

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

The description uses a specific verb ('Create') and a specific resource ('MSP user'), clearly distinguishing it from sibling operations like list/get/update/delete MSP users. There is no ambiguity about the tool's core function.

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 this tool is for creating a new MSP user, and the sibling names make alternatives (update/delete/get/list) evident. However, it does not explicitly state when to prefer this tool over those alternatives or mention prerequisites such as parent MSP authorization.

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 states the action ('create') but does not disclose side effects, permissions required, whether the operation is reversible, what happens on duplicate tenant names, or what the response contains. For a creation tool with no annotations and no output schema, this is a significant gap.

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

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

The description is a single clear sentence with no wasted words. It is front-loaded with the verb and resource. It could earn a 5 by adding a brief usage condition, but as-is it is efficient and readable.

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 creation tool with no annotations and no output schema, the description is thin. It does not mention required permissions, the meaning of the MSPId field for parent MSPs, or what a successful creation returns. The schema covers parameters, but the description does not provide the operational context an agent needs to invoke this correctly in an MSP hierarchy.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters. The description adds no parameter-level meaning beyond what the schema provides. The MSPId parameter's conditional behavior ('Parent MSPs only') is in the schema, not the description, so the description does not compensate for any ambiguity. Baseline 3 is appropriate given full schema coverage.

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

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

The description states a specific verb ('create'), a specific resource ('customer tenant'), and the scope ('under the current MSP'). It clearly distinguishes this from sibling tools like avanain_create_msp_partner and avanain_create_msp_user, which create different resource types. The title is null, but the description alone 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 implies the tool is for MSPs creating customer tenants, and the sibling list shows related create tools for MSP partners and users, but there is no explicit guidance on when to choose this over alternatives. The MSPId parameter hints at a parent/child MSP scenario, but the description does not explain when to use it or when to use a different creation tool. Usage context 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?

Annotations already flag destructiveHint, but the description adds 'irreversible' and instructs to confirm with the user, giving agents a concrete safety protocol. It also specifies the deletion is by entity IDhol. No contradiction with annotations; the explicit destructive emphasis is useful. Not a 5 because it mostly restates structured intent with little operational detail beyond confirmation.

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 destructive nature and the exact operation the agent should complete. Every phrase contributes, no fluff.

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

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

For a simple destructive action, the description covers behavior, identifier, and safety protocol. It could mention where to obtain the entity ID or that the tool is irreversible in practical terms, but the combination of parameter names and descriptions make the call unambiguous.

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 both excType and excId and the allowed enum values; description adds little beyond 'by entity ID'. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly names the operation—deleting an exception entry—and identifies the target resource as a whitelist or blacklist entry keyed by entity ID. It is unmistakable what action the tool performs and is distinguishable from sibling add/get/update operations.

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

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

The description provides an important usage guardrail: confirm with the user before invoking. However, it does not explain when to choose delete over add or update, nor mention how the entity ID should be obtained (e.g., from a list operation), so the guidance is partial.

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 does well by explicitly warning that all tenants associated with the MSP are also deleted, a critical and non-obvious consequence. It does not mention reversibility or downstream effects on users/licenses, but the cascade warning is the most important safety-relevant 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 two short sentences with no filler. It front-loads the primary action and then adds the critical warning in a dedicated second sentence, so every word earns its place.

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

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

For a one-parameter destructive tool with no output schema, the description covers the target, the action, and the most important side effect. It could additionally state the expected response or explicitly confirm irreversibility, but the cascade warning provides the key missing context an agent needs to invoke this safely.

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

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

Schema coverage is 100%, and the schema already describes msp_id as 'ID of the MSP partner to delete.' The description only restates 'by ID' and adds no new parameter-level meaning. The baseline of 3 applies because the schema carries the parameter documentation burden.

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

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

The description uses the specific verb 'Delete' and names the exact resource ('child MSP partner by ID'), making the operation unambiguous. It also distinguishes this tool from sibling delete tools like avanan_delete_tenant and avanan_delete_msp_user by clearly targeting the MSP partner entity.

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

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

No explicit when-to-use or when-not-to-use guidance is provided beyond the core action. The wording implies this tool is for removing a child MSP partner, but it does not mention alternatives, prerequisites, or situations where the cascade makes deletion inappropriate. This leaves some routing to agent inference.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Delete', which states the action but does not disclose whether deletion is permanent, whether it cascades to related resources, or what response/error behavior to expect. For a destructive operation 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 clear sentence with no wasted words. It front-loads the operation and the identifying parameter, making it easy to scan.

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

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

The tool is a simple one-parameter delete operation, so the description covers the basic 'what' and 'how' adequately. However, because there is no output schema and no annotations, the absence of any behavioral or safety context leaves the agent under-informed about irreversible side effects or post-deletion expectations.

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

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

Schema description coverage is 100%, so the schema already documents user_id as 'MSP user ID.' The description adds minimal semantic value by restating that deletion is 'by ID', but this is consistent with the parameter and not misleading.

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

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

The description uses a specific verb ('Delete'), a specific resource ('MSP user'), and the selection criterion ('by ID'). It is immediately distinguishable from sibling tools like avanan_delete_msp_partner or avanan_update_msp_user.

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

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

The intended use is clearly implied by the delete verb, but there is no explicit guidance about when to choose this over alternatives or any caution about destructive consequences. It reads as a straightforward action statement rather than usage guidance.

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

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

No annotations are provided, so the description carries the full burden. It explicitly warns that the action deletes the tenant and all its data, disclosing the destructive and irreversible nature. This goes beyond the schema's parameter description and clearly signals mutational 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?

Two sentences with zero waste. The action is stated first, and the critical warning is appended. Every word earns its place, providing essential information without padding.

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

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

For a single-parameter delete tool with no output schema, the description is complete for correct invocation. It explains what happens (deletion with data loss) and the required ID. The warning covers the main risk, and the schema handles the parameter format. A 5 would require explicit mention of success/error responses or rollback absence, but these are minor for this simple tool.

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

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

Schema coverage is 100%—tenant_id is already described as 'Avanan tenant ID.' The description adds no further meaning beyond 'by ID,' which is redundant with the schema. Baseline 3 is appropriate because the schema fully documents the only 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 'Delete,' the resource 'customer tenant,' and the method 'by ID.' This distinguishes it from sibling tools like create_tenant, get_tenant, and list_tenants without requiring the agent to inspect schemas.

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

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

The description implies usage (delete a specific tenant) but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The destructive nature is hinted at via the warning, but no guidance is given on when not to use it (e.g., 'only when irreversible deletion is intended').

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, yet it only restates what the tool returns at a high level. It does not mention pagination via scrollId, whether results are read-only, permission requirements, or how the msp_ids filtering affects 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 efficient sentence with no wasted words and the key scoping information is front-loaded. It is concise without being padded, though it sacrifices some useful context for brevity.

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

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

Given five parameters, no output schema, and no annotations, the description is too thin to be fully actionable. It omits return value shape, pagination behavior for scrollId, and clarification of how msp_ids interacts with the 'across all customer tenants' statement.

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

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

Schema description coverage is 100%, so the schema already documents each parameter clearly. The description adds minimal extra meaning, though 'across all customer tenants' hints at the default scope when msp_ids is omitted. This meets the baseline but does not substantially exceed 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 action ('Get'), the resource ('daily usage details'), and the scope ('across all customer tenants') for a specific date. This immediately distinguishes it from the sibling tool avanan_get_monthly_usage, which covers a different time granularity.

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

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

The description implies the tool is for daily-level usage data, but it does not explicitly state when to use this tool over get_monthly_usage or any other sibling. There are no exclusions, prerequisites, or alternative routing guidance 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get full details' vaguely promises a return payload, but it does not explain what details are included, error/not-found behavior, permissions, or that this is a non-mutating read operation.

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

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

One clean sentence with no filler. The core purpose and the required identifier are front-loaded, and every word contributes to 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 single-parameter read tool, the description is serviceable but not complete. It lacks sibling differentiation, behavioral details like return contents or error behavior, and an explanation of how an agent would obtain an entityId. No output schema or annotations exist to fill these gaps.

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

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

The schema already documents entityId at 100% coverage, so the baseline is 3. The description adds some context by clarifying that entityId refers to a secured entity (email, file, or message), but it does not provide a format, example, or guidance on how to obtain the ID.

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 full details') and a clear resource scope: one secured entity (email, file, message) by Avanan entity ID. It is clear, but it does not explicitly distinguish itself from sibling tools such as avanan_get_event or avanan_search_emails, so it misses the full sibling-differentiation bar.

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. An agent is not told to use avanan_search_emails to find an entity ID first, nor told to use avanan_get_event for events. Usage is only implied when the agent already has an entity ID.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. 'Get' clearly indicates a read-only retrieval operation, and 'full details' communicates the expected scope of the return. However, it does not mention response structure, potential errors, or any permissions needed, which is acceptable but not rich for a simple get-by-ID tool.

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

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

The description is a single sentence with no filler. It front-loads the action, resource, and lookup key, and every word contributes to understanding the tool's purpose.

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

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

For a low-complexity tool with one required parameter and no output schema, the description is largely sufficient. 'Full details' conveys what the caller should expect as a return. It could be more explicit about where the event ID originates (e.g., from avanan_query_events), but that is reasonably inferable from the sibling tool names.

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

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

Schema description coverage is 100%, and the schema already describes eventId as 'Avanan event ID.' The description repeats this concept ('by its Avanan event ID') without adding format, constraints, or source guidance. This matches the baseline of 3 where the schema does the heavy lifting.

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 full details'), a clear resource ('one security event'), and the lookup key ('Avanan event ID'). It clearly distinguishes this from sibling tools like avanan_query_events, which imply searching or listing events rather than retrieving a single event by ID.

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

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

The description implies the tool should be used when you already have a specific Avanan event ID and need full details, but it does not explicitly state when not to use it or point to alternatives such as avanan_query_events for searching. The usage context is inferable but not explicit.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only says 'Get' without stating that the operation is read-only, what happens if the ID is not found (e.g., null or error), or any authentication/permission requirements. For a simple get, this might be acceptable, but the lack of any explicit behavioral detail is a notable gap.

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

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

The description is a single, efficient sentence with no filler. The core action ('Get one whitelist or blacklist entry') is front-loaded, followed by the key identifier. Every word contributes to clarity.

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

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

For a simple get operation with two fully described parameters, the description is adequate but not complete. It lacks any mention of the return format or error behavior, especially since there is no output schema. An agent might wonder what fields are returned or how failures are signaled, which could affect correct invocation and result 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?

Schema coverage is 100%, so both parameters are already documented with descriptions. The description adds minimal value—only rephrasing 'excId' as 'entity ID'—which is redundant. Baseline 3 applies because the schema does the heavy lifting and the description doesn't introduce new meaning.

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

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

The description clearly states the verb (Get), the resource (one whitelist or blacklist entry), and the identifier (entity ID). It distinguishes itself from sibling tools like list_exceptions, add_exception, update_exception, and delete_exception by focusing on a single entry 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?

The description implies its usage—retrieve a specific entry when you know its ID—which contrasts with list_exceptions for all entries. However, it does not explicitly state when to prefer this over alternatives, nor does it mention exclusions or conditions. The context is clear but not fully defined.

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 disclosure burden. It usefully discloses the return shape and scope, but it does not mention pagination behavior, potential data volume, access requirements, or explicitly confirm read-only behavior beyond the 'Get' verb.

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

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

Two concise sentences with no filler. The verb and resource are front-loaded, and the return detail is provided in a single clarifying second sentence.

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

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

The core invocation semantics and return fields are described, and optional parameters/pagination are covered by the schema. With no output schema and no annotations, it would benefit from a note on read-only behavior or data volume, but it is adequate for correct basic invocation.

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

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

All four parameters already have schema descriptions, so the baseline is 3. The description does not add parameter-level detail, but the schema fully documents year, month, msp_ids, and scrollId, so no compensation is needed.

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

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

The description names a specific verb (get), a clear resource (monthly usage details), and a precise scope (all customer tenants for a given year/month). It also states the return granularity (per-day, per-tenant rows), which helps differentiate it from the sibling get_daily_usage.

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

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

The description explains what the tool does but gives no guidance on when to choose it over get_daily_usage or when to set msp_ids. There are no exclusions, prerequisites, or alternative routing hints.

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. 'Get' conveys a read-only, non-destructive operation, but the description does not disclose potential error behavior, required permissions, or response characteristics. This is adequate for a simple lookup but not especially rich.

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

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

The description is a single, direct sentence with no filler or redundancy. It front-loads the action and resource, and every word contributes to understanding the tool's purpose.

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

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

This is a simple, one-parameter tool with no output schema, no enums, and no nested objects. The description plus schema provide enough information for an agent to invoke the tool correctly. The only minor gap is the lack of an explicit statement about return value or not-found behavior, but the simplicity keeps this from being a major deficiency.

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

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

The schema already documents the single parameter with 100% coverage ('user_id' described as 'MSP user ID.'). The description adds little beyond restating that the fetch is by ID, which is acceptable since the schema carries the semantic weight.

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

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

The description states a specific verb ('Get'), a clear resource ('a single MSP user'), and the lookup criterion ('by ID'). It clearly distinguishes this from sibling tools like avanan_list_msp_users (plural/all) and avanan_update_msp_user (mutation).

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

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

The description implies the appropriate use case: retrieve exactly one MSP user when the ID is known, as opposed to listing all users. It does not explicitly name alternatives or exclusions, but the 'single ... by ID' wording provides clear context for when to invoke this tool.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. 'Check' implies a read-only operation with no side effects, and 'task' implies an asynchronous operation, but the description does not explicitly state that it is non-mutating, nor does it mention polling behavior or potential states. This is adequate but leaves some ambiguity.

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

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

One sentence that fronts the core purpose and immediately explains the key input. Every word earns its place; no redundancy or filler.

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

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

For a simple one-parameter status lookup, the description is essentially complete: it identifies the operation, the input source, and the general intent. The lack of an output schema means possible state values are not specified, but that is not required to invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful provenance by saying the task ID comes from 'an action returned.' This tells the agent where to obtain the value, which the schema's bare 'Task ID' does not convey.

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 ('Check') and resource ('state of a quarantine/restore task') plus the lookup key ('task ID'). It clearly distinguishes itself from sibling action tools like avanan_quarantine_events and avanan_restore_events, since this is the follow-up status check rather than an initiating action.

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

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

The phrase 'by the task ID an action returned' provides clear contextual guidance: this tool is meant to be called after a quarantine/restore action returns a task ID. It doesn't spell out when-not-to-use or name alternatives, but no sibling tool competes for the same status-check role, so explicit exclusions are unnecessary.

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 behavioral disclosure burden. It clearly conveys a read-style operation via 'Get' and lists returned fields, but it does not explicitly state non-mutating behavior, error handling, or not-found behavior. Basic transparency, but not detailed.

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, focused sentence states the operation, the scope, and the useful output fields. There is no filler, and the key information 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 simple single-parameter getter, the description adequately covers what data the agent can expect by listing license, dates, user count, and expiration. Minor gaps such as not-found behavior and authorization requirements prevent a perfect score, but nothing critical is missing for basic invocation.

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

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

Schema description coverage is 100%, and the parameter already has a clear type and description. The description's 'by ID' adds no new semantic meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Get details of a single customer tenant by ID.' It also names the key data fields returned, making it easy to distinguish this from sibling tools like avanan_list_tenants or avanan_get_msp_user.

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

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

The description implies use when a specific tenant_id is known and details are needed, but it does not explicitly say when not to use it or mention alternatives such as avanan_list_tenants for enumeration. The context is clear but not prescriptive.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It clearly indicates this is a read-only listing operation and reveals the return fields (id, name). It could add pagination or permission details, but for a zero-parameter list endpoint the disclosure 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?

The description is two sentences with no filler. The main action and result are front-loaded, and the second sentence adds a meaningful usage hint without redundancy.

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

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

For a simple, parameterless list tool with no output schema, the description is complete: it names what is returned and explains why the IDs matter. No critical information needed to invoke the tool correctly is missing.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no unnecessary parameter information and correctly implies that no inputs are required to list all add-ons.

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'), names the exact resource ('all available license add-ons'), and states the output fields (id, name). It also connects the purpose to the sibling assign_license workflow, making the tool's role clear even without explicit sibling differentiation.

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

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

The description implies when to use this tool: before assigning a license, to obtain add-on IDs. It does not explicitly list alternatives or when-not-to-use, but the stated relationship to license assignment provides sufficient contextual guidance.

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

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

The verb 'List' makes the read-only, enumerating nature clear and the whitelist/blacklist qualifier defines the scope. However, with no annotations, the description carries full burden and does not disclose return shape, pagination, or any authentication expectations.

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 packs the action, resource, and the two list types with no filler. Every word earns its place.

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

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

For a one-parameter, no-output-schema list operation, this description is largely complete: the action and the parameter are clear, and the schema fully documents excType. It could be improved by stating what the returned exception entries look like, but nothing needed for invocation is omitted.

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

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

Schema coverage is 100% and the excType parameter is fully described with an enum. The description's 'whitelist or blacklist exception entries' essentially restates the schema, so it adds no new parameter semantics beyond the baseline.

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

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

The description states a specific action ('List') and an exact resource ('whitelist or blacklist exception entries'), which matches the required excType parameter. This clearly separates it from the singular get_exception and mutating add/update/delete_exception 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?

There is no explicit guidance on when to use this tool instead of get_exception, add_exception, or the other exception tools. The only signal is the word 'List', which implies enumeration but leaves the agent to infer routing from sibling names.

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

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

With no annotations provided, the description must independently convey behavior. The verb 'List' and 'all available' imply a read-only, complete enumeration, and the field list gives the agent a concrete idea of what the response will contain. It does not discuss pagination or rate limits, but for a likely small set of license packages this is not a major 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?

Two short sentences convey the operation, output fields, and a downstream usage tip. Every word earns its place, and the core action 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?

Given zero parameters, no output schema, and no annotations, the description is complete for a simple list tool. It states the resource, the returned fields, and how to use one of them, leaving no critical unknown for invoking the tool correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics; it instead adds value by describing what the returned data contains and how to use one field.

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

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

The description clearly states a specific verb ('List'), a specific resource ('license packages'), and the returned fields ('id, codeName, displayName'). It is unambiguous, but it does not explicitly differentiate from the sibling 'avanan_list_addons', which could be confused for a similar listing tool.

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

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

The description gives actionable usage context: 'Use the codeName when assigning a license to a tenant.' This tells the agent how to apply the returned data downstream. It does not mention alternatives or state when not to use this tool, but for a straightforward list operation the context is clear.

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

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

No annotations provided, so description bears full burden. It states behavior (list all child MSPs) and output (id and name). Does not disclose permissions, rate limits, or side effects. Adequate but not detailed.

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 sentences, no filler. Action verb first, scope and return value clearly stated. Highly efficient.

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

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

Describes scope ('under current MSP') and return content ('id and name per child MSP'). Lacks pagination or limit info, but for a list tool, it's sufficient. No output schema, so description covers essentials well.

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?

Input schema has zero parameters with 100% coverage. The description adds value by specifying the return format (id and name), compensating for lack of output schema. No need for param details.

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' targeting 'all associated child MSP partners', clearly distinguishing from sibling tools that list other entities (licenses, users, tenants). The resource and scope are 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?

No explicit guidance on when to use this tool versus alternatives. However, given it's a straightforward list with no parameters, the context is clear. Lacks exclusions or criteria for 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?

No annotations are present, so the description carries the full burden. It only states 'List all MSP users,' which implies a read-only operation but discloses nothing about pagination (scrollId), optional filtering (MSPId), or any permissions or side effects. This is a significant gap for a tool with these parameters.

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

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

The description is a single sentence with no wasted words, which is efficient. However, it is so brief that it sacrifices useful context, making it less effective than a slightly longer but more 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?

For a list operation with optional pagination and filtering, and without an output schema or annotations, the description is incomplete. It does not explain the scrollId pagination mechanism, the MSPId filtering behavior, or any expected return format, leaving an agent without enough information to call it correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description adds no additional meaning or context about how these parameters are used together (e.g., that MSPId restricts to child MSP users). Baseline 3 is appropriate.

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

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

The description states a specific verb ('List') and resource ('MSP users'), making the core purpose clear. However, it does not differentiate from sibling tools like get_msp_user or list_msp_partners, which is a minor gap given that resource names are self-explanatory.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention any conditions, such as whether to use this for bulk listing vs get_msp_user for a single user, or any prerequisites or restrictions (e.g., parent vs child MSP).

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 behavior disclosure itself: it is a read-only listing, and it explains how scope count differs by key type (one for customer keys, one per managed tenant for MSP keys). It doesn't mention error cases or response shape, but for a list 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 tightly written sentences; the key statement is front-loaded and every clause adds meaning. No fluff or schema repetition.

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

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

For a zero-parameter, list-style tool it is reasonably complete: no inputs to documentaineagu, and it explains cardinality and downstream usability. It leaves the exact output items unspecified, but the output schema is also absent, so the description provides most of what an agent needs.

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 zero parameters, so the baseline is 4. The description adds semantic context by defining what a scope is and how the scopes relate to downstream event/search/action tools.

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

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

States a specific verb and resource ('List the farm:tenant scopes'), and immediately distinguishes this from sibling tools by clarifying it returns query scopes, not tenants or partners. The customer-tenant vs MSP distinction removes ambiguity about what an agent will get.

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

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

The description explains that scopes are what the key can query and that they feed into the event, search and action tools, which tells an agent when to call this tool. It doesn't explicitly name alternative tools or say 'use this before other queries,' but the context is clear enough.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation, and the description states what each entry includes, but it does not explicitly confirm it is non-destructive, nor does it mention pagination behavior (though scrollId is in the schema). The missing explicit safety and pagination context prevents a higher score.

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 well-structured sentence that front-loads the core action and scope, then lists the included fields. Every word contributes meaning with no redundancy or filler.

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

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

For a simple list operation with two optional parameters and no output schema, the description sufficiently covers what the tool does and what the response contains. It omits an explicit note on pagination flow or the optionality of MSPId, but those are documented in the schema. Overall, it is nearly complete for an agent to call 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 schema fully documents both parameters (MSPId and scrollId), so the baseline is 3. The description adds no detail about parameter usage, such as that MSPId is optional and only for parent MSPs, or how scrollId relates to pagination. Since schema coverage is 100%, a 3 is appropriate.

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

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

The description specifies a clear action ('List') and resource ('all customer tenants') with an explicit scope ('associated with the current MSP'). It also enumerates the fields returned, which helps differentiate it from sibling tools like get_tenant (singular) and list_msp_partners (different resource).

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 makes the primary use case obvious: retrieving all tenants for the current MSP. However, it does not explicitly mention alternatives (e.g., when to use get_tenant for a specific tenant) or any negative conditions. The context of a list operation is clear enough for an agent to infer, but the lack of explicit routing guidance keeps it from 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?

Beyond the annotations, the description adds crucial behavioral context: the operation is reversible via avanan_restore_emails, it returns task IDs, and it requires user confirmation. This materially helps an agent understand consequences and follow-up actions.

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 four short, purposeful clauses: impact warning, action, reversibility, output, and confirmation requirement. Every sentence earns its place and the most important caution 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 simple quarantine tool with no output schema, the description covers the action, impact, return value, reversal path, and user-confirmation requirement. An agent has enough context to invoke it correctly and know what to expect.

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

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

The input schema already describes all three parameters with 100% coverage, so the description gets the baseline 3. It reinforces that entityIds identify the entities to quarantine, but it does not add new parameter-level detail beyond the schema.

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

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

The description states a specific verb ('quarantine'), a clear resource ('secured entities (emails)'), and the selection mechanism ('by entity ID'). This distinguishes it from sibling tools like avanan_quarantine_events and avanan_restore_emails without needing to inspect schemas.

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

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

It clearly signals high impact and mandates user confirmation, and it names avanan_restore_emails as the reversal path. It does not explicitly forbid use in favor of avanan_quarantine_events, but the email-vs-event resource distinction is evident enough for an agent to route correctly.

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

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

Annotations already mark destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context beyond that: the operation is high impact, reversible, returns task IDs, and requires user confirmation. No contradiction with annotations is present.

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

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

Every sentence earns its place: the impact warning is front-loaded, the action is explicit, reversibility is stated, output is described, and the confirmation requirement is included. No filler or redundancy.

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

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

For a destructive operation with no output schema, the description covers the essentials: impact, reversibility, return type, and required user confirmation. It could be slightly more complete by explicitly distinguishing from avanan_quarantine_emails, but the core guidance is sufficient.

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

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

Schema description coverage is 100%, so the schema already documents both scope and eventIds. The description adds no parameter-level detail, but with full schema coverage this is acceptable and meets the baseline.

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

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

The description states a specific verb and resource: 'quarantine the emails behind one or more security events.' It clearly distinguishes the tool from restore-focused siblings by emphasizing that the action is driven by security event IDs and is reversible.

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

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

The description gives clear context: use when quarantining emails linked to security events, confirms reversibility via avanan_restore_events, and explicitly instructs the agent to confirm with the user before invoking. It does not explicitly contrast with sibling avanan_quarantine_emails, which is a minor gap.

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 does disclose that the tool returns each event's available remediation actions, and the verb 'Query' implies a non-destructive read. However, it says nothing about pagination (scrollId), default time windows, auth/MSP restrictions, or result-volume behavior, which are significant for an 11-parameter query 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?

Two sentences with no filler: the first sentence front-loads the verb and resource ('Query Avanan security events'), the parenthetical lists the event domains, and the second sentence covers filtering capability and return value. Every clause carries information.

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

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

Given no output schema and no annotations, the description conveys the high-level intent well but omits operational context that an agent would need: pagination behavior, default time frame, the MSP-only scopes caveat, and the shape of the returned remediation actions. With 11 optional parameters, a bit more operational guidance would make the tool self-contained 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?

Schema description coverage is 100%, so the baseline is 3. The description mainly re-summarizes filter dimensions already documented per-parameter (type, severity, SaaS, date range, description text) rather than adding new meaning; its only added contribution is that the result set includes available remediation actions.

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

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

The description clearly identifies the operation as querying Avanan security events and enumerates the domains (phishing, malware, DLP, anomaly, shadow IT, malicious URL), so an agent understands the resource and scope. However, it does not explicitly differentiate this from the sibling avanan_get_event, which is the closely related single-event retrieval tool; the distinction is only implied by the filtering language.

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

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

The description conveys a clear usage context: query security events using the listed filter dimensions and receive remediation actions for each. But it gives no explicit routing guidance — no 'use avanan_get_event for one event' or 'use avanan_search_emails for email-level search' — so an agent must infer when this tool is preferable to its siblings.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the operation returns task IDs, which hints at async behavior, and that it restores entities. However, it does not mention any permissions, reversibility, side effects, or what happens if an entity is not quarantined. The 'returns task IDs' is useful but incomplete for a mutating tool without annotation support.

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

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

The description is a single sentence of 14 words, front-loading the verb and object. It conveys purpose and output without any fluff, making it highly efficient and 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?

For a simple tool that takes entity IDs and returns task IDs, the description covers the core aspects: what it does, the input type, and the output. It omits explicit mention of async behavior or checking task status, but the 'returns task IDs' hints at it. Given no output schema and no annotations, the description is reasonably complete, though a mention of the async nature would strengthen it.

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

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

Schema description coverage is 100%, so the schema already explains all parameters. The description adds the context that entities are 'quarantined' and implies the entityIds are the primary parameter, but it does not elaborate beyond the schema. It adds some value by clarifying the object type but does not compensate for any missing schema info, given coverage is high.

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 ('Restore'), a resource ('quarantined entities (emails)'), and the method ('by entity ID'). This clearly distinguishes it from sibling tools like avanan_restore_events (which restores events) and avanan_quarantine_emails (which quarantines). The tool name and description align perfectly.

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

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

The description implies when to use this tool (when restoring quarantined emails) but does not explicitly reference alternatives or conditions. It does not say 'for events, use avanan_restore_events' or mention any prerequisites like MSP scope. The context is clear enough from the word 'emails', but the guidance is implicit 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the operation mutates quarantined emails and returns task IDs, which hints at asynchrony, but it doesn't connect this to avanan_get_task_status, nor mention permissions, reversibility, or side effects. This is a meaningful but incomplete behavioral disclosure.

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

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

Two short sentences with no filler; the core action and return value are front-loaded. The phrase 'previously quarantined' is necessary context rather than redundancy.

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

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

For a two-parameter tool with a complete schema, the description is close to adequate, but it omits the follow-up contract: the return of task IDs implies a task lifecycle, and an agent isn't told to monitor via avanan_get_task_status. It also doesn't distinguish from the closely related avanan_restore_emails, leaving selection ambiguity.

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

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

The input schema covers 100% of parameters, so the schema already documents eventIds and scope. The description adds that eventIds refer to security events, but doesn't clarify how scope is used or how multiple event IDs combine.

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 ('Restore') and identifies the resource ('previously quarantined emails behind one or more security events'), making the tool's purpose unambiguous. It stops short of explicitly differentiating from avanan_restore_emails or avanan_quarantine_events, so it doesn't earn the top score.

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

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

No when-to-use or exclusion guidance is given; there is no mention of when to prefer this over avanan_restore_emails or how it relates to avanan_quarantine_events. An agent must infer the use case from the tool name and the single line.

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 does not mention that this is a read-only search, what the response contains, whether results are paginated, or any limitations. 'Search' implies reading but does not explicitly disclose behavior.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently communicates the core action, resource scope, and optional filters in a compact form.

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 leaves out what the search returns, pagination behavior, and when to prefer this over sibling search/query tools. The schema covers parameters, but the overall calling context is incomplete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's mention of platform, date range, and filters aligns with schema properties but adds no deeper semantics beyond what the schema already provides.

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 ('Search') and a resource ('secured entities (emails and SaaS objects)') with platform, date range, and filters. It is distinguishable from get/list siblings by its broad search semantics, though 'secured entities' is slightly generic.

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 instead of related tools like avanan_query_events or avanan_get_email. There are no alternatives, exclusions, or contextual triggers described.

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 do the heavy lifting. It transparently lists the three main behavioral steps: auth handshake, scope listing, and MSP endpoint probe. This goes far beyond a generic 'test connection' and clearly implies a read-only verification process, although it doesn't explicitly state there are no side effects or describe failure modes.

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

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

The description is two compact sentences. The first states the primary purpose and specific sub-steps, the second gives the practical usage rule. No fluff, front-loaded with the action, and every sentence contributes value.

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 'test connection' tool with no output schema, the description is complete. It covers what the tool does (auth check, scope check, MSP-scope probe), and why to call it (first diagnostic step on 403). An agent has everything needed to invoke and interpret the tool's general purpose.

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

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

The tool has zero parameters, so parameter semantics are moot. The schema is 100% covered (empty object), and the baseline for 0 params is 4. The description adds no parameter information because none is required.

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

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

The description clearly states the tool's specific action: verifying configured Avanan credentials through an auth handshake, listing key scopes, and probing an MSP endpoint to confirm MSP-scoped access. It distinguishes itself from sibling tools by explicitly targeting the connection/credential check and providing a concrete trigger (MSP tools returning 403).

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

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

It provides an explicit usage trigger: 'Run this first when MSP tools return 403,' which tells the agent exactly when to invoke it as a diagnostic step. However, it does not mention when not to use this tool or name alternative sibling tools, so it's not fully explicit on when-to-use vs. alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only indicates that an update occurs; it does not disclose whether this is a partial update or full replacement, what happens to unspecified fields, error behavior, or response details. This is a significant gap for a mutation tool.

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

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

A single sentence with no filler, front-loaded with the core action and target. 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 22-parameter mutation tool with no annotations and no output schema, this description is far too minimal. It does not explain update semantics, the role of optional parameters, whether existing values are overwritten or merged, or what response to expect. An agent would need to infer too much.

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 73%, so the schema does most of the parameter documentation work. The description only restates the concept of whitelist/blacklist and entity ID, adding no meaning beyond the schema. It also does not compensate for the several parameters that lack schema descriptions, such as the matching-mode 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 specific verb ('Update'), a precise resource ('existing whitelist or blacklist entry'), and the key identifier ('entity ID'). It clearly distinguishes this tool from siblings like add_exception, delete_exception, get_exception, and list_exceptions.

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: use it when you have an existing exception ID and want to modify that entry. However, it does not explicitly name alternatives or state when not to use it, so the 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It correctly signals that this is a mutation and notes that all fields are required, but it does not describe side effects, authorization requirements, overwrite behavior, idempotency, or what happens on failure. For a full-object update this is a significant transparency gap.

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

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

The description is two short sentences with no filler. The core action and key constraint ('all fields are required') are front-loaded and every word earns its place.

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

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

Despite the high complexity (10 required parameters, no annotations, and no output schema), the description provides only the mutation intent and the all-fields-required constraint. It omits guidance on fetching current values before updating, handling partial updates, response expectations, and distinguishing this from create_msp_user. The description is not sufficient for confident use beyond the schema.

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

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

The input schema already describes all 10 parameters with 100% coverage, so the baseline is 3. The description adds no parameter-level detail beyond restating that all fields are required, which is already encoded in the schema's required array.

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 ('Update'), a specific resource ('MSP user'), and the identifying key ('by ID'), which clearly differentiates it from sibling tools like create/get/list/delete MSP user. The purpose is immediately 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 tool's purpose implies it should be used to modify an existing MSP user rather than create or delete one, but the description does not explicitly say when to choose this over alternatives or mention any exclusions, such as needing an existing user ID. This is implied usage rather than explicit guidance.

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