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

Far exceeds the annotations: hard-cap guarantee that the rental is never charged above budget_micro, metering only starting once the machine is verified ready, retry safety via idempotency_key, and the explicit fact that the tool spends money and is refused unless the server started with AMPLERUN_MCP_ALLOW_SPEND=1. The destructiveHint=true annotation is corroborated rather than merely repeated.

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?

Dense and front-loaded: purpose first, then cost/idempotency behavior, then the spend gate. It is longer than strictly necessary (the return-field enumeration partly duplicates its own later statements) but every sentence carries real 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 write tool with no output schema, the description covers the return shape (rental_id, state, quote, fee_split, idempotency_key), the cost model, the idempotency contract, the auth prerequisite, and the follow-up sibling. An agent has everything needed to call it 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 100%, so the schema already documents all seven parameters including budget_micro's cap semantics and idempotency_key's retry behavior; the description largely restates these. Baseline 3 is appropriate since the description adds little parameter detail beyond what the schema carries.

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 and resource ('Rent a GPU'), and further pins the semantics: quotes the template on the offer AND reserves the machine in one step. This distinguishes it from the sibling get_quote (quote only) and get_rental (observe only).

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 contrasts the one-step quote+reserve with the quote-only sibling and points to get_rental for state, and it explicitly states the spend gating condition (AMPLERUN_MCP_ALLOW_SPEND=1). It does not literally say 'use get_quote first if you only want a preview', so it stops short of a full when/when-not routing statement.

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?

Annotations already declare non-read-only, non-idempotent, open-world behavior, and the description adds the traits the annotations cannot convey: five-minute validity, single-use, that signing constitutes acceptance of a named Terms version, and the required signing scheme. The 'single use' note coherently explains the idempotentHint=false annotation rather than contradicting it.

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

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

Front-loads 'Step 1 of 2', then the return, then the constraints, then the required sequence. Every clause (TTL, single-use, exact signing method, key-safety warning) earns its place with 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?

No output schema exists, yet the description explains exactly what is returned (a SIWE message), how long it lives, and how to consume it, plus the security constraint and the handoff to the sibling tool. An agent has everything needed to call it 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?

With one parameter and 100% schema description coverage, the schema already documents the address and its server-wallet default. The description adds genuine semantic value by specifying it must be 'a wallet address this agent controls', narrowing how the parameter should be chosen beyond the regex/format in 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?

States a specific verb and resource: returns an EIP-4361 (SIWE) message tied to the agent's own account registration. It positions itself as 'Step 1 of 2' and names register_agent_account as the follow-up, so it is unambiguous against its only sibling.

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?

Gives explicit ordering (step 1 of 2), the exact next action (sign with personal_sign/EIP-191, then call register_agent_account with message and signature), and a hard exclusion ('Never send a private key to any tool'). Nothing about when to use it is left to inference.

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?

Annotations already cover readOnlyHint, idempotentHint and destructiveHint=false, so the description's 'Read-only' is partly redundant. It earns credit by disclosing the auth prerequisite (AMPLERUN_API_KEY) and by enumerating what the response breaks down into, which the structured fields do not provide.

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?

One dense sentence that front-loads the asset and unit (micro-unit strings) before the field breakdown. Every clause carries information; no filler or restatement of the tool name.

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 parameters and no output schema, the description carries the return-shape burden and does so reasonably, naming units and categories plus a 30-day spend window and the auth requirement. It stops short of stating pagination/format details or precision semantics of micro-units, so a token of clarification 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 takes zero parameters, which is the baseline-4 case; nothing about parameter meaning needs explaining. The description correctly does not invent parameters and focuses on the return payload instead.

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 (Get) and resource (AmpleRun account balances), and enumerates the exact assets (USDC/USDT) and balance categories returned. An agent can distinguish this from siblings like get_quote or get_rental 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 listed balance categories (spendable, held, pending, disputed, withdrawable) imply when an agent would want this tool, i.e. checking funds before renting or withdrawing. However, there is no explicit when-to-use statement, no exclusions, and no pointer to any alternative sibling such as top_up or get_quote.

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?

Adds substantial context beyond the annotations: the quote is free and non-binding, valid only 60 seconds, nothing is reserved or charged, and it requires AMPLERUN_API_KEY with the renter scope. It also discloses the return payload (raw API response plus fee_split, platform_fee_bps, host share). This is consistent with readOnlyHint=true since no state is mutated.

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?

Front-loaded with the core action and tightly packed, but the final sentences covering auth scope and return shape make it longer than strictly necessary for a quote call. Every sentence still carries information, so only minor trimming is possible.

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?

No output schema exists, yet the description explains the return shape (raw API response plus fee_split breakdown). Combined with the auth requirement and non-commitment guarantee, an agent has everything it needs to call this 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 100%, so every parameter is already documented. The description restates the budget_micro cap ('capped by budget_micro') and mentions offer/template sourcing, but adds no syntax or semantics beyond what the schema provides. Baseline 3 applies.

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 and resource ('Price a rental without committing: creates a free, non-binding AmpleRun quote') and immediately distinguishes itself from create_rental, which does the reserving. An agent can tell exactly what this does versus its siblings.

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 frames the call as optional ('this step is optional') and names create_rental as the alternative that quotes again when it reserves. The when-to-use relationship between the two tools is fully spelled out.

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?

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new behavioral context: access data (endpoints, SSH host-key fingerprint, ready-made command, per-rental API key) is only returned while RUNNING or during a limited post-STOPPED window. That temporal constraint and the disclosure of sensitive credential material go well beyond the structured fields and directly affect how an agent should call and handle the result.

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?

Front-loads the core resource and its fields, then adds the conditional access behavior and the sibling pointer. Dense but every clause carries information; only the run-on sentence about access is slightly awkward to parse.

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?

There is no output schema, so the description carries the full burden of describing the return shape, and it does so field-by-field, including the conditional access payload. An agent knows what it will receive and under what runtime conditions.

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?

One parameter with 100% schema coverage (UUID pattern and provenance already documented in the schema). The description adds meaning by naming the upstream tools that produce the id, which is useful routing context but not syntax 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?

States a specific verb+resource ('Get one AmpleRun rental by rental_id') and immediately enumerates the returned fields (state, cumulative charge, rate, funded-through time). It is clearly distinguishable from list_rentals, which it names as the source of ids.

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 tells the agent where to get the required rental_id ('list_rentals finds rental ids') and when access fields are available (while RUNNING, or read-only for a limited window after STOPPED). It lacks explicit exclusions or a statement of what to use instead when no access is needed, so it falls short of a full when/when-not treatment.

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?

Annotations already declare readOnly/non-destructive/idempotent, and the description reinforces this with 'It runs nothing itself', then adds behavior the annotations cannot convey: root requirement, owner consent needed, and that listing depends on approval via the printed approve_url. That is genuinely additive safety context.

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 tight sentences, front-loaded with purpose, then return values, then the safety condition. No filler and no repetition of the title.

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 0-param, no-output-schema tool this covers everything an agent needs: what it does, that it is side-effect free, what it returns, and the consent/approval gate before the returned command is run.

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 takes zero parameters, so the schema has no semantics to add; the baseline for a 0-param tool applies. The description correctly implies no input is required to obtain the installer instructions.

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 and resource ('Explains how to add the GPU of the machine this agent runs on to AmpleRun') and specifies the return payload (installer command, steps, earnings links). It is unmistakably distinct from the rental/account siblings in the list.

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?

Gives a clear precondition chain: ask the machine's owner before running the installer because it needs root, and the owner must approve via approve_url or nothing is listed. It stops short of naming alternatives (e.g. what to use if the owner declines), but the context of use is 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?

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds genuinely non-obvious behavior: ordering is by id, not time, and pagination is driven by next_cursor, which an agent could not infer from the annotations.

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 clauses front-load what is returned, then ordering, then the sibling pointer. Every sentence earns its place with 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?

With no output schema, the description takes responsibility for the return fields and pagination model, and it does so. An agent has everything needed to call and interpret this listing 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 coverage is 100%, with both limit and cursor fully documented, so the baseline is 3. The description's 'page with next_cursor' merely restates the schema's cursor semantics rather than adding format or edge-case detail.

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 and resource (list the account's rentals) and enumerates the fields returned (state, charge, rate, funded-through time). It explicitly differentiates from the sibling get_rental, so an agent can distinguish the two without opening a 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 closing sentence names the alternative (get_rental for one rental's details/access), which tells the agent when to prefer this listing tool. It stops short of explicitly stating 'use this to browse all rentals', so it is strong but not a full when/when-not statement.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered; the description adds the meaningful auth fact that no API key is needed. It also enumerates returned fields and pagination (next_cursor), giving behavioral context beyond annotations, though no rate limits or ordering guarantees.

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 tight sentences, front-loaded with the operation and object, then returns, then the safety/auth note and sibling pointer. Slightly dense but every clause carries information; nothing is 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?

With no output schema, the description compensates by listing the returned fields and the pagination cursor, and it covers auth and read-only nature for a 4-param list tool. An agent has everything needed to call and interpret it.

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% and each parameter (kind, limit, cursor, gpu_vram_gib) is documented in the schema itself with enums and units. The description's enumeration (id, slug, kind, engine, VRAM, GPU count) describes return values rather than adding parameter meaning, so baseline 3 applies.

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+resource (List published AmpleRun templates) and immediately defines what a template is, so the agent understands the domain object, not just the operation. It also contrasts with the sibling search_offers, making the distinction clear without opening schemas.

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?

Gives context ('no API key needed') and routes the agent to search_offers for finding machines, which is a useful alternative pointer. However, it does not state explicit when-not conditions or prerequisites (e.g. filtering behavior, whether unauthenticated listings are scoped).

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?

Annotations already mark this as non-read-only, open-world, and non-idempotent. The description adds real behavioral context beyond them: the API key is shown once and must be kept secret, the same wallet re-registers to the same account but yields a new key (consistent with idempotentHint=false), and no free credit is granted. It does not cover permissions or rate limits, so not a 5.

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?

Front-loads the stage marker and core action, then packs key constraints (key secrecy, idempotent re-registration, credit requirement, scopes default) into tight sentences. No filler; every clause carries information an agent needs.

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-param mutation tool with no output schema, it covers the return value (API key), the prerequisite sibling call, and the credit prerequisite. Missing only secondary details such as error handling on invalid signatures or what happens if the wallet is already registered under different agent metadata.

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 50%, but the description compensates on the ambiguous parts: scopes default to ["renter"] and adding "host" enables hosting, and it clarifies that message/signature come from the challenge tool. The nested agent object's fields (name, vendor, model, homepage, operator_contact) rely entirely on the schema, leaving a modest 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?

States a concrete verb+resource ('Opens an AmpleRun account for this AI agent') with its distinguishing properties: agent-created, wallet as verified payout wallet, returns an API key. It also positions itself explicitly as 'Step 2 of 2', cleanly separating it from the sibling get_agent_account_challenge (step 1).

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?

Gives the prerequisite flow clearly ('Pass message and signature from get_agent_account_challenge') and shifts expectations about credit ('no free credit: renting needs a deposit first'). It does not explicitly state when-not to call or what to do if the challenge is missing/expired, 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?

Annotations already cover read-only/idempotent/openWorld, but the description adds non-obvious behavior: no API key needed, client-side filtering that can yield fewer than `limit` matches, the meaning of `scanned`, cursor continuation, and price units. This is exactly the extra context that helps an agent interpret results.

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?

Front-loaded with purpose and filtering model, then pagination, pricing, template fit, and safety in two tight sentences. Every clause carries information; 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?

No output schema exists, and the description compensates by explaining the return shape: cheapest-first ordering, price units, `scanned`, `next_cursor`, and the per-offer `fit` object with template. An agent has everything needed to page and interpret 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?

Schema coverage is 100%, so per-parameter docs already exist (baseline 3). The description goes further by explaining the semantic split between server-side and per-page filters and by clarifying that prices are whole-machine micro-units including fees, which the schema does not state.

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 and resource ('Search GPU machines that can be rented now on AmpleRun'), which clearly distinguishes it from siblings like list_templates and create_rental. The purpose is immediately graspable without opening the 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?

Gives strong operational context: which filters run server-side vs per-page, how to continue with next_cursor, and that template adds fit info. It stops short of explicitly naming alternatives or when-not conditions (e.g., 'use create_rental after selecting an offer'), so it isn't a full 5.

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?

Adds substantial context beyond the annotations: files remain reachable read-only for a limited retrieval window, the operation is safe to repeat, the return payload (rental_id plus STOPPING or later state), and the AMPLERUN_MCP_ALLOW_SPEND=1 gate that otherwise refuses the write. This is exactly the destructive/auth behavior an agent needs and annotations alone cannot convey.

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?

Four compact sentences, front-loaded with the core effect before the retrieval-window caveat and the auth gate. Each sentence carries non-redundant information, though the return-value sentence is slightly terse relative to the rest.

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, gated mutation with no output schema, the description covers effect, consequence window, idempotency, return shape, and the auth requirement. Nothing an agent needs to invoke 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?

Schema description coverage is 100%, so rental_id, reason, and idempotency_key are already fully documented in the schema. The description adds nothing parameter-specific, so the baseline 3 applies.

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+resource ('Stop an AmpleRun rental') and immediately scopes the effect: the workload and its metering end. It is clearly distinguishable from siblings like get_rental or list_rentals, which are read 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?

Usage is implied by the verb and the noted idempotency ('Stopping again is harmless'), but it never explicitly says when to use this versus checking state with get_rental first, nor any prerequisites beyond the env-var gate. Adequate but leaves the when-to-use inference to the agent.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds meaningful non-annotation context: the server holds no wallet and pays nothing, and payment only occurs if an operator configures AMPLERUN_MCP_WALLET_KEY_FILE and allows spending. That caveat is genuinely useful behavioral disclosure.

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

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

Three dense sentences, front-loaded with the purpose and followed by the usage flow and the wallet caveat. Every sentence carries information, though the parenthetical SDK reference and final sentence are somewhat wordy for an otherwise tight definition.

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?

Despite no output schema, the description enumerates what is returned (network, USDC contract, treasury payTo, amount, EIP-712 domain) and explains the downstream signing/POST step. Combined with full annotation coverage, an agent has everything needed to call and consume this tool 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 100% and the single parameter is fully documented with a regex pattern and a concrete example, so the schema carries the burden. The description only restates amount_micro, adding no format or constraint detail beyond the schema; baseline 3 applies.

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 and resource ('Get what it takes to top up the AmpleRun USDC balance'), names the exact protocol (x402) and enumerates the returned payment requirements (network, USDC contract, payTo, amount, EIP-712 domain). This is clearly distinguishable from siblings like get_balance and get_quote.

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?

Explains the intended flow clearly: fetch requirements here, then sign as EIP-3009 transferWithAuthorization and repeat the POST with the PAYMENT-SIGNATURE header. It gives strong context for when this tool is used, but does not explicitly name alternatives or state when not to use it.

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