Server Quality Checklist

Tool Scores

• get_usageC
  2.9/5.0
  Behavior2/5

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

  The 'Get' wording is consistent with readOnlyHint=true and there is no contradiction. However, the description adds no behavioral detail beyond that, such as pagination behavior, units, billing-cycle context, or what the response represents.

  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, direct sentence with no wasted words. It is concise and front-loaded, though its brevity leaves some semantic gaps.

  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 read-only tool with two fully documented optional parameters, the description is nearly sufficient. However, it does not clarify what 'data usage' refers to (current cycle, aggregate, or billable amount), and the presence of get_usage_history makes the distinction ambiguous.

  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 both page and limit fully described including defaults and constraints. The description does not add parameter-level meaning, but the schema already carries the burden adequately.

  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 clear verb and resource: 'Get data usage for the subscriber.' It is specific enough to identify the tool, though it does not explicitly distinguish it from the similarly named sibling get_usage_history.

  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 like get_usage_history, get_dashboard, or get_account. No conditions, exclusions, or context for selection are given.

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

• get_plansB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals a safe read operation, and the description's 'List' phrasing is consistent. Beyond that, the description adds little behavioral context such as pagination behavior or whether plans are currently active, but given the annotation coverage, this is acceptable.

  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 with no wasted words. It states the essential purpose immediately and omits filler.

  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 paginated list tool with annotations and complete schema coverage, the description is minimally sufficient. However, the lack of any differentiation from sibling plan-related tools leaves a real ambiguity that an agent must resolve by inspecting other definitions.

  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 both parameters (page, limit) already include meaningful descriptions. The tool description adds no additional meaning about these parameters, so it lands at the baseline of 3.

  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 the action ('List') and the resource ('available plans/packages'), making the tool's purpose understandable at a glance. However, it does not differentiate this from sibling tools such as get_upgrade_plans or get_renewal_plan, so it falls short of a 5.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus any of its many siblings, especially the similarly named get_upgrade_plans and get_renewal_plan. The description implies a general list operation but provides no context or exclusions to help an agent select it confidently.

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

• get_dashboardB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description's 'Get' is consistent. The description adds the scope 'current subscriber' and indicates the result is an overview rather than detailed records, but it does not disclose response shape, aggregate behavior, or whether any context/auth is required.

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

  Conciseness5/5

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

  One short sentence, front-loaded with the verb, with no filler or redundancy. It is appropriately economical for a zero-parameter read-only tool.

  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 zero-parameter read-only tool, callability is clear. However, 'overview stats' is vague and there is no output schema, so the agent does not know which metrics are included or what the response will contain. This is adequate but leaves meaningful gaps.

  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 input schema has zero parameters, so schema coverage is 100% and there are no parameters to document. The baseline for zero parameters is 4, and the phrase 'current subscriber' usefully suggests that no parameter input is needed because the context is inferred.

  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 uses a specific verb ('Get') and names a concrete resource ('dashboard overview stats') with a scope ('current subscriber'). It is clear on its own, though it does not explicitly differentiate itself from sibling get_* tools like get_usage or get_account.

  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 gives no guidance on when to use this tool versus alternatives such as get_usage, get_account, or get_usage_history. It implies a use case through the name and object, but states no exclusions, prerequisites, or conditions.

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

• get_lost_daysB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint=true annotation already declares that this is a safe read operation, so the safety burden is covered by structured data. The description adds semantic context that 'lost days' are 'downtime compensation credits,' which is helpful and consistent with the annotation. It does not disclose pagination defaults or what fields are returned, but these are minor given the annotation coverage.

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

  Conciseness5/5

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

  A single sentence that immediately conveys the resource and scope, with the clarifying parenthetical front-loaded. No unnecessary words or repetitions. It is an efficient, well-structured description for a simple list tool.

  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 list tool with no required parameters and full schema coverage for pagination, the description conveys the core purpose and defines the domain term ('downtime compensation credits'). It does not mention return-value structure, but there is no output schema, and an agent can likely infer a list of lost-day records. The main missing piece is usage guidance, which is already penalized in that dimension.

  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 both parameters (page, limit) already have clear descriptions in the schema. The tool description adds no additional meaning about the parameters, so the baseline 3 applies. An agent can correctly set pagination values from the schema alone.

  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'), a specific resource ('lost days'), and clarifies that these are 'downtime compensation credits' for the account. This resource is unique among the sibling tool names, so an agent can distinguish it without opening the schema. It does not explicitly contrast it with similar tools like get_usage_history or get_outage_tickets, so it misses the top differentiation score.

  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 gives no guidance on when to use this tool versus alternatives, and no exclusions or prerequisites. It only implies account-level scope with 'for the account.' Siblings like get_outage_tickets or get_usage_history might be related, but the description does not point the agent toward or away from any of them.

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

• get_outage_ticketsB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals a safe read operation, and the description's 'List' action is consistent with that. The description adds only the account scope and does not disclose additional behavioral traits such as pagination behavior, filtering, or return format. With annotations present, the safety profile is covered, so this is adequate but not 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, front-loaded sentence with no wasted words. It conveys the essential purpose efficiently without redundancy.

  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 paginated list with a readOnly annotation and well-documented parameters, the description is nearly complete. It lacks any detail about ticket fields or response structure, but since no output schema exists and the tool is straightforward, the minimal description plus schema is sufficient.

  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 page and limit with defaults and bounds. The description adds no meaning beyond the schema, 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 and resource: 'List outage tickets for the account.' It clearly identifies the operation as a list of outage tickets scoped to the account. It does not explicitly differentiate from siblings like get_ticket or create_outage_ticket, though the plural 'List' implies a collection operation.

  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 provided on when to use this tool versus alternatives. The description does not mention the singular get_ticket or any criteria for choosing this tool, nor does it state any exclusions or prerequisites. Usage is only implied by the action 'List'.

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

• get_transactionsB
  3.4/5.0
  Behavior3/5

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

  Annotations already signal readOnlyHint=true, and the description adds the useful ordering trait ('most recent first'). It does not disclose pagination or return shape, but for a read-only list tool the annotation covers the safety burden.

  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 compact sentence with zero filler words; the core action and ordering are stated clearly and immediately.

  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, read-only list endpoint with two self-explanatory pagination parameters and high schema coverage, the description is nearly complete. It doesn't describe the output structure, but 'list' plus the resource name sufficiently implies the return value.

  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 covers both parameters (page, limit) with types, defaults, ranges, and descriptions at 100% coverage. The description adds no parameter-specific meaning, so the schema carries the load.

  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 uses a specific verb ('List'), names the resource ('payment transactions'), and specifies ordering ('most recent first'). It is unambiguous on its own, though it doesn't explicitly differentiate itself from siblings such as get_usage_history or get_dashboard.

  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 when-to-use guidance or alternatives are mentioned. An agent must infer appropriate usage purely from the tool name and sibling list.

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

• create_outage_ticketA
  3.5/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 transparency burden. It does disclose a key trait: this tool 'files a real report with FiberOne', signaling a real external side effect. But it does not mention authorization requirements, idempotency, reversibility, or what happens after creation, leaving important behavioral gaps.

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

  Conciseness5/5

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

  Two short, dense sentences with no filler. The core action is front-loaded, and the side-effect warning earns its place immediately after.

  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?

  Adequate for a straightforward creation call: all required parameters are documented in the schema and the real-world side effect is flagged. However, with no output schema or annotations, it omits what the tool returns (e.g., a ticket ID) and gives no guidance on when to prefer it over the ticket-reading sibling tools.

  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 each parameter already has a meaningful description, including the source of category and priorityId. The description adds no extra parameter-level guidance, 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?

  States a clear action and resource: 'Create a new support ticket.' The 'action tool' label and 'files a real report with FiberOne' help distinguish it from the read-only get_* siblings. Minor weakness: the tool name says 'outage' but the description says generic 'support ticket', so the scope is slightly ambiguous.

  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?

  Explicitly frames the tool as an action tool, implying it should be used when the user wants to file a real report rather than query data like the sibling get_* tools. However, it does not state exclusions or point to alternatives such as get_outage_tickets or get_ticket for viewing existing tickets.

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

• get_autorenew_statusA
  3.5/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already establishes the read-only behavior, and the description adds only the component fields of the status, not deeper behavioral details such as how the fields are represented or what the response looks like. There is no contradiction, but the added transparency is modest.

  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 compact sentence with no filler, front-loading the core action and immediately specifying the returned status components.

  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 read-only, zero-parameter status lookup, the description adequately identifies the resource and its expected components. The lack of an output schema means a bit more detail about the value format could help, hence not a 5.

  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?

  There are zero parameters, so the baseline is 4 and the schema already covers everything relevant. The description does not need to explain parameters.

  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 and resource ('Get auto-renew status') and enumerates the status components (agreed, saved card, opt-out state), making the tool's function clear. It does not explicitly contrast itself with related sibling tools like get_renewal_plan or get_pause_status, so it falls short of full 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 Guidelines2/5

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

  No guidance is provided about when to use this tool rather than alternatives. The sibling list contains similar status tools (get_pause_status, get_renewal_plan), and the description gives no conditions, exclusions, or selection criteria.

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

• get_faqsA
  3.5/5.0
  Behavior2/5

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

  The readOnlyHint annotation already covers the safety profile, but the description adds no behavioral context beyond the word 'List'. No mention of ordering, pagination, language, or what an FAQ item contains.

  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, efficient sentence with no filler. Every word contributes to stating the tool's purpose.

  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 read-only getter with no parameters this is minimally adequate, but the absence of an output schema means the description should disclose what the returned FAQ list contains. It does not.

  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, and schema description coverage is trivially 100%. The baseline of 4 applies because there is nothing parameter-related the description needs to clarify.

  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 ('List') and a specific resource ('FiberOne FAQs'). This clearly distinguishes the tool from all sibling getters, none of which target FAQ content.

  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 gives no guidance on when to use get_faqs versus alternatives. There is no mention of context, prerequisites, or situations where another tool should be chosen instead.

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

• get_ticket_categoriesA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, which is consistent with the 'List' verb. The description adds no additional behavioral context beyond the read-only nature, such as pagination, sorting, or scope of results. Since the annotation covers the safety profile, a score of 3 is appropriate – the description is consistent but adds minimal extra value.

  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, precise sentence with no filler. It conveys exactly what the tool does and nothing more, which is ideal for a zero-parameter read operation.

  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 list tool with no parameters and no output schema, the description provides sufficient information: it lists support ticket categories and priorities. It does not specify whether all categories are returned or if there is any filtering, but given the lack of parameters, this is likely all categories. The description is adequate for an agent to invoke 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 per the rubric the baseline is 4. The description does not need to elaborate on parameters. The empty schema covers 100% of parameters, and the description's mention of 'categories and priorities' describes the output, not inputs.

  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 the action ('List') and the resource ('support ticket categories and priorities'), making the purpose obvious. It does not explicitly distinguish from siblings like get_ticket or get_outage_tickets, but the resource is specific enough that an agent can infer it is for categories/priorities, not individual tickets or outage tickets.

  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 provided on when to use this tool versus alternatives. It does not mention that get_ticket retrieves a single ticket or that get_outage_tickets lists outage-specific tickets, leaving the agent 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.

• get_modem_infoA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes this is a safe read operation, and the description is consistent with that ('Get'). No additional behavioral context is provided, such as response shape, pagination behavior, or what subset of devices is returned, so the description adds only the account-scope context beyond the annotation.

  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 with no filler or redundancy. Every word carries meaning: the verb, the resource, and the account scope.

  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 read-only list tool with optional pagination parameters and no output schema, the description states the core resource and scope. It is slightly incomplete because it doesn't describe the return format or the device fields, but an agent can successfully invoke it with no required parameters.

  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 page and limit parameters are already documented in the input schema. The description adds no additional parameter semantics; 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 uses a specific verb and resource ('Get modem/router devices on the account') that clearly differentiates this tool from account/usage/ticket siblings like get_account or get_usage. It stops short of a 5 because it doesn't explicitly state scope or contrast with an alternative, but the resource itself is distinctive enough for selection.

  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?

  There is no explicit when-to-use or when-not-to-use guidance, but the description implies the tool is for retrieving modem/router devices tied to the account. It does not mention any alternatives or exclusions, so the guidance is only 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.

• get_upgrade_plansA
  3.6/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already discloses the read-only nature. The description adds the 'upgrade' context, which is useful, but does not disclose return format, authentication requirements, or any side effects. Since the bar is lower with annotations, this description provides minimal additional behavioral context, warranting a 3.

  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, clear sentence with no redundant words. It is front-loaded with the primary action and object, making it easy to parse. Nothing is wasted.

  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 no-parameter read-only list operation, the description is adequate. However, it does not describe the response structure (since there is no output schema) nor clarify how it differs from get_plans or get_renewal_plan. This could confuse an agent about which tool to invoke, so it is not fully complete.

  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?

  With 0 parameters, the schema already has 100% coverage and no parameters to explain. Per the rubric, baseline for 0 params is 4. The description adds nothing needed for parameters, so this score 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 'List plans the account can upgrade to' clearly identifies the verb (list) and resource (upgrade plans), and distinguishes itself from siblings like get_plans (all plans) and get_renewal_plan (current plan) by focusing on upgrade eligibility. It is specific but does not explicitly name alternatives, so it is not a perfect 5.

  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 for upgrade scenarios but does not explicitly state when to use this tool versus get_plans or get_renewal_plan. There is no exclusion or alternative guidance, so an agent must infer context from the word 'upgrade'. This is adequate but not explicit.

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

• get_accountA
  3.7/5.0
  Behavior4/5

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

  The readOnlyHint annotation already indicates a safe read. The description adds meaningful context by specifying that the data belongs to the logged-in subscriber, implying an authentication prerequisite. It does not contradict the annotation and provides useful behavioral context beyond it.

  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, short sentence with no filler words. The key scope ('logged-in subscriber') is 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.

  Completeness4/5

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

  For a zero-parameter, read-only tool, the description is sufficient to understand what the tool does and when to select it. It does not enumerate the returned account fields, and with no output schema that information is absent, but the core purpose is clear enough for an agent to invoke it correctly.

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

  Parameters4/5

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

  There are zero parameters, so the baseline is 4. The description has no parameter information to add, but none is needed since the input schema is empty and fully self-explanatory.

  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 uses a specific verb ('Get') and a clear resource ('the logged-in subscriber's account details'), which distinguishes it from siblings like get_usage or get_dashboard. The phrase 'logged-in subscriber' adds useful scope, though it doesn't explicitly name alternative sibling tools.

  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 provided about when to use this tool versus alternatives such as get_dashboard or get_usage. The description implies usage when needing the current subscriber's account details, but it does not state exclusions or context for choosing a sibling tool.

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

• get_experience_centresA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, which the description's 'List' verb agrees with. The description adds the output fields (address, city), which gives some behavioral context about the result, but it does not disclose any additional traits such as rate limits, auth requirements, or pagination. Given the annotation covers the main safety profile, the description adds modest value.

  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 with no filler. It states the action, resource, and key output fields in an efficient manner.

  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 parameterless list tool with no output schema, the description gives the essential information: what is listed and what fields are returned. It does not mention pagination or limitations, but these are less critical for such a simple tool. The absence of an output schema makes the explicit field mention valuable.

  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 input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it correctly implies no inputs are required. Schema coverage is 100% trivially, so the description adds no parameter info, but that is acceptable.

  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 action (List) and the resource (FiberOne physical experience centres), and specifies the fields returned (address, city). It is distinct from siblings because it targets a unique resource not covered by other get_* tools.

  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, nor any exclusions or context. It does not mention scenarios where it is appropriate or inappropriate, leaving the agent to infer from the name alone.

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

• get_ticketA
  3.8/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already tells the agent the operation is safe to call; the description adds only that the result includes a message thread, which is a minimal scoping detail. It does not disclose payload size, required authentication, or other behavioral traits beyond what annotations cover.

  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 short sentence with no filler; the purpose ('Get one support ticket with its message thread') is front-loaded. 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 simple read-only getter with one fully documented parameter and a readOnlyHint, the description is nearly sufficient. It names the resource and the included thread, and the schema supplies the id source; however, with no output schema it could say slightly more about the content of the thread, so it stops short of fully 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%: the single required id parameter is described as coming from get_outage_tickets. The tool description itself says nothing about parameters, so it adds no meaning beyond the schema; baseline 3 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?

  The description uses the specific verb 'Get' with the resource 'one support ticket' and adds 'with its message thread', clearly distinguishing this single-ticket fetch from the list operation in sibling get_outage_tickets. It answers what the tool does without unpacking the schema.

  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 does not explicitly state when to prefer this over alternatives like get_outage_tickets or create_outage_ticket. The schema's parameter note ('Ticket id, from get_outage_tickets') implies a follow-up workflow, but the description text itself only implies usage through the word 'one'. It provides no explicit when/when-not guidance.

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

• get_pause_historyA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description is consistent with that annotation and adds the historical scope ('past') as a small behavioral detail, but it does not disclose pagination, ordering, response shape, or other traits. For a zero-parameter read-only tool, this is acceptable but minimal.

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

  Conciseness5/5

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

  The description is a single compact sentence with no filler. Every word — 'List', 'past', 'account', 'pauses' — carries semantic weight and the key scope 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 zero-parameter read-only tool with no output schema, the description sufficiently conveys the operation and scope for basic invocation. However, it does not describe what fields or time range might be returned, nor does it explicitly contrast with get_pause_status, leaving some selection context to inference.

  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 and schema description coverage is trivially 100%, so there is no parameter information the description needs to add. With no parameters, the baseline is 4 and the description correctly includes no parameter 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') and a specific resource ('past account pauses'), and the qualifier 'past' distinguishes it from the sibling get_pause_status, which presumably reports current pause state. This is clear enough for an agent to identify what the tool does and how it differs from related tools.

  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 temporal qualifier 'past' implies this tool is for historical pause data rather than current status, but there is no explicit when-to-use guidance, no exclusions, and no reference to alternatives such as get_pause_status or get_lost_days. Agents must infer usage context from sibling names.

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

• get_pay4me_historyA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the description does not need to restate that this is a read operation. It adds useful semantic context about what pay-for-me requests are but discloses no additional behavioral traits such as response format, pagination, or authorization requirements.

  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 with no wasted words. It communicates the resource and its meaning efficiently.

  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 zero-parameter, read-only list tool, this is nearly complete. It names the resource and clarifies its meaning, though it does not describe what fields or response shape to expect, which is a minor gap given there is no output schema.

  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 schema already fully covers the input surface. The description adds no parameter-specific detail, but none is required; the baseline of 4 for zero-parameter tools 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?

  The description states a specific verb ('List') and resource ('pay-for-me requests'), with a clarifying parenthetical defining what that means. This clearly distinguishes it from sibling tools like get_transactions or get_usage_history.

  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 for listing pay-for-me requests but provides no explicit when-to-use guidance or exclusions compared to alternatives. The context is clear enough, but it does not explicitly route the agent away from similar history/list tools.

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

• get_usage_historyA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the description adds marginal context by specifying it returns a daily series. It does not describe date ranges, pagination, or response format, but for a zero-parameter readonly tool this is acceptable.

  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 sentence with no filler. The key noun phrase and series type are front-loaded, making it immediately scannable.

  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?

  With no parameters, no output schema, and a read-only annotation, the description sufficiently communicates what the tool returns. It might be slightly unclear whether the series covers all historical data or a limited window, but that is a minor gap for such a simple tool.

  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?

  There are zero parameters, so the input schema is trivially complete. The description needs no parameter-level detail; the baseline of 4 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?

  Clearly states the action (Get), the resource (historical data usage), and specifies it returns a daily download/upload series. This naturally distinguishes it from the sibling get_usage tool, which implies current usage.

  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 word 'historical' implies this is for past data rather than current usage, but no explicit alternative or exclusion is stated. The agent must infer when to use this over get_usage, rather than being told directly.

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

• get_renewal_planA
  4.1/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already tells the agent the operation is safe and read-only. The description adds some useful context about what data is returned (price, validity, speed), but does not disclose anything about response shape, pagination, or authentication requirements.

  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 sentence with no filler. The action, resource, and key output fields are all front-loaded and clearly communicated.

  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 parameterless read-only tool with no output schema, this description is sufficient. An agent knows what it is getting and that no arguments are needed.

  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 and schema coverage is 100%, so the schema carries no burden. The description adds meaning by specifying the exact output fields (price, validity, speed), exceeding the baseline for a parameterless tool.

  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 ('get'), names a clear resource ('renewal plan'), and lists concrete fields ('price, validity, speed'). It is distinct enough from sibling tools like get_plans and get_upgrade_plans because it specifically targets the renewal plan.

  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 this tool is for fetching renewal plan details, but it does not explicitly say when to use it versus sibling tools such as get_plans or get_upgrade_plans. There is no mention of alternatives or exclusions.

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

• loginA
  4.1/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the full burden. It discloses the default credential source and that explicit credentials can override it, which is real behavioral context. However, it does not mention side effects such as establishing a session, what happens on failure, or whether repeated login is destructive or idempotent.

  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 no filler. The primary purpose is front-loaded, and the credential override behavior is stated in a compact follow-up sentence.

  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 login tool with no output schema and no annotations, the description covers the essential purpose and credential source. It is still incomplete in that it does not explain what the login call returns, whether it must precede all sibling calls, or what happens if environment variables are 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?

  Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: both parameters are optional because the tool falls back to FIBERONE_USERNAME/FIBERONE_PASSWORD. This is critical for an agent to know before calling.

  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 an explicit verb ('Log in') and the target resource ('FiberOne API'), making the authentication purpose unmistakable. It clearly differentiates from the sibling tools, which are all data or ticket operations.

  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?

  Explains when to supply parameters (only to override the default environment credentials), which is useful practical guidance. It does not explicitly state 'use before other API calls' or mention logout as the counterpart, but the role of login is clear from context.

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

• logoutA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It clearly states two behavioral effects: ending the session and clearing the cached token. It does not, however, disclose consequences for subsequent calls or whether the operation is reversible, which is a minor 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 sentence with no filler and no redundant restatement of the tool name. It front-loads the primary action and then adds the token-clearing detail.

  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 zero-parameter side-effect action with no output schema, the description is complete enough for an agent to know what will happen and when to invoke it. No additional context about return values or prerequisites is necessary at this complexity level.

  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 and the schema coverage is 100%, so the description has no parameters to document. The baseline score of 4 applies because there is no parameter complexity needing explanation.

  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 ('End the session') and a specific resource ('FiberOne API'), and further clarifies a side effect: clearing the cached token. This distinguishes it from sibling login and other read-oriented tools.

  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?

  Usage is clearly implied: to terminate the current session. However, the description does not explicitly state when to use it over alternatives, mention that authenticated calls will fail afterward, or reference the need to log in again. For a simple logout tool this is adequate but not explicit.

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

• get_pause_statusA
  4.4/5.0
  Behavior4/5

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

  The readOnlyHint annotation already covers the safety profile, and the description aligns with it by using 'Check' rather than implying a mutation. It adds useful context about what data is returned, which is especially valuable given there is no output schema. It does not discuss edge cases or auth, but annotations lower the bar here.

  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 front-loaded sentence states the action and resource, then uses a colon-delimited list for output details. Every word earns its place and there is no redundancy with the schema or annotations.

  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 no-input, read-only status tool with no output schema, the description gives the core purpose and the main return fields. Minor ambiguity remains about exact value formats, but nothing an agent needs to decide whether to call the tool 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 description cannot add parameter-level meaning. The no-parameter baseline of 4 applies, and no further parameter documentation is needed.

  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: 'Check account pause eligibility', and enumerates the exact outputs ('days paused, days left this year, pause reasons'). This makes it clearly distinct from siblings like get_pause_history or get_lost_days, which are oriented toward historical data rather than current eligibility.

  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 for when to call the tool: whenever account pause eligibility or current pause counters are needed. It does not explicitly name alternative tools or exclusions, but for a zero-parameter read-only status call this is sufficient context.

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