eqvps

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

With no annotations, the description carries the full disclosure burden. It reveals the authentication prerequisite, the resulting access change ('grants operator access'), and the important session behavior that no new token is issued. These are precisely the non-obvious behaviors an agent needs to know.

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

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

Three short sentences deliver the purpose, prerequisite, effect, and token behavior with zero filler. The most important information is front-loaded in the first sentence.

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

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

For a single-parameter tool with no output schema, the description covers the action, token source, required auth context, effect, and response behavior. No critical information for correctly invoking it is missing.

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

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

Schema coverage is 0%, so the description must explain 'token'. It does so clearly by identifying it as the token from the invite link, adding provenance and usage that the input schema alone cannot convey.

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

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

Description names the specific action ('accept'), the resource ('delegation invitation'), and the token source ('invite link'). 'Grants operator access to your own account' clearly distinguishes accept_delegation from delegating to someone else (delegate_service) or revoking (revoke_delegation).

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

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

It gives a concrete condition for use: accept when you have the token from an invite link and are signed in as the invited email address. It does not enumerate alternatives or explicit when-not-to-use cases, but the context is clear enough for an agent to select it.

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

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

With zero annotations, the description carries the full disclosure burden and excels: it states end_of_period means "NO data loss now, safe," and that immediate "DESTROYS the VM and ALL data right away, permanently and irreversibly." It also discloses the confirm prerequisite, the refund of the unused paid period, and points to refund_amount in the response — a complete safety and consequence profile for a destructive operation.

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

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

The description is a dense ~90-word block where every sentence earns its place: purpose, default-mode safety, destructive-mode warning with the confirm prerequisite, an explicit recommendation, and refund behavior. The safety-critical contrast is front-loaded and emphasized with caps, though the single-paragraph format with several dependent clauses is slightly harder to scan than bulleted structure would be.

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

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

For a destructive 4-parameter tool with no output schema and no annotations, this covers nearly everything: both modes, the confirm requirement, where to find the hostname, and the refund/response pointer. Minor gaps remain: the description never states which parameters must be combined (schema only marks reason as required even though identifying the VPS via service_id is mandatory) and the full response shape beyond refund_amount is unspecified.

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

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

Schema coverage is only 50% (reason and service_id are documented; type and confirm are not). The description compensates precisely for the gaps: it explains both enum values of type in detail and clarifies that confirm must hold the exact server hostname, obtainable via get_vps_status. The schema already handles reason and service_id, so the description adds value exactly where needed.

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

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

The description opens with the specific verb+resource pair "Cancel a VPS" and then dissects what cancellation means via two concrete modes (end_of_period vs immediate). No sibling tool performs termination, so there is no ambiguity with power_vps, reinstall_vps, or set_hostname.

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

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

The description gives explicit when/when-not direction: "Use end_of_period unless you explicitly intend to wipe the server now" and says immediate "REQUIRES confirm set to the exact server hostname." It does not compare against alternative sibling tools, but no sibling handles cancellation, so the key decision an agent faces — which mode to select — is fully guided.

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

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

No annotations are provided, so the description carries the full burden. It notes that closing can be done without rating, but it does not disclose any side effects (e.g., whether closing is irreversible, whether it notifies the other party, or whether the ticket becomes read-only). For a mutation tool, this is a significant gap.

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

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

Two sentences with no filler. The first sentence states the primary purpose, the second covers optional parameters and where to get the required input. Every sentence earns its place.

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

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

The description covers the basic purpose, optionality, and input source. However, with no annotations or output schema, it leaves out behavioral consequences (e.g., whether closing is permanent, if it affects ticket status, or any prerequisites beyond ownership). It is adequate for a simple action but not fully complete.

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

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

The schema has 0% description coverage. The description adds meaning by clarifying that rating and comment are optional, and that ticket_code should come from create_ticket/list_tickets. It also mentions the 1-5 range for rating, which mirrors the schema but reinforces it. However, it doesn't elaborate on the comment parameter or provide examples.

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

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

The description uses a specific verb ('Close') and resource ('one of your tickets'), clearly differentiating this from sibling tools like reply_ticket or get_ticket. The scope ('one of your tickets') adds ownership context.

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

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

It explains that rating and comment are optional, and tells the agent to use the ticket code from create_ticket or list_tickets. This provides context for when to use the tool, though it doesn't explicitly exclude alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses a key behavioral detail—the response contains a ticket code needed for subsequent actions—and clarifies that service_id optionally associates the ticket with a VPS. However, it does not describe side effects, failure conditions, or authorization requirements 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.

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

Two sentences with no filler: the first establishes purpose and input requirements, the second gives output and next-step guidance. Every clause carries useful information.

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

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

For a simple three-parameter creation tool with no output schema, the description covers the required parameters, the optional parameter behavior, the returned ticket code, and how to continue with sibling tools. It does not mention authentication or error behavior, but the operation is simple and well-scoped enough that these are not critical gaps.

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

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

Schema description coverage is only 33% (only service_id has a description), so the description must compensate. It names all three parameters, marks subject and message as required, and adds conceptual meaning to service_id ('ties it to one of your VPS'). It adds little beyond the names for subject and message, which are largely self-explanatory.

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

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

Uses a specific verb ('Open') and resource ('support ticket'), with a clear vendor qualifier ('with EQVPS'). It clearly separates this creation action from sibling tools like get_ticket, reply_ticket, and close_ticket.

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

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

The description implies the appropriate lifecycle context: it is the entry-point action whose returned ticket code is then used with get_ticket, reply_ticket, or close_ticket. It does not explicitly state exclusions, but it names the follow-up sibling tools so an agent can infer when to use each.

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

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

No annotations are provided, so the description carries the full burden. It discloses exactly what the operator can do (power/reinstall/console/hostname/rdns), what they cannot do (renew/cancel/billing), that an invitation with an accept link is sent, and that access can be time-limited. This is exceptional transparency.

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

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

Three compact sentences with no filler. The core action is front-loaded, followed by permission boundaries, the invitation flow, and the optional expiration parameter. Every sentence earns its place.

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

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

For a delegated-access action with no output schema and no annotations, the description covers who, what, whom, limits, invitation mechanics, expiration, and ownership. An agent has enough to select and invoke the tool correctly without needing to inspect sibling definitions.

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

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

Schema description coverage is only 33%, so the description must compensate. It adds meaningful semantics for email (the person receiving access), expires_days (time-limited access), and clarifies service_id as one of the caller's own VPS instances. It doesn't exhaustively define each parameter, but it covers the important operational meaning.

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

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

The description states a specific verb ('Grant OPERATOR access'), the resource ('one of YOUR VPS'), and the recipient ('another person by email'). It clearly distinguishes this from siblings like accept_delegation and revoke_delegation by framing it as the owner-initiated grant action.

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

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

It gives clear context: use when you own a VPS and want another person to operate it, with an 'Owner-only' restriction and a precise list of allowed actions. It does not explicitly name alternatives, but the context and sibling list make the intended use unambiguous.

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

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

No annotations are provided, so the description carries the full burden. It states the return value but does not explicitly confirm that the operation is read-only or disclose any potential side effects, authentication requirements, or rate limits. The behavioral disclosure is adequate but minimal.

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

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

The description consists of two concise, front-loaded sentences. Each sentence adds value: the first describes the core function, the second provides relevant context about its use with another tool. No unnecessary words.

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

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

Given the simplicity of the tool (no parameters, no output schema), the description is completely adequate. It specifies what is returned (balance and currency) and how it relates to order_vps, which is sufficient for an agent to understand its role.

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

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

The input schema has no parameters, so schema coverage is 100%. With zero parameters, the baseline is 4. The description adds no parameter information, but none is needed.

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

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

The description clearly specifies that the tool returns the account's prepaid credit balance and currency. It also distinguishes itself from sibling tools like order_vps (spends balance) and topup_balance (adds balance) by mentioning the spending relationship.

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

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

The description implies when to use the tool (to check balance before ordering) but does not explicitly state when not to use it or provide alternative tools. The context about order_vps spending from this balance gives practical guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool returns the full message thread, that each message has an author field with values 'you' or 'staff', and that 'staff' messages are replies from support. This goes beyond a bare 'read' operation and gives useful behavioral context, though it omits details like error handling or rate limits.

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

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

The description is three short sentences with no filler. The opening sentence immediately states the purpose, followed by useful message-thread details and a sourcing hint. Every sentence earns its place.

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

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

For a simple one-parameter read tool with no output schema, the description covers the essential use case, message structure, and polling behavior. It could be slightly more explicit about the return shape, but it is complete enough 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.

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

Schema description coverage is 0%, so the description compensates by explaining what the single parameter 'ticket_code' is used for and where to obtain it ('comes from create_ticket / list_tickets'). This adds meaning beyond the schema's bare type/minLength definition, though it does not specify the exact format or length constraints.

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

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

The description uses a specific verb ('Read') and resource ('one ticket and its full message thread'), clearly distinguishing it from sibling tools like list_tickets, create_ticket, reply_ticket, and close_ticket. It immediately conveys the tool's core function without ambiguity.

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

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

It states when to use the tool ('Poll this to see new answers') and where the input comes from ('The ticket code comes from create_ticket / list_tickets'). It does not explicitly mention when not to use it, but the context is clear enough for an AI 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.

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

No annotations are provided, so the description alone must carry behavioral context. It states the metric types and the default timeframe, which gives some practical behavior, but it does not disclose output shape, units, or confirm this is a read-only operation.

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

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

The description is one tight sentence with the core behavior front-loaded, followed by a compact parameter constraint. Every part contributes information, and there is no redundant or promotional language.

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

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

With no output schema and no annotations, the description should provide more context about the returned time-series data and how service_id is used, especially since it is marked as optional. The metric categories and timeframe are clear, but an agent could still be uncertain about the response format and the meaning of an omitted service_id.

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

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

The description adds value for the timeframe parameter by enumerating allowed values and noting the default of 'hour', which goes beyond the schema's bare enum. The service_id parameter is left to the schema, which already provides a useful description with an example, so the split is adequate but not comprehensive.

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

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

The description clearly identifies the tool as returning time-series resource metrics (CPU %, memory, network, disk) for a VPS, which is a specific resource and data type. It is distinct enough from siblings like get_vps_status by naming concrete metric categories, though it does not explicitly call out that distinction.

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

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

There is no guidance on when to use this tool versus alternatives such as get_vps_status, and no exclusions or prerequisites are mentioned. The description implies its use for metric retrieval but does not help an agent choose between related VPS tools.

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

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

With no annotations, the description fully discloses behavioral traits: password shown once, password_pending flag, one-time reveal not spent until password returned, ssh_ready meaning, and NAT port forwarding. It explains side effects and prerequisites in depth.

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

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

Long but every sentence carries load-bearing detail; no filler. Starts with core purpose, then flows into access info, password reveal, boot behavior, polling, NAT specifics, and firewall caution—logical progression that front-loads the most critical usage.

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

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

The tool is complex (status, provisioning, password reveal, NAT port forwarding, firewall interplay) and has no output schema. The description covers boot timing, password lifecycle, SSH key login, NAT DNAT port mapping, and internal vs external firewall ports, leaving little for an agent to infer.

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

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

Despite schema coverage at 50%, the description adds rich semantics: reveal is explained (true retrieves password, absent returns password_available), and service_id is tied to list_vps/order_vps with an example. It compensates for the missing reveal schema description and clarifies default behavior.

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

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

The description opens with a specific verb and resource: 'Get full detail for one VPS' and enumerates the exact content (status, specs, live VM state/uptime, access info). It immediately distinguishes from siblings by naming what it is not (e.g., list_vps, reset_password) and by covering the one-time password reveal, which is unique to this tool.

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

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

Provides explicit when-to-use instructions: polling after order_vps, retrying during boot, and using reset_password only if the password is lost. It also covers the NAT firewall scenario and SSH key login, which clarify when alternative actions are needed.

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

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

No annotations are provided, so the description carries full burden. It describes the purpose adequately for a simple read operation, but does not disclose additional behavioral traits like data freshness or side effects.

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

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

The description is a single, concise sentence that is immediately understandable. No wasted words or redundant information.

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

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

Given the tool has no parameters, no output schema, and is a simple list operation, the description is fully complete. It adequately explains what the tool does without requiring further elaboration.

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

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

The tool has zero parameters, so the schema already covers structure. The description adds meaningful context by specifying the resource as 'services delegated by other owners', which is beyond the empty schema.

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

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

The description clearly states the tool lists services delegated to the user, using specific verbs and resources. It distinguishes from siblings like list_delegations (outgoing) and list_vps (owned VPS).

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

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

The description implies usage for viewing incoming delegations but lacks explicit guidance on when to use alternatives like list_delegations or list_vps. No exclusions or conditions are provided.

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

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

No annotations are provided, and the description does not disclose behavioral traits beyond the basic operation. It does not mention whether it lists only active delegations, pagination, authentication requirements, or any side effects. For a simple read operation, this is adequate but not transparent.

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

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

The description is a single sentence that is concise and front-loaded with the action and resource. It contains no fluff and earns its place.

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

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

Given the tool has no parameters and no output schema, the description is complete enough for an agent to understand what it does. It explains the scope (outgoing delegations) and the information returned (who, what, status). Slightly more detail about return format or status values could improve it, but it's sufficient.

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

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

The tool has 0 parameters, so the input schema is trivially covered (100%). The description adds no parameter information, which is acceptable per the baseline of 4 for tools with no parameters.

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

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

The description clearly states the tool lists outgoing delegations granted by the owner, specifying 'who has operator access to what, and its status.' It distinguishes from the sibling 'list_delegated_to_me' which lists delegations received, so the agent can differentiate.

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

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

The description implies usage for listing one's own delegations but does not explicitly state when to use this tool versus alternatives like 'list_delegated_to_me' or other sibling tools. No exclusions or context are provided.

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

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

No annotations are present, so the description correctly carries the burden of behavioral disclosure. It adds genuinely useful operational context beyond a simple catalog statement: 'No authentication needed' — a real behavioral trait an agent would otherwise have to discover or assume. It also surfaces the Windows BYOL licensing model, which materially affects user experience and expectations.

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

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

The description is dense but well-organized: it front-loads the core purpose and deliverable, then breaks the two plan families into readable parenthetical detail, and closes with the usage directive. It is slightly long but every clause earns its place by distinguishing plan types or adding operational value; no filler.

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

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

For a zero-parameter, no-output-schema catalog tool this is complete. It covers what is returned (pricing, specs, OS images), the two plan categories and their defining differences (IPv4, BYOL, port speed, price), the authentication requirement, and how to chain the result into order_vps. Nothing an agent needs to call it correctly is missing.

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

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

The tool has zero parameters and the schema is empty, so there is nothing for the description to clarify about parameter input. The baseline of 4 for a no-parameter tool applies, and the description goes beyond merely resting at baseline by explaining how the output will be used downstream (picking product slug and os_id).

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

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

The description names a specific verb ('List'), a specific resource ('available VPS plans catalog'), and enumerates the deliverable content: pricing, specs, and bootable OS images. It further distinguishes the two plan families by slug pattern (linux vs windows-*) and pricing, so an agent can tell exactly what this tool returns without opening any schema.

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

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

The final sentence gives explicit, actionable guidance: 'Use this first to pick a product slug and an os_id for order_vps.' This tells the agent when in the workflow to invoke it and what values to extract from the result, routing it toward the sibling tool order_vps. No inference is required.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It offers a useful detail about interpreting `last_message_author: "staff"` and implies read-only access via the verb 'list,' but it does not address authorization, pagination, or other behavioral nuances.

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

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

The description is two concise sentences. The first states the action and output, and the second adds a meaningful data interpretation note, with no redundant information.

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

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

For a simple parameterless list tool with no output schema, the description covers the key returned fields (status, last-message) and a helpful caveat. However, it omits potential details like response size limits or whether filters exist, 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.

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

The tool has zero parameters, so the description correctly avoids parameter details. The baseline of 4 applies for parameterless tools, and the schema already fully covers parameter structure.

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

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

The description clearly states 'List your support tickets with status and last-message info,' using a specific verb and resource. It differentiates from siblings like get_ticket (single ticket) by implying an aggregate list of all relevant tickets.

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

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

The description implies usage for viewing all support tickets, but it does not explicitly mention when to use this over alternatives like get_ticket or reply_ticket. No exclusions or alternative guidance is provided.

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

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

With no annotations, the description carries full burden. It discloses that deleted/cancelled are excluded and what to do if a server is missing. While it implies read-only behavior, it doesn't explicitly state no side effects, but it's sufficient for agent decision-making.

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

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

Two sentences, no filler, all information is critical. Highly front-loaded with the key purpose and then usage tips.

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

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

Given the tool has no parameters and no output schema, the description fully covers the return set, exclusions, and downstream usage. An agent has all needed information to decide when to call and how to use results.

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

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

There are no parameters, and schema coverage is 100%. The description adds value by clarifying what the tool returns (active servers and their ids) and how to use the returned data, which exceeds the baseline expectation.

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

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

The description clearly states the tool lists ACTIVE VPS services (active, provisioning, suspended) and explicitly excludes deleted/cancelled. This distinguishes it from sibling tools like get_vps_status or get_vps_metrics, which operate on individual servers.

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

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

The description provides explicit guidance: use the id as service_id for management tools, and if a server is missing, it has been deleted—do not query its status. This helps the agent decide when to use this tool and when to avoid further actions.

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

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

No annotations are provided, so the description carries the full burden. It discloses the key behavior of returning a bearer token and the critical caveat that register_account users have no password by default. It doesn't mention error cases or whether login invalidates existing tokens, but the main unexpected behavior is clearly explained.

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

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

The main action is front-loaded in the first sentence, and the NOTE adds necessary edge-case handling without fluff. Every sentence serves a function.

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

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

For a simple two-parameter tool with no output schema, the description is fully sufficient. It clearly defines the operation, the return value, and the known edge case concerning accounts created via register_account.

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

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

Schema description coverage is 0%, so the description must add meaning. It states that email and password are the login credentials, and the note explains the case where a password may not exist, which directly helps the agent decide whether to pass this parameter or use an alternative.

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

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

States a specific verb ('Log in'), the required credentials (email + password), and the output (bearer token). It also distinguishes itself from register_account and set_password by explaining that registered accounts may not have a password.

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

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

Explicitly explains when to use this tool (when you have email + password) and provides clear alternatives when you don't: reuse the registration token, call set_password, or use the OTP flow. This is a concrete when/when-not proper condition and mentions sibling tools by name.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and fully meets it. It reveals that payment may not succeed immediately, that the server may be provisioning asynchronously, that Windows plans ignore ssh_key and require BYOL/RDP, and that an unpaid invoice is returned when balance is insufficient.

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

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

The content is front-loaded with the core action, then uses a compact bulleted branch structure for the response flow. Each sentence adds necessary operational information (sourcing, Windows exception, payment branching), so the length is justified by the tool's complexity.

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

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

Given that there is no output schema and no annotations, the description covers the essential post-order behavior: it tells the agent what `paid_from_balance: true` and `false` mean, how to poll for activation, and how to recover from insufficient balance. It also points to get_vps_status for the RDP access details, closing the loop for Windows orders.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. It defines `product` as a plan slug, `os_id` as a plan-specific image id, and `ssh_key` as a public key strongly recommended for key-based root login, plus the Windows-specific caveat that ssh_key is ignored. Only `hostname` is left largely self-explanatory.

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

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

The description opens with a direct verb and resource, 'Order a VPS,' and immediately defines the two required inputs (`product` as a plan slug and `os_id` as an OS id from that plan's images), making the action unambiguous. This clearly separates it from sibling management tools like power_vps, reinstall_vps, and cancel_service by focusing on provisioning a new server.

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

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

It explicitly tells the agent where to source values: `product` from list_plans and `os_id` from that plan's images. The branching instructions spell out exactly when to poll get_vps_status (paid_from_balance true) and when to call pay_invoice or topup_balance then re-order (paid_from_balance false), leaving no ambiguity about follow-up actions.

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

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

Discloses return of checkout_url and automatic settlement, but doesn't cover errors or idempotency.

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

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

Two sentences, no fluff, front-loaded with action and result.

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

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

Covers action, return, and side effects adequately for a simple tool; missing error handling details.

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

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

No description for the invoice_id parameter despite 0% schema coverage; description doesn't elaborate on its meaning even though it's inferable.

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

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

Clearly states it initiates payment for an owned unpaid invoice, distinguishes from siblings 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.

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

Implicitly requires invoice to be owned and unpaid, but lacks explicit when-not-to-use or alternatives.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. While the action names imply state changes, the description does not mention that stopping/rebooting will interrupt services, potentially cause data loss, or require appropriate permissions. The agent is left without warning about the destructive nature of these operations.

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

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

The description is a single, concise sentence that front-loads the verb and lists the actions. There is zero redundancy, and every word earns its place.

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

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

For a simple power-control tool, the description covers the core action but omits crucial context: it does not mention that service_id is required to identify the target VPS (despite the schema marking it optional, logically it should be provided). No output schema exists, so return format is not specified, but the description also fails to note whether the operation is synchronous or asynchronous or what happens on success/failure. This leaves some ambiguity for the agent.

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

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

Schema coverage is 50%: service_id is well-documented in the schema, but action has no schema description. The tool description partially compensates by listing the enum values (start, stop, reboot), which adds clarity to the action parameter. However, it does not elaborate on service_id beyond what the schema already provides.

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

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

The description uses a specific verb ('Power-control') and names the resource (VPS) and lists the exact actions (start, stop, reboot). It is unambiguous and clearly distinct from any sibling tool; no other tool appears to handle power operations.

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

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

The description clearly indicates when to use this tool: whenever a VPS needs to be started, stopped, or rebooted. There are no direct alternative tools for this action, so no exclusions are necessary. The usage context is implied strongly 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.

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

With no annotations, the description carries the behavioral disclosure burden. It reveals critical runtime facts: a bearer token is returned, the token is the only credential, it must be sent as Authorization header on every following request, and the account has no password until set_password is called. It does not mention duplicate-email behavior or response shape, but the core safety information is covered.

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

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

The description is compact but information-dense. Each sentence earns its place: creation purpose, token safety warning, authentication instruction, and the set_password fallback. The most important operational guidance is front-loaded around the token.

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

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

For a simple 3-parameter account creation tool, the description covers the key operational points: what is created, how the returned token is used, how to protect it, and how to get a fallback credential. Given the annotations are absent and there is no output schema, the description is remarkably complete.

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

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

Schema description coverage is 0%, so the description needs to add meaning. It only names the three parameters without explaining their semantics beyond what the schema already encodes. The schema already provides types, requiredness, and string constraints. The description lacks additional guidance like email uniqueness or casing behavior, so it adds minimal parameter-level value.

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

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

The description states a specific verb and resource: 'Create a new EQVPS customer account'. It also lists the exact input fields (first_name, last_name, email). This clearly distinguishes the tool from siblings like login, set_password, and whoami.

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

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

It explicitly explains when to use this tool and how it behaves: no password or human step is needed, and the returned token is the only credential for subsequent requests. It names an alternative fallback path (set_password) for enabling password login, giving the agent clear routing guidance.

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

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

No annotations are provided, so the description carries the burden. It clearly discloses the destructive nature (all data lost) and the mandatory confirmation step, plus async execution. It doesn't detail other side effects like downtime, but the critical safety information is present.

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

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

Two sentences, no fluff. The destructive warning is front-loaded, and each sentence adds necessary guidance. Very efficient.

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

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

For a destructive reinstall operation, the description covers the required confirmation, the parameters, and the asynchronous behavior with polling instruction. With no output schema, it doesn't specify return values, but it tells the agent what to do next. Complete enough.

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

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

Schema covers only service_id with a description (33%). The description adds crucial semantics for os_id (from list_plans) and confirm (exact hostname or 'DELETE'), effectively compensating for the missing schema descriptions on those parameters.

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

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

The description clearly states the tool's purpose: wipes and reinstalls the VPS with a given OS image. It references related tools (list_plans for os_id, get_vps_status for hostname) and distinguishes itself from other VPS management tools by its destructive nature.

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

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

Explicitly instructs that the agent must confirm with the human, requires confirm to be exact hostname or 'DELETE', and explains async provisioning with polling guidance. This gives clear when-to-use and how-to-use instructions.

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

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

No annotations are provided, so the description bears full responsibility for disclosing behavior. It only says 'post a reply', which implies a write operation, but does not mention side effects such as email notifications, status changes, or whether the reply is visible to the customer. It also omits any authentication or ownership requirements beyond 'one of your tickets'.

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

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

Two short sentences, front-loaded with the action 'Post a reply' and containing no redundant information. Every word adds value.

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

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

For a simple two-parameter action without output schema or annotations, the description covers the core action and the source of the identifier. However, it lacks details about expected behavior, return values, or errors, which could be important for an agent invoking the tool autonomously.

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

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

The input schema provides no descriptions for the two parameters (0% coverage). The description compensates partially by explaining that ticket_code should be obtained from create_ticket or list_tickets, but it gives no additional meaning for 'message' beyond being a reply.

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

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

The description uses a specific verb 'reply' and clearly identifies the resource as a support ticket. It distinguishes the tool from siblings like create_ticket, close_ticket, and list_tickets by specifying the reply action, and it names the required input source.

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

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

It provides clear context for when to use the tool: to post a reply on an existing ticket, and explicitly specifies that the ticket code must come from create_ticket or list_tickets. It doesn't mention exclusions or alternatives, but the usage context is clear enough.

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

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

With no annotations present, the description carries full responsibility, and it delivers: it discloses live VM mutation, no reboot, ~10-30s propagation, old password invalidation, and the fact that the new password is not returned in this response. This is far more transparent than typical mutation-tool descriptions.

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

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

Every sentence adds necessary operational detail: timing, side effects, human-confirmation requirement, when-not-to-use guidance, and how to retrieve the new password. The critical scoping constraint is front-loaded.

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

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

For a destructive live-system mutation with no output schema and no annotations, this description is unusually complete. It covers confirmation requirements, behavior, timing, the special confirm value, the alternative tool, and post-call retrieval of the new password via get_vps_status.

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

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

The required confirm parameter is given precise meaning: 'exact hostname (from get_vps_status) or DELETE'. The schema covers service_id semantics, but the description does not explain how service_id relates to the target VM or when it is needed, leaving a small gap.

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

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

The description uses a specific verb ('rotate') and a clear resource ('root password'), and explains the effect on the LIVE VM. It is easy to distinguish from sibling tools like get_vps_status or set_password because it emphasizes generated-password rotation and live application.

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

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

The description explicitly states when to use this tool ('ONLY if the password was lost') and when NOT to use it ('NOT because SSH was not instant on a fresh order'). It also names the correct alternative (poll get_vps_status with reveal:true) and requires human confirmation.

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

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

No annotations provided, so description carries full burden. Mentions notification to the other side and two scenarios. However, does not disclose idempotency, error handling, or authorization requirements (e.g., who can revoke). Adds some value but leaves gaps.

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

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

Two sentences, front-loaded with the core action, no fluff. Every sentence serves a purpose: definition, notification, and guidance on finding the id.

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

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

Tool is simple (1 param, no output schema). Description covers action, use cases, notification, and id retrieval. Missing details on result, idempotency, or permissions, but adequate for straightforward revoke operation.

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

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

Schema description coverage is 0%, and description does not compensate well. Only states 'by its id' without explaining the parameter's meaning, format, or source directly. Relies on name 'delegation_id' being self-explanatory, but more detail would help.

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

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

Clearly states the action (revoke), resource (delegation), and two specific use cases (owner revokes, delegate declines). Distinguishes itself from sibling tools like accept_delegation and list_delegations.

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

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

Explicitly tells the user to use list_delegations/list_delegated_to_me to find the delegation id, providing a clear precondition for usage. Lacks explicit when-not-to-use guidance, but the context is straightforward.

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

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

With no annotations provided, the description carries the full burden and does disclose the two most important behavioral traits: input must be a valid DNS labelebbe and the change only takes effect on reboot/rebuild. It does not cover permission requirements or error behavior, but the critical operational surprises are surfaced.

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

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

The entire description is a single focused sentence with the action front-loaded and constraints placed in a parenthetical. There is no wasted wording or redundancy with schema fields.

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

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

For a two-parameter setter with no output schema isolate, the description together with the schema gives the agent enough to call the tool correctly: required hostname, condition, and result timing. It omits return-value details and error handling, but these are minor for such a simple mutation.

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

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

Schema coverage is only 50% because the required 'hostname' property lacks a description. The description compensates by adding the 'valid DNS label' constraint. The optional 'service_id' parameter is already fully described in the schema, so the description meaningfully fills the remaining gap.

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

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

The description uses a specific verb ('Set') and resource ('VPS hostname') and immediately adds a validation constraint and timing note, making the operation unmistakable. It is clearly distinct from sibling tools like set_password 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.

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 the agent needs to change a VPS hostname — and provides a key timing context ('applied on next reboot/rebuild') that informs the agent that the change is not immediate. However, it does not explicitly name alternatives or provide exclusion conditions, so it stops short of full routing guidance.

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

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

With no annotations, the description carries full behavioral disclosure. It reveals that accounts created via register_account have no password by default, that the bearer token is the primary credential, that this is a one-time activation, that it validates password composition, and that already-set passwords produce a 409. This is strong transparent behavior even though it does not mention success response shape.

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

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

Each sentence earns its place: one defines the target account, one explains the default state, one gives the intended usage, one states parameter constraints, and one covers the error condition and alternative. It is dense but tight and well-structured.

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

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

For a single-parameter tool with no output schema, the description is essentially complete. It tells the agent how to authenticate the operation implicitly via bearer token, why the tool exists, what the parameter needs, and what happens on repeated attempts. Nothing critical is missing for generating a correct call.

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

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

Schema coverage is 0%, so the description must compensate for the undocumented 'password' parameter. It does, by stating the format ('min 8 chars, letters+numbers') and clarifying that no current password is needed for the first call. This adds meaning beyond the schema's bare minLength constraint.

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

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

The description uses a specific verb ('Set a password') with a clear target resource ('THIS account' owned by the bearer token). It explains the contextual purpose (creating an email+password login recovery method) and distinguishes itself from the later use case of changing an already-set password.

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

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

It explicitly states when to call this tool ('Call this ONCE'), what passwords the tool needs versus does not need ('no current password the first time'), and what to do if the password already exists ('use change-password instead'). This gives clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description discloses key behaviors: creating an invoice, returning a checkout URL, automatic credit on confirmation, and server-side min/max enforcement.

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

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

The description is three concise sentences, front-loading the main action and adding necessary constraints without redundancy.

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

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

For a single-parameter tool with no output schema, the description covers the core workflow, constraints, and output, though it omits error handling details.

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

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

The schema has 0% description coverage for the 'amount' parameter, but the description adds crucial semantics: currency is USD, and min/max are enforced server-side.

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

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

The description clearly states that the tool creates a top-up invoice and returns a checkout_url for PayRam crypto checkout. It specifies the credit automation, currency (USD), and server-side enforcement of limits.

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

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

The description mentions the 'only one unpaid top-up at a time' constraint but does not explicitly guide when to use this tool vs alternatives like 'pay_invoice' or other billing tools.

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

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

With no annotations, the description bears the full burden. It discloses that the tool returns profile data and can verify token validity. No side effects are implied, and the description is accurate and transparent.

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

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

Two concise sentences, front-loaded with the main action and followed by usage guidance. No unnecessary words.

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

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

For a no-parameter tool with no output schema, the description is complete: it states what it returns, the purpose, and a use case. Sibling tools are diverse, and this stands alone.

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

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

The tool has zero parameters, so the baseline is 4. The description adds value by specifying the return fields (id, name, email), compensating for the lack of an output schema.

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

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

The description clearly states the tool returns the authenticated account profile with specific fields (id, name, email). It uses a specific verb and resource, and the tool is distinct from siblings like 'login' or 'get_balance'.

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

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

The description explicitly states when to use the tool: 'to verify the bearer token is valid.' This provides clear context, though no exclusions or alternatives are mentioned, which is acceptable for a simple self-identity tool.

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