Server Quality Checklist

Tool Scores

• avanan_create_msp_userC
  2.9/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full behavioral disclosure burden. It only states that a new MSP user is created, which implies mutation, but says nothing about required permissions, side effects, idempotency, or response behavior.

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

  Conciseness4/5

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

  The description is one short, front-loaded sentence with no filler. It is appropriately concise, though slightly oversimplified given the nine-parameter input schema.

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

  Completeness3/5

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

  For a simple create action, the description plus a fully described input schema provides a workable basis for invocation. However, with no annotations and no output schema, it omits behavioral context such as permission requirements or return value, leaving some ambiguity.

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

  Parameters3/5

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

  Schema description coverage is 100%, with every parameter described, including a role enum. The description adds no parameter meaning beyond the schema, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description states a specific action and resource: 'Create a new MSP user.' This clearly identifies what the tool does. It does not explicitly differentiate from sibling tools like avanan_update_msp_user, but the create/update distinction is obvious.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as avanan_update_msp_user or avanan_create_msp_partner. There are no prerequisites, exclusions, or contextual conditions. Usage is only implied by the verb 'create'.

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

• avanan_list_msp_usersC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full behavioral burden, but it only says 'List all MSP users.' It does not disclose that results are paginated or that scrollId must be used to retrieve subsequent pages; the schema hints at this, but the description itself does not.

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

  Conciseness4/5

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

  The description is a single focused sentence with no filler words. It is front-loaded and easy to parse, though it is minimal enough that some behavioral context is omitted.

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

  Completeness3/5

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

  For a simple list tool with one optional parameter, the description and schema together are minimally sufficient to make a first call. However, with no output schema and no mention of how scrollId is returned or used, an agent still has to infer the response structure and pagination flow.

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

  Parameters3/5

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

  The only parameter, scrollId, is fully described in the schema as 'Pagination scroll ID from a previous response,' so schema coverage is 100%. The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

  Purpose4/5

  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'), and 'all' clarifies the scope. It is differentiated from single-user retrieval by the resource name, though it does not explicitly contrast with sibling list tools like avanan_list_msp_partners.

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

  Usage Guidelines2/5

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

  No guidance is given about when to use this tool versus alternatives. There is no mention of preferring get_msp_user for a single user, or using pagination via scrollId for large result sets.

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

• avanan_create_tenantB
  3.1/5.0
  Behavior2/5

  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 conveys only that a tenant gets created, but does not state side effects (e.g., provisioning, invitation emails, billing implications), permission requirements, duplicate-handling behavior, or what happens on failure. For a mutation operation with zero annotation coverage, this is a significant gap.

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

  Conciseness4/5

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

  The description is a single ten-word sentence with the verb and resource front-loaded and zero wasted words. It is efficient, though it errs on the side of being terse given the tool's complexity.

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

  Completeness2/5

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

  For a create operation with 6 required parameters, no annotations, and no output schema, the description is under-sized. It omits return behavior, post-creation outcomes, and operational prerequisites. The schema richly documents parameters, but the behavioral context needed to invoke this tool confidently is missing.

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

  Parameters3/5

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

  Schema description coverage is 100% — all six parameters have descriptive text, including format hints ('10 digits', 'lowercase') and the enum for tenantRegion. Per the rubric, the high coverage sets a baseline of 3; the description itself adds no parameter-level meaning, but it does not need to since the schema already handles it.

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

  Purpose5/5

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

  The description names a specific verb ('Create'), a specific resource ('customer tenant'), and a scope ('under the current MSP'). This clearly distinguishes it from sibling creation tools such as avanavan_create_msp_partner and avanavan_create_msp_user, and an agent can tell them apart without opening any schema.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives. It does not mention prerequisites (e.g., whether an MSP partner must exist first), nor does it contrast itself with sibling creation tools like create_msp_partner or create_msp_user. The agent is left to infer the appropriate context.

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

• avanan_assign_licenseB
  3.3/5.0
  Behavior2/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• avanan_update_msp_userB
  3.4/5.0
  Behavior2/5

  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.

  Conciseness5/5

  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.

  Completeness2/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• avanan_delete_msp_userA
  3.5/5.0
  Behavior2/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• avanan_get_tenantA
  3.8/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• avanan_create_msp_partnerA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the parent-child relationship ('child' and 'under the current MSP'), which adds meaningful context, but it does not mention side effects, permissions, idempotency, or uniqueness constraints that might affect usage.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence focusing on the verb and resource with zero fluff or unnecessary detail.

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

  Completeness3/5

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

  For a one-parameter tool with no output schema and no annotations, the description covers the core action and scope. Yet it omits any guidance on preconditions or resulting state, which would be useful for a create operation.

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

  Parameters3/5

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

  Schema description coverage is 100%: the 'name' property already has a description. The tool description adds no further meaning about the parameter or its format, 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.

  Purpose5/5

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

  The description uses the specific verb 'Create' with a clear resource ('new child MSP partner') and scope ('under the current MSP'). This distinguishes it unambiguously from sibling tools like avanan_create_msp_user and avanan_create_tenant.

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

  Usage Guidelines4/5

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

  The description makes clearthe context: it creates a child partner under the current MSP, which implicitly tells an agent when to use this tool instead of creating users or tenants. However, it does not explicitly mention alternatives or exclusion conditions.

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

• avanan_get_daily_usageA
  3.9/5.0
  Behavior3/5

  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 context. It discloses that this is a read operation and that it spans all customer tenants for a given date, but it does not mention return format, pagination, aggregation, or access caveats.

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

  Conciseness5/5

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

  One front-loaded sentence with no filler; every word adds meaning: 'daily', 'across all customer tenants', and 'specific year/month/day'.

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

  Completeness3/5

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

  For a simple date-keyed read, the essential invocation data is present and the daily vs monthly distinction is implicit. However, no output schema exists and the description does not characterize the returned usage details, pagination, or tenant-level versus aggregate shape.

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

  Parameters3/5

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

  The schema already documents all three parameters at 100% coverage, so the description does not need to repeat them. 'Specific year/month/day' only restates the fields without adding format, relationship, or behavior details.

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

  Purpose5/5

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

  States a specific verb 'Get', a definite resource 'daily usage details across all customer tenants', and a date parameter. The word 'daily' distinguishes it from the sibling avanan_get_monthly_usage.

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

  Usage Guidelines4/5

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

  The phrase 'for a specific year/month/day' and 'daily' clearly signal when to call this tool. It does not explicitly name alternatives like get_monthly_usage or state when not to use it, but the daily vs monthly contrast is clear enough.

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

• avanan_delete_msp_partnerA
  4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• avanan_delete_tenantA
  4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• avanan_get_msp_userA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• avanan_list_msp_partnersA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• avanan_list_tenantsA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It implies a read-only list operation and describes the output fields, but it does not disclose pagination behavior, authentication requirements, or how scrollId from a previous response should be used beyond what the schema states.

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

  Conciseness5/5

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

  Two concise sentences: the first states the action and scope, and the second lists the returned entry fields. There is no redundant or filler content.

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

  Completeness4/5

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

  For a low-complexity list tool with one optional pagination parameter and no output schema, the description is mostly complete: it explains scope and enumerates response fields. It could optionally mention that results are paginated or that more pages can be retrieved using scrollId, but the schema already covers the parameter.

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

  Parameters3/5

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

  Schema description coverage is 100% for the single optional scrollId parameter, and the schema already explains it as a 'Pagination scroll ID from a previous response.' The tool description adds no additional meaning to the parameter, so the baseline score applies.

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

  Purpose5/5

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

  States a specific verb and resource: 'List all customer tenants associated with the current MSP.' It is clearly distinct from sibling tools like avanan_get_tenant (single tenant), avanan_list_msp_partners (partners), and avanan_list_msp_users (users).

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

  Usage Guidelines4/5

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

  The phrase 'List all customer tenants' provides clear context for when to use this tool: enumerating tenants under the current MSP. It does not explicitly exclude alternatives such as avanan_get_tenant for single-tenant lookups, but the 'all' wording makes the intended use reasonably clear.

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

• avanan_get_monthly_usageA
  4.2/5.0
  Behavior4/5

  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 discloses the output structure ('per-day, per-tenant rows with user count, daily price, and cost') and the verb 'Get' implies a read-only operation. It does not explicitly state side effects, but for a retrieval 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.

  Conciseness5/5

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

  The description is a single, tightly structured sentence that front-loads the purpose and then summarizes the output. There is zero wasted wording, and every phrase adds value.

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

  Completeness4/5

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

  Given the absence of an output schema, the description adequately describes the return rows and their fields, and it states the scope across all tenants. It does not mention pagination, error conditions, or rate limits, but for a simple two-parameter retrieval tool this is reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents the 'year' and 'month' parameters. The description adds no extra semantics for the parameters themselves; it only reinforces that they specify a month. The baseline of 3 applies because the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states a specific verb ('Get'), a distinct resource ('monthly usage details across all customer tenants for a given year/month'), and the return format. This unambiguously distinguishes it from the sibling tool 'avanan_get_daily_usage' by the 'monthly' vs 'daily' scope.

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

  Usage Guidelines4/5

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

  The description provides clear context that this tool retrieves monthly usage data across all tenants, which implies its use case for monthly reporting. However, it does not explicitly contrast with avanan_get_daily_usage or state when to use one over the other, so it lacks explicit alternative guidance.

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

• avanan_list_licensesA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines4/5

  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.

• avanan_list_addonsA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.