Server Quality Checklist

Tool Scores

• reset_passwordB
  3.3/5.0
  Behavior2/5

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

  Annotations are absent, so the description carries the full burden. It only states 'reset', implying mutation, but does not disclose side effects (e.g., whether a new password is generated, if an email is sent, or if the service must be stopped). This is minimal behavioral disclosure.

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

  Conciseness5/5

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

  The description is a single, concise sentence: 'Reset the VPS root password.' It is front-loaded with the action and resource, with no unnecessary 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 simple one-parameter tool, the description provides the core action but lacks usage context and side effects. There is no output schema, so return behavior is unmentioned. Overall, adequate but with clear gaps, making 3 appropriate.

  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 service_id with 'VPS service id.', and the description does not add additional semantics. With 100% schema coverage, the baseline of 3 applies; the description does not enhance parameter understanding.

  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 'reset' and a clear resource 'VPS root password', making the action unambiguous. It distinguishes from sibling tools like power_vps or set_hostname which perform different operations.

  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 usage guidance is provided. The description does not state when to use this tool, any prerequisites (e.g., service must be active), or alternatives like reinstall_vps. The agent is left without contextual direction.

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

• order_vpsA
  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. It discloses that payment is drawn from prepaid balance, a useful behavioral trait, but does not mention failure modes (e.g., insufficient balance), whether the order is synchronous, or any provisioning delays. This is a mutation tool, so more transparency is needed.

  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, front-loaded with the action and resource, and contains no fluff. Every word earns its place while still conveying the payment mechanism.

  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?

  Given no output schema and no annotations, the description is thin on side effects and error handling. It covers the core action and payment source, and the input schema is well-documented, but it does not explain what happens on success, failure, or how long provisioning takes. Adequate but with clear gaps.

  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 provides 100% coverage with clear descriptions for each parameter. The description adds the phrase 'by plan slug + OS id', which reinforces the relationship but does not provide additional meaning beyond the schema. Baseline 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 clearly states the action 'Order' and the resource 'VPS', with the key inputs 'plan slug' and 'OS id'. It is distinct from sibling tools like list_vps and cancel_service, leaving no ambiguity about what this tool does.

  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 creating a new VPS with a prepaid balance, but it does not explicitly state when to use it vs alternatives or mention prerequisites like checking balance first. The unique purpose makes alternatives obvious, but guidance is minimal.

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

• power_vpsA
  3.7/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 for behavioral disclosure. It only states the actions without explaining consequences (e.g., stopping causes downtime, reboot disrupts services) or prerequisite conditions. For a mutation tool, this lacks critical transparency beyond the schema's enum values.

  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?

  Single sentence, front-loaded with the action, no filler. The structure is optimal for a simple power-control 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 low-complexity tool, the description plus schema is mostly sufficient. However, the lack of annotations and explanation of side effects (e.g., what happens on stop/reboot) leaves gaps that could confuse an agent, especially without an output 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?

  Schema coverage is 100% with both parameters described ('VPS service id', 'Power action'). The description adds no extra meaning beyond the schema's enum values, 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.

  Purpose5/5

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

  The description clearly states the tool's function: 'Power-control a VPS: start, stop or reboot.' The compound verb 'power-control' is specific and the listed actions (start, stop, reboot) make the scope unambiguous. This distinguishes it from sibling tools like reinstall_vps or cancel_service.

  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 clearly implies when to use the tool: whenever a VPS needs to be started, stopped, or rebooted. However, it does not explicitly exclude alternatives or mention related tools (e.g., get_vps_status for checking state), but the context is strong enough for an agent to select it appropriately.

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

• get_vps_metricsA
  3.8/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals safety. The description adds that the data is time-series and identifies the metric categories, which gives some expectation of the output shape. However, it doesn't disclose default range behavior or any response structure details beyond that.

  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 that front-loads the tool's purpose. Every word contributes to clarity, with no unnecessary repetition or fluff.

  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 metrics tool with 2 well-documented parameters, the description covers the essential purpose and metric scope. Without an output schema, a bit more detail on default range or response format would be helpful, but it's not critically 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%, so the description adds no additional parameter guidance. It doesn't mention the range parameter or service_id, but the schema already documents them adequately.

  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 that the tool returns time-series resource metrics (CPU, memory, network, disk) for a VPS. This specific verb+resource+scope distinguishes it from sibling tools like get_vps_status (current status) and list_vps (list VPSs).

  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 by naming the resource and metric types, but it doesn't explicitly state when to use this tool versus alternatives or mention exclusions. An agent can infer that this is for historical resource monitoring, but no explicit guidance is provided.

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

• revoke_delegationA
  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 behavioral disclosure burden. It does mention a side effect (the other side is notified) and implies permission roles, but it lacks details on reversibility, error handling, or output behavior. Given it's a mutation tool, more transparency would be beneficial.

  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, front-loaded with the primary action. Every word earns its place, and the description is appropriately sized for a one-parameter 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?

  The description covers the core action and a side effect, which is adequate for a simple one-param tool. However, without annotations or an output schema, it misses information about errors, idempotency, or return values, leaving some gaps in completeness.

  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 fully documents delegation_id with a description, and the description only restates 'by id' without adding deeper meaning. Since schema coverage is 100%, the baseline of 3 is appropriate; the description does not compensate beyond that.

  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 (revoke) with a resource (delegation) and clarifies the operation by id. It clearly differentiates from sibling tools like accept_delegation and delegate_service by indicating the action is a revocation/decline.

  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?

  It explains the two scenarios where the tool applies: an owner revoking or a delegate declining. This provides clear contextual guidance, but it does not explicitly list alternatives or exclusions such as listing delegations first or using accept_delegation for accepting.

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

• loginA
  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 full burden. It discloses the key behavior of returning a Bearer token, but does not mention failure behavior, token expiry, or whether it invalidates previous sessions. This is a moderate gap given the absence of structured annotations.

  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 that is front-loaded with the action, contains no filler, and communicates the essential purpose and outcome 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?

  The tool is simple with two well-documented parameters and no output schema, so the description covers the core purpose and return value. It lacks error handling or token usage context (e.g., Authorization header), but given the simplicity, it is largely 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?

  The input schema already provides meaningful descriptions for both parameters (Account email/password), and schema coverage is 100%. The description only restates 'email + password' without adding syntax, format, or additional constraints beyond what the schema already conveys.

  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 (log in), the credential type (email + password), and the result (Bearer token). It distinguishes login from sibling tools like register_account and whoami by being the authentication entry-point.

  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 it (to authenticate and get a token), but it does not explicitly mention alternatives or when not to use it. The context is clear enough for a login tool, though it could benefit from noting that register_account creates an account first.

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

• pay_invoiceA
  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 full burden. It discloses that it initiates a payment and returns a checkout URL, offering some insight into the flow. However, it does not mention side effects like whether the invoice is locked, payment reversibility, or prerequisites beyond ownership and unpaid status.

  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 unnecessary words. It front-loads the action and concisely states the action, subject, and result.

  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 tool with one parameter and no output schema, the description provides adequate context: it states the core action, a prerequisite condition, and the return value. It omits details about error conditions or post-payment behavior, which could be relevant for a financial operation, but the essentials are covered.

  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 schema describes invoice_id as 'Invoice id to pay' (100% coverage). The description adds the constraint that the invoice must be owned and unpaid, providing additional meaning beyond the schema's simple field description.

  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 'Initiate' and a clear resource 'crypto payment for an owned unpaid invoice', and explicitly mentions the output 'returns a checkout URL'. This clearly distinguishes it from sibling tools like topup_balance.

  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 paying owned unpaid invoices but provides no explicit when-to-use guidance or alternatives. It does not explain when to choose this tool over topup_balance or other payment methods.

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

• register_accountA
  4/5.0
  Behavior3/5

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

  With no annotations, the description must carry the burden of behavioral disclosure. It discloses that no KYC/OTP is involved and that a Bearer token is returned, but does not mention side effects, idempotency, password policies, or potential failures—moderate transparency for a creation tool.

  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 that packs in the action, programmatic nature, no-KYC/OTP detail, and return type. Every word earns its place; no redundancy or fluff.

  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 tool with only two required parameters and no output schema, the description covers the key aspects: what it does, the key behavioral trait of skipping KYC/OTP, and the return value. It lacks explicit permission/safety details but is otherwise complete for an account registration 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%, with both parameters clearly described (email with no verification, password). The description adds no additional parameter-specific detail beyond confirming the absence of human verification, 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.

  Purpose5/5

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

  Description clearly states the verb 'Create' and resource 'EQVPS account', and specifies the programmatic nature with no human/KYC/OTP step. This distinguishes it from siblings like login and reset_password by making the account-creation purpose explicit.

  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?

  Provides context that this is for programmatic account creation without human verification, which implies when to use it over login or other account management tools. However, it does not explicitly name alternative tools or state when not to use it.

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

• reinstall_vpsA
  4/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true, and the description adds valuable context by specifying the destructive behavior: it wipes and reinstalls, which tells the agent what gets destroyed. This goes beyond the bare annotation without being redundant.

  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, punchy sentence front-loaded with 'DESTRUCTIVE' that immediately communicates the tool's nature and function. Every word earns its place; no waste.

  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 destructive tool with no output schema, the description covers the core action and destructive nature. It does not mention the confirm parameter's purpose or potential downtime, but the schema provides the parameter details and the destructive hint is already highlighted. Overall, it is sufficiently complete for an agent to use the tool 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 description coverage is 100%, with all three parameters (service_id, os, confirm) already described. The description adds no additional parameter-specific meaning beyond the phrase 'given OS image,' which maps to the 'os' parameter. Baseline 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 specific verbs 'wipe and reinstall' and identifies the resource ('the VPS') and the key input ('a given OS image'). It clearly distinguishes this from sibling tools like power_vps, set_hostname, and cancel_service, leaving no ambiguity about the operation.

  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 (when you need to reinstall with a new OS), but it does not explicitly state when to prefer this over alternatives or mention any prerequisites or exclusions. There is no explicit context like 'use when the current OS is corrupted' or 'do not use if you need to preserve data.'

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

• topup_balanceA
  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 full burden. It discloses that the tool creates an invoice and returns a checkout URL, and specifies payment networks. However, it does not mention authentication requirements, whether balance is credited automatically, fees, or invoice expiration, leaving some 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 concise sentences that front-load the purpose and return value, with no filler or redundancy. Every word 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?

  The tool is simple with one parameter, and the description covers primary purpose, return value, and payment methods. It lacks minor details like how the invoice is paid or side effects, but is sufficient for a straightforward top-up 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?

  The schema already has 100% coverage with 'Top-up amount in USD.' The description does not add further meaning to the parameter beyond what the schema provides, so the baseline score of 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 states a specific verb+resource ('Create a crypto top-up invoice') and clearly distinguishes from siblings by mentioning the PayRam checkout URL and payment methods. It clearly differentiates from tools like pay_invoice and get_balance.

  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 it (to top up balance via crypto) and specifies the payment options (USDC/USDT on Base or Ethereum). It does not explicitly mention when not to use it or alternatives, but the intended context is clear.

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

• get_balanceA
  4.1/5.0
  Behavior3/5

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

  The annotations already provide readOnlyHint=true, indicating a safe read operation. The description adds that the tool returns both balance and currency, giving some context about the output. However, it does not disclose any other behavioral traits such as authentication requirements, rate limits, or potential errors. Given the read-only nature, the description is minimally sufficient.

  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: 'Return prepaid credit balance and currency.' Every word is meaningful, and it is front-loaded with the action. No unnecessary information is present.

  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 read-only tool with no output schema, the description completely covers what the tool returns (balance and currency). No further context is needed to understand the tool's purpose or use.

  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 parameter semantics are trivial. The schema covers 100% of parameters (none). Per the rubric, 0 params earns a baseline of 4. 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.

  Purpose5/5

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

  The description clearly states the tool's function: 'Return prepaid credit balance and currency.' It uses a specific verb ('Return') and resource ('prepaid credit balance and currency'), which unambiguously distinguishes it from sibling tools like topup_balance (which adds credit) or whoami (which returns account identity).

  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 when the user needs to know their prepaid credit balance, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. For instance, it does not say 'use this before placing an order' or 'for top-ups, use topup_balance instead.'

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

• accept_delegationA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It usefully discloses that the tool returns a Bearer token and that the token comes from an invite link. However, it does not mention any side effects, auth prerequisites, or error conditions.

  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, direct and front-loaded. No superfluous information.

  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 tool with no output schema, the description covers purpose, token source, and return value. It does not address potential failure modes or authentication requirements, but is otherwise complete for selection and invocation.

  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% for the token parameter, but the description adds meaning by specifying the token comes from an invite link, which goes beyond the schema's 'Invite token.' description.

  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 (accept), the object (delegation invite), and the required input (token from invite link), distinguishing it from sibling delegation tools like delegate_service and revoke_delegation.

  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 clearly indicates when to use the tool: when you have a delegation invite token. It does not explicitly mention alternatives, but the sibling context makes it obvious this is the accept action, not create or revoke.

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

• delegate_serviceA
  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 transparency burden. It usefully discloses the access level (OPERATOR), included capabilities, exclusions, the fact that an invite is sent, optional time limits, and the owner-only restriction. It does not mention immediate vs. pending access or revocation mechanics, but the core behavioral traits are well covered.

  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, front-loaded with the primary action and resource, and then expands with scope, invite behavior, and owner-only constraint. Every sentence earns its place with no redundancy or filler.

  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 relatively simple mutation tool with no output schema, the description covers the essential context: what access is granted, what is included/excluded, what happens (invite), optional expiry, and ownership requirement. It does not mention the acceptance flow or response format, which slightly reduces completeness, but it is largely 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 baseline is 3. The description adds some meaning beyond the schema by explaining 'by email' and 'optional time limit', but it does not substantially enrich the parameter definitions already present in the schema.

  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 ('Grant OPERATOR access') and the resource ('one of your VPS to another person by email'). It also differentiates the scope ('power/reinstall/console/hostname/rDNS, not billing') from the sibling delegation tools, making the tool's unique purpose unmistakable.

  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 indicates when to use the tool by specifying the grant action, the recipient mechanism ('by email'), and a key prerequisite ('Owner-only'). It does not explicitly name alternative tools or exclusions beyond 'not billing', but the verb and the sibling names (accept_delegation, revoke_delegation) provide enough contextual distinction.

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

• get_vps_statusA
  4.2/5.0
  Behavior4/5

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

  With readOnlyHint=true, the safety profile is already clear. The description adds value by specifying the returned categories (status, specs, live VM state/uptime, SSH access), helping the agent understand what to expect. It does not mention rate limits or auth, but for a simple read-only tool, this is sufficient.

  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 focused sentence, front-loaded with the tool's purpose and followed by a concise list of content areas. No wasted words.

  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?

  The tool is simple with one parameter and no output schema. The description lists key data categories, which is adequate for the agent to understand the return content. It lacks explicit output structure, but for a straightforward status tool, this is sufficiently 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 coverage is 100% with the parameter 'service_id' described as 'VPS service id.' The description does not add further parameter context, but the baseline of 3 applies when the schema fully documents parameters.

  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 tool retrieves full detail for one VPS, listing specific content (status, specs, live VM state/uptime, SSH access). This distinguishes it from siblings like list_vps, which likely provides summary info for all VPS, and get_vps_metrics, which focuses on metrics.

  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 usage when detailed information about a specific VPS is needed, especially compared to list_vps for overview. It provides clear context but does not explicitly name alternatives or state when not to use it, so it misses the top score.

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

• set_hostnameA
  4.2/5.0
  Behavior3/5

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

  The description discloses an important non-obvious behavior: the hostname is only applied on reboot/rebuild. However, with no annotations provided, it leaves other behavioral aspects unaddressed, such as whether the change is reversible or if there are permission requirements. It adds some context but is not comprehensive.

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

  Conciseness5/5

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

  The description is a single concise sentence with a parenthetical that packs essential extra context. Every word contributes meaning and the key action 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 two-parameter mutation tool, the description covers the action and the most important behavioral detail (when it takes effect). The absence of an output schema is acceptable since return values are likely obvious. A brief note about immediate vs. post-reboot effects is already included.

  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% and both parameters are described, but the description adds value by clarifying that the hostname is a DNS label, which constrains the accepted format beyond the schema's simple "New hostname." This helps the agent avoid invalid input.

  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+resource construction: "Set the VPS hostname." It clearly distinguishes this tool from sibling tools like power_vps or reinstall_vps by naming the exact action and target. The parenthetical adds useful detail about it being a DNS label.

  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 the tool's use case obvious: it is for changing the VPS hostname. While it does not explicitly mention alternatives or exclusions, there is no overlapping sibling tool that sets hostnames, so the context is clear enough without saying "use this instead of X."

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

• list_delegated_to_meA
  4.3/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already discloses that this is a read-only operation. The description adds no extra behavioral details such as pagination, authorization requirements, or return format. Since annotations cover the safety profile, a 3 is appropriate.

  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 that immediately states the tool's function. No filler or repetition; every word contributes to understanding.

  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, read-only list tool with an annotation and clear description, the information is complete. The user knows what the tool does and that it aggregates incoming delegations, without needing an 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, and the schema confirms this with no properties. The description does not need to explain parameters, so a baseline of 4 is applied.

  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 tool lists services delegated to you by other owners, using the specific verb 'List' and the resource 'services other owners delegated operator access to you.' It is unambiguous and distinguishes this from a general delegation list.

  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 is for incoming delegations ('to you'), but it does not explicitly mention alternatives or when not to use it. The sibling 'list_delegations' may serve a broader purpose, but no comparison is given.

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

• list_delegationsA
  4.3/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already establishes the safe read-only nature. The description adds context about the output contents ('who has operator access to what, and its status'), but does not disclose additional behavioral traits such as ordering, pagination, or default filters. It meets the minimum bar with the annotation supported.

  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, well-structured sentence that leads with the action verb. It contains no filler words and precisely conveys the scope and content, earning the maximum score.

  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?

  This is a simple, zero-parameter read-only list tool with no output schema. The description fully covers what the tool lists and the key information returned (operator access and status), making it sufficiently complete for an agent to understand and invoke 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?

  There are zero parameters, so the baseline is 4. The description needs no parameter explanation, and the schema coverage is effectively 100% with an empty properties object. No further parameter semantics are required.

  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 resource ('outgoing delegations you granted'), clearly distinguishing it from incoming delegations. It further specifies the informational content ('who has operator access to what, and its status'), making the tool's purpose unambiguous.

  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 phrasing 'outgoing delegations you granted' clearly indicates when to use this tool—for viewing delegations you initiated—and implicitly differentiates it from the sibling tool 'list_delegated_to_me'. However, it does not explicitly name alternatives or state when not to use it, stopping short of a 5.

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

• list_vpsA
  4.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already covers safety, so the description only needs to add value beyond that. It adds scope (account's VPS services) and output fields, but does not mention pagination, potential delays, or any other behavioral nuance. 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 one concise, front-loaded sentence that states the action and the output, with no filler or redundant information.

  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 list operation with no input parameters and no output schema, the description is complete. It explains what is listed and what fields are returned. No additional context is 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?

  There are zero parameters, so the baseline is 4. The description's mention of 'the account's' clarifies the implicit scope but does not need to document parameter details. It adds enough context given the lack of parameters.

  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 action (list), a specific resource (the account's VPS services), and the scope (account-level). It also lists the returned fields (id, status, plan), making it distinct from sibling tools like get_vps_status or power_vps.

  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 the tool's purpose unmistakable: to list all VPS services. It does not explicitly mention when not to use it or provide alternatives, but the context is clear given the sibling tools. A slightly higher score would require an explicit alternative statement.

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

• whoamiA
  4.3/5.0
  Behavior4/5

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

  The annotation readOnlyHint=true already indicates a safe read operation. The description adds the context that it returns the profile of the authenticated account, implying a valid session is required. No contradictions; reasonable for a simple read-only tool.

  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?

  Single sentence, front-loaded, with no wasted words.

  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 read-only tool with no output schema, the description adequately states the return value. The profile concept is clear in context, and no additional behavior needs disclosure.

  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 zero parameters, the schema is fully covered. The description adds no parameter semantics, but none are needed; baseline 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?

  The verb 'Return' clearly specifies the action, and 'authenticated account profile' identifies the resource. This distinguishes it from sibling tools like get_balance or login, focusing on the current user's identity.

  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 use this tool versus alternatives. However, the name and phrase 'authenticated account profile' imply it should be used to retrieve the current user's information. There is no exclusion or alternative mentioned.

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

• list_plansA
  4.4/5.0
  Behavior4/5

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

  The annotation readOnlyHint=true already signals a safe read operation. The description adds the valuable behavioral detail that the tool is public and requires no authentication, which is not inferable from annotations alone.

  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 that immediately states the action, the object, and the key qualifiers (pricing, specs, OS images, public, no auth). Every word earns its place with no 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 read-only list with no parameters and no output schema, the description provides sufficient context: what is listed and the auth requirement. It does not detail return format, but that is not essential for a public catalog lookup and output schema absence lowers the burden.

  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 fully covers this (100% coverage). The description adds no parameter-specific semantics, but with no parameters this is unnecessary; the baseline of 4 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 a specific verb 'List' and a clear resource 'available VPS plans', further detailing that it includes pricing, specs, and OS images. This clearly distinguishes it from sibling tools like list_vps, which likely lists user-owned VPS instances.

  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 notes 'Public — no auth', giving clear context that this tool can be used without authentication, unlike many siblings that likely require auth. It implies when to use it (when browsing available plans) but does not explicitly name alternatives or exclusions.

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

• cancel_serviceA
  4.6/5.0
  Behavior5/5

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

  The annotations only give destructiveHint=true, but the description elaborates that 'immediate' destroys the VM and data and requires confirm=hostname, while 'end_of_period' runs until the paid period ends. This adds concrete behavioral context beyond the annotation without contradicting 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, front-loaded sentence that efficiently conveys the action, mode options, consequences, and a required parameter. Every word earns its place, with no 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 tool with three parameters, no output schema, and a destructive annotation, the description covers the core behavior and invocation requirements. It omits minor context like post-cancellation confirmation, but that is not essential for correct use.

  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 schema already describes all parameters (100% coverage), so the baseline is 3. The description adds value by explaining the behavioral difference between the two enum values for 'mode', but it does not provide new details for service_id or confirm beyond what the schema states.

  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 the verb 'Cancel' and the resource 'VPS', making the tool's primary action clear. It further distinguishes the two cancellation modes (end_of_period and immediate), which sets it apart from sibling tools like power_vps or reinstall_vps.

  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 explicit guidance on when to use each mode: 'end_of_period' is the safe default, while 'immediate' is destructive and requires confirm. It does not mention alternative tools for similar actions (e.g., power off), but within this tool the mode-selection context is clear.

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