AnchoredIP

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

With no annotations, the description carries full behavioral burden and does so thoroughly. It discloses failure modes (source aborts and deletes the interface on macOS), side effects (full claims the default route), and interactions with existing VPNs. This is far beyond minimal disclosure.

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

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

The description is well-structured, front-loaded with the core purpose, and every sentence earns its place. The mode-by-mode breakdown is dense but highly informative, with no fluff or repetition.

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

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

For a tool with 5 params, no annotations, and no output schema, the description is remarkably complete. It covers routing modes, platform compatibility, VPN interactions, transport selection, and parameter semantics. The return value ('WireGuard configuration') is stated, making the tool fully understandable.

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

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

Schema description coverage is 100%, but the description adds substantial meaning beyond the schema. It explains the real-world implications of routing_mode, clarifies the destinations parameter's requirements, and contextualizes transport choices. The schema lists fields; the description explains how and why to choose.

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+resource: 'Provision a peer and return its WireGuard configuration.' This clearly distinguishes the tool from siblings like revoke_tunnel and order_lease, and the routing mode discussion further clarifies the tool's scope.

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 each routing mode, including platform limitations (source is Linux-only), conflict scenarios (full cannot run beside an always-on corporate VPN), and user guidance ('Ask the user which partner requires the address rather than guessing a range'). This is exemplary usage guidance.

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

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

With no annotations provided, the description carries the burden of revealing behavior. It explains what information the tool returns (active status, addresses, tunnels, renewal time), which is useful context. However, it does not explicitly state whether the operation is read-only, whether any side effects occur, or what authentication requirements exist beyond the access_token parameter. This is a moderate amount of disclosure, but gaps remain.

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 efficiently conveys the tool's purpose and the key aspects of the returned data. It is front-loaded with 'Everything about one lease' and avoids any unnecessary words. Every word earns its place, making it a model of conciseness.

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 low complexity (one parameter, no output schema), the description adequately covers what the tool does and what it returns. It enumerates the specific data points (active, addresses, tunnels, renews) without needing to detail an output format. It could be improved by explicitly stating that it is a read-only status lookup, but overall it is sufficiently complete for this tool's simplicity.

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 sole parameter access_token has 100% schema description coverage, so the schema already fully explains it. The tool description does not add further parameter-specific context, but given the high coverage, the baseline of 3 is appropriate. No additional semantic meaning 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 indicates this is a status/retrieval tool for a single lease, enumerating the specific aspects it covers (active, addresses, tunnels, renews). It distinguishes itself from sibling tools that perform actions like create or renew by implying a read/query operation. The lack of an explicit verb like 'get' keeps it from a 5, but the meaning is unambiguous.

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

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

The description implies usage when you need all details about a lease, and the sibling list (order_lease, renew_lease, create_tunnel) suggests this is the query counterpart. However, there is no explicit statement of when to use this tool versus alternatives or what conditions warrant it. The usage is easily inferred but not directly stated, so a 3 is appropriate.

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

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

The description adds valuable behavioral context by stating that prices are 'never hardcoded' and should be read from this tool, indicating live data. Without annotations, it covers the read-only nature implicitly, but it does not disclose rate limits, response pagination, or exact return structure.

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

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

The description is two short sentences that immediately convey the core purpose without any redundant information. It is front-loaded with the main idea and every phrase 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 zero-parameter list tool, the description covers the essential output: plans, prices, and payment methods. The lack of an output schema means the exact response format is unspecified, but the description is sufficient for a simple catalogue.

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 has no obligation to explain parameter semantics. The baseline of 4 applies because there is nothing for the description to add beyond the schema.

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

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

The description clearly identifies the tool as a catalogue of plans with live prices and acceptable payment methods, which distinguishes it from sibling tools that manage tunnels or leases. While the verb is implicit ('catalogue' implies listing), it is specific and unambiguous.

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

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

The phrase 'read them here' implies this tool is the source for plan pricing and details, giving some usage direction. However, it does not explicitly mention alternatives or when not to use it, such as referencing lease_status for active leases.

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 and does well: it discloses activation behavior (trial immediate, paid pending), return of payment details, lack of auth requirements, and the second-trial refusal rule. This goes far beyond a generic 'place an order' statement.

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 sentences, each earning its place: the first states the action, the second explains behavior, the third gives a key constraint. Front-loaded with 'Place an order' and no redundant 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 4-parameter tool with no output schema, the description covers key behavioral aspects: trial vs paid outcomes, lack of required account/card, and the restriction on second trials. It doesn't detail return values fully but mentions payment details for paid plans, and likely relies on sibling tools like lease_status for follow-up.

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% (plan, country have descriptions; organization_name, billing_email do not). The description adds meaning for billing_email by linking it to the trial-refusal rule, and for plan via trial/paid distinction, but organization_name remains unexplained. It partially compensates but not fully.

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 'Place an order' and immediately clarifies it's for a lease/plan by discussing trial and paid plans. It distinguishes from siblings like list_plans and renew_lease because ordering is the primary purchase action, though it doesn't explicitly name alternatives.

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 clear context: trial activates immediately, paid stays pending, no account/card needed, and a second trial is refused—ordering a paid plan instead. This implies when to choose this tool over renewing or listing, but doesn't name sibling tools explicitly.

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 and excels: it discloses address preservation, trial-to-plan behavior, planless return of eligible plans, and idempotency ('Pressing it twice quotes the same reference rather than raising a second invoice'). This goes well beyond basic function.

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 front-loaded with the core action and then adds logically ordered details on trial, plan, and idempotency. Every sentence contributes; however, it is moderately long, so not a perfect 5.

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 tool with no output schema or annotations, the description covers key behavior, edge cases, and idempotency, making it largely complete. It doesn't detail error conditions or return formats, but for this simplicity level it's adequate.

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 both parameters with helpful descriptions (e.g., plan defaults, access_token provenance). The description adds extra semantics: the plan behavior when omitted on a trial and the idempotency consideration, which are not in the schema. This justifies a score above the 3 baseline.

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

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

The description opens with 'Raise an invoice for another term and keep the same addresses' — a specific verb and resource that clearly distinguishes renewal from sibling tools like order_lease or lease_status. It also ties to the trial-to-paying transition, making the purpose unambiguous.

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

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

It provides contextual guidance: 'This is how a trial becomes a paying customer' and explains when plan is needed and what happens if omitted. While it doesn't explicitly contrast with alternatives, the trial-to-payment scenario gives clear use case. Could be improved by naming when not to use, but overall strong.

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. It clearly states that revoking stops inbound connections, frees the allowance, and is irreversible except by bringing up a new machine. This discloses destructive and irreversible behavior beyond the schema.

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 sentences, each adding distinct value: purpose, motivating scenario, and behavioral consequence. It is front-loaded and wastes no 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?

The description provides a complete picture of the tool's role within the lifecycle: when to use it, what it does, and what it cannot do. Even without an output schema, the agent has enough context to decide and 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?

Both parameters (tunnel_id and access_token) are fully described in the schema with references to lease_status and order_lease. The description adds no param-level detail, and the 100% schema coverage makes a baseline 3 appropriate.

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

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

The description opens with 'Retire a peer and hand its slot back to the plan's allowance,' using a specific verb and resource. It also clarifies the consequence (stopping inbound connections) and distinguishes itself from lifecycle siblings like create_tunnel and renew_lease.

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 a concrete scenario—short-lived workers consuming the allowance—and explains why failing to revoke blocks future provisioning. It also notes that 'promoting another' cannot undo the revocation, effectively steering agents away from an alternative, though no explicit tool name is given.

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 disclosing side effects. It explains that stopping is not a cancellation and that the lease continues to the end of the paid period. It also notes the action is reversible ('the same call turns it back on'). This adds meaningful context about behavior, though it doesn't detail error cases or idempotency 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 three sentences, each adding essential value: the core action, the card-only condition, and the non-cancellation clarification. It is front-loaded with the primary behavior and contains no filler or repetition.

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

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

For a simple boolean toggle with two well-documented parameters, the description covers the essential context: what it does, when it applies, and what it does not do. It omits potential error scenarios or response details, but given the tool's low complexity and lack of output schema, this is a minor gap.

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

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

The schema already describes both parameters at 100% coverage: 'enabled' (false stops the next charge, true resumes it) and 'access_token' (returned by order_lease). The description reinforces the meaning of 'enabled' by paraphrasing stop/start, but it does not add significant new information beyond what the schema provides. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's function: 'Stop this lease charging the customer's card again, or start it again.' It uses specific verbs (stop/start) and identifies the resource (lease card charges). It also distinguishes from siblings by clarifying it's not a cancellation and that it applies only to card subscriptions, which is a unique scope.

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 clear context for when to use the tool: only for card subscriptions, not bank transfers ('Only a card subscription can be stopped — a bank transfer is a payment the customer sends us, so there is nothing of ours to cancel'). It also explains behavioral boundaries ('Stopping is not a cancellation'). However, it does not explicitly name alternative sibling tools for other lease actions, so it lacks full explicit alternative 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 bears the full burden of behavioral disclosure. It adds a latency guarantee ('Live within a second') and mentions the removal behavior, but the removal behavior is already in the schema. It does not disclose prerequisites, side effects, reversibility, or error conditions, leaving significant 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?

The description is exceptionally concise, consisting of two short sentences. It front-loads the purpose and adds a behavioral nuance, with no unnecessary words or repetition.

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

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

For a 3-parameter tool with no annotations and no output schema, the description is too minimal. It omits essential context such as the requirement for an active lease, what happens if the address is not on the lease, potential failure modes, and the meaning of the return value. The latency note is helpful but not sufficient for complete context.

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 67% (hostname and access_token have descriptions, address does not). The description adds no parameter-specific meaning beyond the schema, and the undocumented 'address' parameter remains unexplained. The generic 'address' mention in the description does not clarify its format or 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 'Publish' and clearly identifies the resource as 'a PTR record for an address on the lease.' This distinguishes it from sibling tools that deal with tunnels, leases, or autorenewal, making the tool's purpose immediately clear.

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 context (setting reverse DNS on a lease) but offers no explicit guidance on when to use this tool versus alternatives. There are no exclusions or alternative recommendations, so the usage guidance is only implicit.

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