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

With no annotations, the description carries the full burden and discloses important behavior: it returns a Docker command containing a secret token, the node comes online only after the command runs, and then goes through a GPU check. It also states the rate limit, though it does not mention auth requirements or failure behavior.

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 purpose and return value are front-loaded, followed by operational warnings and rate limit. Every sentence adds useful information: confirmation guidance, secret-handling warning, lifecycle note, and rate limit.

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, but the description explains the key return value: a Docker command containing the node secret token. Combined with the lifecycle explanation and rate limit, it gives enough context for an agent to call the tool and handle the result safely.

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 name, os, spot, type, and available, including defaults and enums. The description reinforces that name and type should be confirmed with the user but adds little parameter detail beyond the schema; baseline 3 is appropriate.

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

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

The description states a specific verb and resource: add a new node to the account and return the Docker install command. The word 'new' helps distinguish it from siblings like get_node_install_command, which presumably handles existing nodes, and from list/get/update node tools.

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 usage context: confirm the name and type with the user first, and note the 20-nodes-per-hour limit. It does not explicitly compare against the sibling get_node_install_command, so the agent must infer that this tool is for adding a node rather than fetching a command for an existing one.

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 fully discloses critical behavior: per-minute billing, asynchronous pending status, provisioning time, idempotency key generation, and default open-ended duration. This exceeds transparency 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 every sentence serves a purpose—cost, confirmation, async flow, timing, next steps, duration policy, idempotency. It is front-loaded with the core action 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?

Given the tool's complexity (billing, async provisioning, open-ended vs. capped duration) and lack of output schema, the description covers all essential aspects: return shape (rental_id/status), follow-up action, cost warning, and stopping mechanism. Nothing critical 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?

Although the schema already documents all parameters, the description adds meaningful context: how 'hours' behaves relative to the default, that node_id comes from list_gpus, and that type only supports 'jupyter'. This enriches the agent's understanding.

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 'Start renting a GPU', which clearly identifies the action and resource. It distinguishes itself from sibling tools focused on listing, getting, or destroying rentals.

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 operational guidance: confirm with user, use open-ended by default, only pass 'hours' when user requests a limit, and call get_rental once instead of polling. This is exactly the kind of when/how guidance 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states that the tool stops the GPU, stops billing, is safe to call twice (idempotent), and requires user confirmation. This is strong behavioral disclosure, though it doesn't mention reversibility or what happens to data.

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, front-loaded with the core purpose ('Stop a rental'), then adding critical behavioral notes. Every sentence adds value and there is 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?

Given the tool's simplicity (one parameter, no output schema), the description covers the essential context: what happens, idempotency, and the need for confirmation. It doesn't describe return values or error conditions, but these are less critical for a straightforward destroy action.

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 one parameter (rental_id) with no description (schema description coverage is 0%). The description does not mention or explain the parameter at all, leaving the agent to infer meaning from the name only. Since coverage is low and the description provides no compensation, the parameter semantics are under-specified.

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 ('Stop') and resource ('a rental'), and clearly states the main effects: stopping the GPU and stopping billing. This distinguishes it clearly from siblings like list_rentals, get_rental, create_rental, and get_balance.

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

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

The description gives clear context for when to use the tool: as a 'money brake' to stop a rental, and explicitly instructs to confirm with the user unless they already asked to stop it. It doesn't mention alternative tools, but the use case is evident and the confirmation guidance is valuable.

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 explicitly discloses 'Read-only, no cost,' indicating no side effects or charges. It does not mention auth or return format, but for a simple balance check this is meaningful and sufficient.

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, front-loaded sentence that states the action first and then adds concise, relevant context. Every word earns its place with no redundancy.

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

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

For a zero-parameter read-only balance tool, the description is fully complete: it explains what is being retrieved, how it relates to rentals, and that the call is safe and free. No output schema is necessary for this simple case.

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 an empty input schema, so the baseline is 4. The description confirms no input is needed and clarifies the operation, adding no unnecessary parameter 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?

The description explicitly names the action ('Get the account's credit balance') and adds billing context ('rentals are billed per minute against it'), clearly distinguishing this from the GPU/rental sibling tools.

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 that this relates to rental billing, implying it should be used to check available credit before or during rental operations. It does not explicitly name alternatives or exclusions, but sibling tools are obviously different.

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 declares read-only, states figures are net of the platform fee, separates already-billed-but-still-running rentals from settled earnings, and names a data source it can't provide (payouts). Lacks only operational traits like latency or caching.

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 plus a two-word safety clause, with the provider/data scope front-loaded before the field enumeration. Every clause adds information and nothing is repeated.

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, so the description must convey return content, and it does by naming the breakdown categories. The exact response shape (per-day buckets vs aggregates) is left implicit, which is a minor residual gap for a single-parameter read.

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 define `days`, and it does: what is counted ('last `days` days'), the default (30), and the max (366). It doesn't spell out how boundary days are counted (inclusive/exclusive) or the cost of large windows, keeping it below 5.

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 (returns earnings) plus resource (account earnings in USD by UTC day), and enumerates the breakdown it includes (rentals per node, inference, total, withdrawable balance, accrued running rentals). This distinguishes it from get_balance and the node/rental siblings, which deal with state rather than an earnings ledger.

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 default (30) and max (366) window and explicitly excludes payouts ('not available through the API'), which is useful scoping. However, it never routes the agent between this and the closely related get_balance or explains which to pick when only a current balance is 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?

With no annotations, the description must carry full behavioral disclosure. It states 'Read-only' which is helpful, but omits authentication requirements, error behavior (e.g., if node_id is not found), and any rate limits. The mention of returned fields adds some context but is not sufficient for a mutation-free read tool.

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, short sentence with no wasted words. However, the leading 'PROVIDER:' is cryptic and may confuse rather than front-load useful information. Still, the size is appropriate.

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 read tool with no annotations and no output schema, the description is incomplete. It gives read-only status and some return fields, but does not cover error handling, authentication, or expected response structure. An agent would need to infer too much.

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% and the node_id parameter already has a clear description ('Node UUID from list_my_nodes'). The tool description does not add any new meaning about the parameter or its format; baseline 3 is 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 indicates it returns one of the account's nodes and lists fields (state, price, rental, live GPU metrics), which distinguishes it from list_my_nodes. However, it lacks a clear action verb like 'Get' or 'Retrieve' and the phrase 'PROVIDER: one of the account's nodes' is ambiguous; an agent must infer the purpose from the name and parameter.

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?

No explicit guidance on when to use this tool versus alternatives. It references the sibling list_my_nodes only to compare fields, but does not state 'use this when you have a specific node_id' or any exclusion conditions. The read-only note is not 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, the description must carry the burden; it does disclose 'Read-only' and explains a non-obvious behavior — that an empty list with private: false means public/visible to everyone. It omits permission requirements, error cases, and pagination or result shape beyond field hints.

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 compact sentences with no filler, and the core access semantics are front-loaded before the read-only note. The 'PROVIDER:' prefix is a terse scoping cue rather than wasted text.

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 partially compensates by describing return content (emails, domains, organizations, private flag), which is helpful. However it leaves the required node_id unexplained and never confirms what the call actually returns (a list vs. an object).

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 single node_id parameter is required but has 0% schema description coverage, and the description never explains what a node_id is, where to obtain it, or its format. For a one-parameter tool this is the main 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 conveys the resource — the access list controlling who can rent a node — and 'Read-only' signals a fetch rather than a mutation. But no explicit verb is used, and the sibling set_node_access is never named, so the agent must infer from the name alone that this retrieves while set_node_access writes.

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 statement of when to call this versus set_node_access, update_node, or list_my_nodes, and no prerequisites (e.g., node ownership) are given. The only guidance is the semantic of the returned data, not when to invoke the tool.

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 by disclosing that the result contains a secret token, must be shown only to the user, and is read-only. It could still say more about provider-only auth requirements or whether the token is time-limited.

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 tight sentence that front-loads the provider context, purpose, sensitivity warning, and read-only nature without wasted 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 simple one-parameter read tool with no output schema, the description covers the purpose, use case, secret-handling requirement, and read-only nature. It is missing only the source or format of node_id, which is the main remaining 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?

Schema description coverage is 0%, and the description never mentions the single required node_id parameter. It implies an existing node but does not explain how to obtain or format the node identifier, leaving the schema to carry a parameter it does not document.

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 and resource: returning the Docker install command for an existing node. It clearly scopes the tool to reinstall/move scenarios on an existing node, distinguishing it from add_node or update_node.

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 use case is explicit: an existing node that needs to be reinstalled or moved. It does not name an alternative tool or state when not to use it, but the context is clear enough for selection.

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 an excellent job. It discloses the blocking/waiting behavior, the ~24s internal timeout, the total provisioning time (~20-40s), the connection_pending readiness flag, and declares the tool 'Read-only.' This gives an agent a clear mental model of side effects and timing.

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 unique value: purpose, usage timing, wait behavior, anti-loop guidance, timing estimate, readiness condition, and read-only flag. The content is front-loaded and the length is justified for the behavioral nuance it conveys.

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 one-param tool with no output schema, the description covers what the tool returns (status, Jupyter URL, token), when it's ready, how long to wait, and how to interact with the rental lifecycle (create → get → destroy). It is fully complete for the agent's needs.

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 rental_id. It does so indirectly: 'Get one rental's status' and 'After create_rental, call this' implies the rental_id comes from create_rental. While not a formal param definition, this is sufficient context for a single obvious parameter. It earns above 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 uses a specific verb ('Get') and resource ('one rental's status and connection details (Jupyter URL + token)'), clearly distinguishing this from sibling list_rentals. It immediately conveys the tool's unique purpose.

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 provides when-to-use guidance: 'After create_rental, call this to get the URL.' It also gives strong behavioral guidance: warns against tight loops, explains the internal wait (~24s), and states the readiness condition. This is far beyond a minimal description.

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 safety profile itself: 'Read-only, no cost' tells the agent nothing is mutated or charged. It also explains the non-obvious reserved_for_you semantics (provider-held for this key's person/org, listed first, invisible to others), which is real behavioral context beyond the schema. Pagination or result-size limits are not disclosed.

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 scope and return fields, then the rental action, then the reserved_for_you caveat and the compute-capability tip. Every sentence is informative, though the reserved_for_you explanation runs long and slightly interrupts the flow between the action and the recommendation.

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, and the description compensates by naming the returned fields and the node_id needed to act. For a zero-parameter read tool this is nearly complete; only result volume/pagination behavior is unaddressed.

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 there is no parameter semantics to explain; baseline 4 applies. The description does not need to compensate for any schema gap here.

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 GPU nodes available to rent right now') and enumerates exactly what comes back (price/hour, GPU model, VRAM, compute capability, country). The 'available to rent right now' scope implicitly separates it from list_my_nodes, so an agent can route 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 actionable next-step guidance ('Rent by the returned node_id') and a concrete selection heuristic ('prefer compute_cap >= 8.9 (FP8)' for LLM work). It does not explicitly state when to prefer a sibling such as list_my_nodes or get_my_node, so it falls short of full when/when-not coverage.

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 structured annotations exist, so the description carries the full burden. It explicitly declares the tool 'Read-only', states the required key scope, and adds a privacy detail ('never the renter'). It does not mention rate limits or error behavior, but for a scoped list call the essential behavioral traits are disclosed.

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 purpose is front-loaded in the first clause, and the dense enumeration of returned fields is useful rather than repetitive. The single long sentence is less scannable than a structured list would be, and 'Read-only' sits as a trailing fragment, but no sentence is wasted.

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 and no parameters, so the description must explain what comes back. It does so thoroughly: node states, GPU/VRAM, price details, verification, reputation, current rental privacy, and live metrics. An agent can form a correct expectation of the response without additional documentation.

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 there is no parameter semantics to document. Per the rubric, a zero-parameter schema receives a baseline of 4 regardless of description content.

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 ('list'), resource ('GPU nodes'), and ownership scope ('this account provides'), with a 'PROVIDER:' prefix that distinguishes it from renter-side siblings like list_rentals. An agent can identify this as the provider's node inventory call without touching 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 clear usage context: it requires a key with the 'nodes' scope and is framed for providers. It does not explicitly say when to use this versus get_my_node (single node) or list_gpus (all GPUs), so it lacks the outgoing routing of a 5, but the provider framing makes the intended use clear.

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 behavioral disclosure burden. It explicitly states 'Read-only,' which is a key safety trait, and clarifies that 'active' means 'what's running and billing.' This adds meaningful context beyond the bare schema, though it does not mention pagination or return format, which are common for list tools.

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 extremely concise: four short sentences that front-load the purpose, then efficiently cover defaults and the read-only nature. Every sentence contributes value without repetition, making it easy for an agent to parse quickly.

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 only one optional parameter, no output schema, and no annotations, the description covers all essential aspects: purpose, default behavior, parameter usage, and safety. It does not describe return values or pagination, but for a simple list operation this is a minor omission, and the description is otherwise complete enough for an agent to select and invoke the 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?

The input schema already defines the status parameter with an enum and default, but the description adds semantic meaning by explaining that the default includes only active rentals and that 'all' gives full history. This directly clarifies what each value represents, going beyond the schema's generic description.

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 begins with 'List the account's rentals,' which uses a specific verb and resource, clearly distinguishing it from siblings like get_rental (single rental) and create_rental/destroy_rental. The scope ('account's rentals') and default behavior ('active ones') further clarify its purpose.

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 usage context: by default only active rentals are returned, and passing status='all' retrieves full history. It does not explicitly mention alternatives, but the sibling names make the appropriate tool obvious, and the guidance on the status parameter is practically sufficient.

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 most of it: it discloses that rentals and inference stop, that a spot rental terminates two minutes later, and that the renter is notified. It does not say what the tool returns or whether the call can fail for non-spot or busy nodes, leaving a small gap 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?

Front-loads the action, then consequences, then constraints, then the reverse action — a sound ordering with no filler sentences. The nested parentheses and all-caps emphasis make it denser than necessary and slightly harder to scan.

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 one-parameter, no-annotation, no-output-schema mutation tool, the description covers the consequential behavior (rentals off, two-minute termination, renter notified), the safety gate (confirm first), and the cleanup path. Only the return value and failure modes are unaddressed.

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% and the description never explains node_id — but with a single, self-evidently named identifier parameter the risk of misuse is low. The description compensates indirectly by telling the agent the node must be a spot node, which is the only real semantic constraint on the input.

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 ("take a spot node back for the owner's own use") and immediately scopes it ("Only for spot nodes"). It also names the sibling operation that reverses it (set_node_available), so an agent can distinguish this from generic node-management tools 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?

Explicit about when it applies ("Only for spot nodes"), what must precede it ("Always confirm with the user first"), and what must follow it ("Put the node back afterwards with set_node_available(true)"). This is a complete use/reverse lifecycle with no inference 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?

Without annotations, the description fully discloses key behaviors: it replaces the entire list, a non-empty list makes the node private and restricts inference work, an empty list opens access, and added people receive email notifications. This is thorough for a mutation tool.

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 main action and logically organized. It is slightly verbose (e.g., explaining ParalonCloud inference work), but every sentence adds useful context without severe 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?

Given no annotations or output schema and a mutation tool with side effects, the description covers purpose, behavior, side effects (emails), and usage guidance (get first, confirm). It provides everything an agent needs to invoke 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 0% schema description coverage, the description compensates by explaining the entries format in detail, including examples for each kind (email, domain, org) and the effect of the list being full replacement. It also implies node_id is the target node.

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 explicitly states 'set who can rent a node, replacing the whole list,' providing a specific verb (set) and resource (node access), and distinguishes from siblings like set_node_available or set_node_price by focusing on renter permissions.

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 advises 'Call get_node_access first to keep existing entries' and 'Always confirm with the user first,' giving clear context for use. However, it does not explicitly state when NOT to use this tool or compare to alternatives like update_node, keeping it from a 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?

With no annotations, the description carries the behavioral burden well: it discloses that taking a node off the market stops new rentals immediately while an existing rental continues to its end. It also requires user confirmation unless the request was explicit. It does not detail permissions or return behavior, but the core side effects are clearly stated.

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 short and front-loaded: role, action, side effects, usage condition, and confirmation rule appear in a logical order. Every sentence adds useful information without 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 two-parameter mutation with no annotations or output schema, the description covers purpose, key side effect, usage condition, and confirmation requirement. The main omission is node_id guidance, but the overall definition is sufficient for correct invocation.

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 explain both parameters. It fully explains the available boolean semantics, but node_id is only implied by 'a node' and not described as to source or format.

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 provider action on a specific resource: taking a node off the market or putting it back, with available=false/true mapped directly to the state change. It is clearly distinct from sibling tools like update_node and set_node_price because it is about market availability, not configuration or price.

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 explicit when-to-use conditions: the owner needs the machine or it is rented elsewhere. It also gives an important confirmation rule, though it does not explicitly compare against alternatives such as update_node or set_node_price.

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 discloses important behavior: provider-only operation, platform fee deduction, default-price reset via null, bounds enforcement, running-rental price preservation, spot-node exclusion, and user confirmation. It does not describe auth requirements, error behavior, or the response.

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 constraints and safeguards in a compact sequence. Every sentence adds useful information, with no repetition or 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 two-parameter mutation tool with no annotations and no output schema, the description covers purpose, bounds, side effects, spot-node exclusion, and confirmation guidance. It is largely complete, though it does not mention authorization requirements or expected response/error behavior.

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 substantial meaning beyond the schema for price_per_hour: USD per hour for the whole node, renter-facing price, provider net of platform fee, null default reset, and min/max constraints. node_id remains undocumented, but its meaning is self-evident from the tool name.

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: set a node's hourly price, including what the renter pays and what the provider receives. It is clear but does not explicitly differentiate this operation from the sibling update_node 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?

It gives clear usage constraints: the price must fall within the node's min/max bounds, spot nodes are excluded, running rentals keep their price, and the user should confirm first. It references get_my_node for bounds but does not name an alternative for related updates.

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 behavioral burden and does well: it discloses that spot changes are refused while the node is rented, that enabling spot clears a custom price, and that only changed fields should be sent. It stops short of covering auth/permission requirements, failure behavior for partial updates, or what the tool returns.

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 dense sentence that front-loads the core action ('change several things on a node at once') and uses parentheticals for constraints. Every clause adds useful information, though the compact format makes it slightly less scannable than a short structured list.

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 mutation tool with no annotations and no output schema, the description covers the essential semantics: which fields can change, key side effects and refusals, and the requirement to confirm with the user. Missing details like permission requirements, node_id description, and return/error behavior keep it from being 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?

Schema coverage is 0%, so the description must compensate, and it largely does: it explains the meaning and constraints of spot, available, and price_per_hour (USD per hour or null). The node_id parameter is only implied by 'on a node', and 'available' is left as a simple boolean without further context, but the added semantic detail elsewhere is substantial.

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 ('change') and resource ('a node'), and lists the exact fields that can be updated. The phrase 'several things at once' implicitly distinguishes it from single-field siblings like set_node_available and set_node_price, but it does not name those alternatives explicitly, keeping it short of a 5.

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

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

It provides clear context that the tool is for changing multiple fields in one call and adds important usage constraints ('Send only what changes', 'Confirm changes with the user first'). However, it never explicitly says when to use this tool versus the dedicated single-field setters, so the agent must infer the routing.

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