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

Beyond the annotations, the description adds useful behavioral context: the endpoint is free, provides a stable HTTPS address and key on port 8000, and the key is shown only once during creation. It also names the related retrieval tool. It does not discuss idempotency behavior or what happens if the same name is reused, which would be helpful for a non-idempotent creation tool.

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

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

The description is short and mostly information-dense, but it is written as sentence fragments and opens with “A new Endpoint” rather than a clear verb. The line break and phrasing around “e.g. one per customer you serve” make it less front-loaded and slightly awkward. It avoids bloat but could be structured more cleanly.

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 simple one-parameter schema, existing output schema, and annotations, the description covers the key operational facts an agent needs: access level, cost, what is created, that the key is shown once, how to launch machines against it, and where to retrieve the key later. It is close to complete, with only idempotency and repeated-creation behavior left 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?

There is a single parameter with 100% schema description coverage, so the schema already explains that the name can represent the customer it serves. The description reinforces this with “e.g. one per customer you serve” but adds no distinct naming constraints or format details beyond the schema. This fits the baseline 3 when schema coverage is high.

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 resource as a new Endpoint and explains its practical meaning: a stable HTTPS address and key for the user's own server. It distinguishes the tool from get_endpoint_key by noting that the key is shown once here and can be retrieved again there. The verb 'create' is only implied, not explicitly stated, which keeps it just 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 gives concrete usage context: intended for owners and admins, typically one per customer, and explicitly points to launch_machine(endpoint=...) as the follow-up action. It also contrasts with get_endpoint_key for retrieving the key later. It does not state explicit when-not-to-use conditions, so it is not 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?

Annotations already declare readOnlyHint=false and openWorldHint=true, but the description adds the critical non-obvious fact that the call costs money and requires a quote/confirm dance. That is genuine value beyond structured data; only return-format/pagination style details are absent, and an output schema exists.

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

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

Two short sentences, front-loaded with the cost warning and the quote-first instruction. No filler.

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

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

For a paid mutation tool with an output schema present, the description covers purpose, cost, and the approval flow adequately. Minor gap: no mention of what happens on failure or whether the quote expires, but nothing blocking 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 coverage is 75% and already documents confirm and expected_total_usd, but the description reinforces their interlocking semantics ('the quoted total_usd' tied to confirm=true). It adds real workflow meaning over the field descriptions rather than repeating them.

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 ('Add time') and resource ('a machine') plus a pricing constraint ('at the price it launched with'). Clearly distinguishable from siblings like launch_machine and stop_machine.

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 prescribes a two-step workflow: quote with confirm=false first, then confirm=true with expected_total_usd after the person agrees. Strong usage context, though it doesn't name sibling alternatives or when-not-to-extend conditions.

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 the safety profile (readOnly, idempotent, non-destructive), so the description's job is to add context — and it does: it discloses an authorization constraint (owners and admins only) and the security consequence (the key grants access to their server). It does not say what happens on an unauthorized request or warn about handling the returned secret.

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

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

Two short clauses, front-loaded with what the tool returns and immediately followed by the usage gate — no filler. The phrasing is slightly telegraphic (a fragment rather than a sentence), which costs a point but not readability.

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?

An output schema exists, so return values need no explanation, and the permission gate plus the access implication are stated. However, for a credential-revealing tool it omits error behavior when the caller is not an owner/admin and any caution about exposing or logging the key.

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

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

There is a single parameter and schema coverage is 100%, with the schema already documenting "Endpoint name or id." The description adds no additional meaning about that parameter, 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?

The description identifies the resource (an Endpoint's key) and its audience (owners and admins), which is specific enough to distinguish it from list_endpoints or create_endpoint. It reads as a noun phrase rather than an explicit verb+resource statement, so it stops short of the top score, but an agent can tell what it returns.

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?

"Only when the person asks for it" is an explicit gating condition, which is stronger than typical implied usage. It does not name alternatives or explain what to do when the caller lacks owner/admin rights, but the primary when-to-use rule is stated outright.

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, open-world, so safety is covered. The description adds real value beyond that by scoping what is returned and explicitly stating 'Never its keys' — a security-relevant negative that steers agents toward get_endpoint_key. It does not mention behavior for unknown/expired IDs.

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 with the resource front-loaded, then the returned facets, then an important exclusion at the end. No filler and nothing redundant with 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 one-parameter read tool with full annotation coverage and an output schema, the description covers purpose, contents, and the one non-obvious caveat (keys excluded). Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100% and the single machine_id parameter already carries an example format (cnx-7f3a9c) plus length bounds, so the baseline of 3 applies. The description adds no syntax, format, or lookup guidance for the identifier.

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?

Names a specific verb (get) and resource (one machine) and enumerates the returned facets: state, connection details, time left, keep-running status, costs. The phrase 'One machine' implicitly distinguishes it from list_machines, so an agent can route between single-fetch and listing without opening another 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?

Usage is only implied: 'One machine' vs. the list_machines sibling signals the retrieve-a-single-record case, but there is no explicit when-to-use, no prerequisite (e.g. machine must exist / be owned by caller), and no named alternative for related needs like get_endpoint_key.

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 the safety profile (readOnly, idempotent, non-destructive), so the description's added value is the disclosure that results are pre-aggregated across four dimensions. It says nothing about whether today is included in the window, timezone, currency of spending, or latency over long ranges.

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 tightly packed sentence with the metrics and window front-loaded and no filler. It is slightly telegraphic — the missing verb means the agent reads it as a phrase rather than a statement of behavior.

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?

An output schema exists, so return-shape details are unnecessary, and annotations carry the safety semantics. With only one parameter and one aggregation window, the description covers what the tool produces; only the default-window behavior and inclusion of the current day are left unstated.

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 single parameter is fully documented with default 30, minimum 1 and maximum 365. The description's phrase 'over the last N days' merely restates the schema, 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?

The description names the two concrete metrics returned (spending and GPU-hours) plus the time window and the aggregation grains (GPU, app, day, project), which is far more specific than the tautological title. It implicitly distinguishes itself from the list_* siblings because it produces an aggregated cost report rather than an inventory, though it never explicitly says so.

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 list_receipts, list_gpus, or list_projects, and no note on prerequisites or typical queries. The agent must infer the use case from the metric names alone.

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?

Beyond annotations, the description discloses the critical financial behavior: the launch costs money, confirm=false produces only a quote and does nothing, and booked time is charged up front from the team balance. This is exactly the kind of consequence-focused context an agent needs for a non-read-only, open-world mutation.

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 purpose and cost warning, then gives the required confirmation workflow without unnecessary detail. Every sentence serves selection or safe invocation.

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 12-parameter financial mutation with high schema coverage and an output schema, the description covers the essential missing context: cost, quote mode, confirmation requirement, and upfront charging. Return-value details are appropriately left to the output schema.

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 high at 92%, so the schema already carries most parameter meaning. The description nevertheless adds useful procedural semantics for confirm and expected_total_usd by explaining the two-call quote-then-confirm workflow and the need to reuse the same arguments.

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: 'Launch a GPU machine.' It also immediately frames the operation as a paid action, which makes the tool's core purpose unmistakable against siblings like list_gpus, stop_machine, and extend_machine.

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

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

The description gives explicit invocation guidance: call first with confirm=false to get a no-op quote, show it to the person, then call again with confirm=true and expected_total_usd after agreement. It does not explicitly mention alternatives such as extend_machine for renewing an existing machine, so it falls short of full when-to-use-vs-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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful beyond-schema context: the response is a catalogue with per-app purpose, offered models, and a recommended model keyed to GPU memory, and that supplying `app` switches to an installed-software view. It does not mention whether results vary by project or account, which is the main remaining behavioral gap.

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

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

A single sentence with a parenthetical enumeration; the core catalogue purpose is front-loaded and the parameter hint trails it, which is the right order. The colon-and-clause structure is slightly dense, and the fragment phrasing costs a little clarity, but there is 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?

An output schema exists, so return values need not be spelled out, and annotations cover the read-only/idempotent safety profile. What remains for an agent to decide correctly — what the catalogue contains, what each entry tells you, and how to drill into installed software — is all present. Nothing essential to invoking this zero-required-parameter read tool 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 both `app` and `package` are already documented, establishing the baseline of 3. The description's "Give `app` for the software installed" largely restates the schema's "One app, to also see what's installed in it" and says nothing about the `package` parameter or the app+package combination. No added semantic value over 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 identifies the resource precisely and enumerates the concrete catalogue entries (basic, datascience, chat, imagegen, modelapi, voice) plus what each entry exposes: purpose, offered models, and a per-GPU-memory recommendation. It is not a tautology of the name/title and no sibling tool covers app catalogues, so it is distinguishable. It falls short of a 5 because it is phrased as a noun fragment rather than a clear verb+resource statement of what the call does.

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?

"Give `app` for the software installed" is the only usage steer and it is tied to a single parameter, implying a drill-down pattern but never stating it. There is no explicit when-to-use framing relative to siblings (e.g., before launch_machine or create_endpoint to pick an image), and no when-not-to-use guidance. Usage must be inferred.

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 and open-world, so safety is covered. The description adds real value beyond them: endpoints always terminate on port 8000, mappings reflect the machine they point at *now*, and key material is deliberately withheld from results — an output-content disclosure the agent cannot get from 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?

A single compact sentence, front-loaded with the resource definition and ending on the most useful constraint (keys excluded). It is a sentence fragment whose second clause ('the machine each points at now') is slightly elliptical, but nothing 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?

With no arguments, rich read-only annotations and a declared output schema, the only thing the description must supply is what an endpoint is and what the caller will and will not see. It covers both, so an agent can call this confidently without further 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly avoids inventing filtering options that do not exist.

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 defines the resource precisely — stable HTTPS addresses on a machine's port 8000 that point to a machine — and explicitly scopes out keys, which separates it from get_endpoint_key. The listing verb is only implied by the tool name rather than stated, so it falls short of a full verb+resource statement.

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 explicit 'use this when...' guidance, and no mention of how it relates to create_endpoint or get_endpoint_key beyond the 'Never their keys' exclusion. The exclusion implies the sibling that should be used for keys, but the agent must infer the selection rule.

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 the operation read-only, idempotent, open-world, and non-destructive. The description adds useful behavioral context beyond that: prices are live, denominated in US dollars per GPU per hour, stock is included, and results are sorted cheapest first. It does not explain sales-availability defaults, but the schema covers that.

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

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

A single compact sentence that front-loads the resource and immediately gives price units, stock inclusion, and sort order. There is no 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 rich annotations, full schema coverage, and an output schema, the description supplies the key missing context: price currency/unit and ordering. It could mention filtering behavior briefly, but the structured fields carry the rest adequately.

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 all four parameters are already documented in the input schema. The description adds no parameter-specific meaning beyond what the schema provides, making the 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 clearly identifies the resource as GPUs and states that live prices and stock are returned, with cheapest-first ordering. It lacks an explicit verb but the tool name supplies that, and it distinguishes itself reasonably from sibling list tools like list_machines and list_apps.

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

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

There is no guidance on when to use this tool versus alternatives such as list_machines or list_apps, nor any mention of prerequisites. The usage is only implied by the resource name and returned data.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context about ordering and returned fields, but does not explain pagination, permissions, or how defaults like active_only affect 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?

The description is a single efficient sentence with zero waste. It front-loads the resource and scope, then lists the most relevant return attributes.

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?

This is a simple listing tool with rich annotations and an output schema, so the description need not explain return values in depth. It is complete enough to call correctly, though it could briefly clarify the default filters and when to prefer get_machine for details.

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

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

The schema describes two of three parameters (whole_team and active_only) and limit is self-explanatory with min/max/default values. The description does not add parameter-level meaning beyond the schema, but the schema coverage is adequate enough that this is a minimum-viable case.

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

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

The description names the resource (machines), the scope (your machines), the ordering (newest first), and the key fields returned. This clearly distinguishes a personal machine listing from generic GPU/app listings, though it does not explicitly differentiate from get_machine.

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 explicit guidance on when to use this tool versus get_machine, list_gpus, or list_apps. The phrase 'Your machines' implies a personal listing use case, but no alternatives or exclusions are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds domain context — that projects are files restored into ~/work — but says nothing about ordering, pagination, or what happens when no projects exist. With annotations carrying the behavioral load, this is adequate.

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 tightly packed sentence with no filler. The nested parenthetical is slightly awkward to parse but front-loads the resource before the explanatory gloss.

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?

Output schema exists, so return values need not be described, and annotations cover the safety profile. The description supplies the one thing structured fields cannot: the meaning of 'project' in this environment. Missing only usage routing, which is the guidelines dimension.

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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The parenthetical about ~/work does add meaning to what the returned project objects represent.

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 identifies the resource (saved projects) and adds a useful gloss on what a project actually is (files restored into ~/work on launch) plus the size attribute returned. Combined with the name list_projects, an agent can tell it apart from list_machines or list_apps, though the description itself never states the listing action explicitly.

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 when-to-use guidance: nothing says to call this before launch_machine or extend_machine, no exclusions, no mention of alternatives. The implication that this enumerates saved projects is left entirely 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 declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real value by clarifying that only ended sessions appear and that cost means charged minus refunded – a definition an agent could not infer from the schema. It says nothing about ordering, pagination, or what happens with zero 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?

A single short sentence with zero filler, and the most distinguishing concept (finished sessions) is front-loaded. It is a fragment rather than a complete sentence, but nothing 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?

An output schema exists, so return-shape explanation is not required, and the cost definition covers the semantic core. Still missing is any hint about the undocumented 'limit' parameter or result ordering, leaving an agent to guess how to page through receipts.

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%: 'days' is documented in the schema, but 'limit' has no description anywhere, and the description does not compensate by explaining paging behavior or result caps. The description mentions no parameter at all, so it adds nothing beyond the structured fields.

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?

Names a specific resource – finished sessions with their final cost, defined as charged minus refunded – which is concrete enough to separate it from generic siblings like get_usage. It never states the verb (list) explicitly and reads as a noun fragment, but the scope 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?

No guidance on when to reach for this tool versus get_usage, get_machine, or the other list_* siblings. The only implicit cue is 'finished sessions', which hints at completed rather than live data, but no alternative or exclusion is named.

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 only declare the generic profile (not read-only, open-world, non-idempotent, non-destructive). The description adds the material facts an agent cannot get from them: renewal spends money from the team's balance at every renewal, at the launch price, and it enforces a quote-then-confirm safety protocol with a specific expected amount. That is exactly the added context this dimension rewards.

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, cost and confirmation protocol front-loaded. Minor waste in the opening 'Keep running:' echo of the tool name, and the telegraphic phrasing ('quote first, then confirm=true with expected_renewal_usd') is dense but decodable.

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?

An output schema exists, so return values need not be explained, and the description covers the billing cycle, price basis, and confirmation flow. It stops short of edge cases such as insufficient balance or what a quote response contains, but nothing essential to making the call is missing.

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

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

Schema coverage is 75% and the description reinforces the highest-risk parameters: `confirm` as quote-only vs. execute-after-agreement, `expected_renewal_usd` as the quoted figure, and `hours=null` as the off switch. Only `machine_id` is left implicit, which is reasonable given its self-explanatory 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 resource (the machine), a specific behavior (self-renewal in `hours` increments billed from the team balance at launch price until stopped), which goes well beyond the bare tool name. It does not, however, name or differentiate itself from the closely related siblings `extend_machine` and `stop_machine`, which an agent would likely weigh against this tool.

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

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

It gives an explicit operational procedure: turning on requires a quote first, then `confirm=true` with `expected_renewal_usd`; turning off uses `hours=null` and needs no confirmation. That is clear when-and-how guidance. The gap is that it never says when to prefer this over `extend_machine` or `stop_machine`.

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 flag destructiveHint and idempotentHint, but the description adds the details an agent actually needs: files outside a project are deleted, a project is saved first, unused time is refunded, and the action is irreversible. This is exactly the 'what gets destroyed and what it costs' context that 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 clauses, each load-bearing: state-dependent behavior first, then data-loss scope, then refund, then irreversibility. Front-loaded with the primary effect and 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?

Output schema exists, so return values need no explanation, and the annotations plus description together cover safety, side effects, and billing. The only real gap is that the agent gets no information about what machine_id must be or where to obtain 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 0% and the single required parameter machine_id is never mentioned in the description, so there is no compensation for the schema gap. The reference to 'a machine' is generic and adds no format, scope, or lookup guidance beyond the property 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?

States a specific verb and resource ('End a machine now') and goes further by spelling out the two distinct outcomes: stopped if running, cancelled with refund if still starting. It is clearly the inverse of siblings launch_machine and extend_machine, though it never names them explicitly.

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 'End a machine now' and the 'Can't be undone' warning gives a caution signal, but there is no explicit guidance on when to prefer extend_machine or set_keep_running instead, nor any statement of prerequisites or permissions.

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 the safety profile (readOnly, idempotent, non-destructive), so the description's job is to add context — which it does by disclosing that the response includes authorization-relevant facts (whether the key may launch/stop machines). It does not mention auth requirements or error behavior, but for a trivial read-only introspection call this is close to 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?

A single front-loaded sentence that enumerates the payload fields without padding or restating the tool name. Nothing here could be cut without losing 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 zero-parameter read-only tool with an output schema, the description covers everything an agent needs: what identity context is returned and that it reveals launch/stop permissions. Return-value formatting is correctly left to the output schema.

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 nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies a parameterless call.

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

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

The description names the exact resource (the identity behind the server's API key) and enumerates the returned fields: email, team, role, team balance, GPU limit, and launch/stop permission. It is unambiguous against siblings like list_gpus or get_machine, though it does not explicitly differentiate itself from them.

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 only implied: an agent can infer this is a pre-flight identity/permission check before launching or stopping machines, but the description never states when to call it, when not to, or what alternative exists. No prerequisites or ordering guidance is given.

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