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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful operational context beyond that: report the balance in USD and surface auto-recharge only when enabled, which shapes how results should be presented rather than repeating the annotation claims.

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

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

Three short sentences in a deliberate order: what it does, when to call it, how to report the result. No filler, and the core purpose is front-loaded.

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

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

With an output schema present, the description need not explain return values, and it adds reporting conventions on top. The only gap is not clarifying boundaries against balance-adjacent siblings such as billing_history, which an agent must resolve on its own.

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 per the baseline this lands at 4. The description correctly does not invent parameter detail, and schema coverage is 100%.

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

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

The description opens with a specific verb and two concrete resources: the identity behind the configured API key and the account credit balance. It is clear what the tool returns, though it does not distinguish itself from siblings like billing_history or transactions that plausibly touch the same data.

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?

"Call this first when the user asks about their account, balance, or which key is in use" gives an explicit trigger condition and even a precedence rule. It stops short of naming alternatives (e.g., use billing_history for past charges), so the agent must infer when to switch.

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, so safety needs no restating. The description adds genuinely useful behavior: the list includes managed storage usage and estimated monthly USD cost, single-asset mode returns `files` and usage locations, and null `size_bytes`/`file_count` signals an unmeasured linked source.

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 tight sentences, each carrying distinct information, front-loaded with the list-vs-single distinction. Slightly dense with inline formatting but 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?

Given rich annotations and an output schema, the description covers the remaining burden: scope, filters, workspace defaulting, null-value semantics, and what each mode returns. Pagination omission is the only real gap and is partially mitigated by 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 0%, so the description must carry parameter meaning, and it explains only `asset`, `asset_type`, `status`, and `workspace`. `limit` and `cursor` are never mentioned, leaving pagination undocumented, and the parameter is called `asset` in the schema but `asset_id` in the description, a naming mismatch that could mislead.

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

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

States a specific verb and resource ('List the Asset Hub assets') and enumerates the entity types covered (datasets, models, adapters, outputs). It also clearly separates the two modes: a workspace-scoped list vs. a single-asset lookup by `asset_id`.

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 routing: filter with `asset_type` or `status`, take `workspace` from the workspaces tool, and omit `workspace` when the user has only one. It lacks an explicit when-not/alternative statement (e.g. versus import_asset or storages), but the usage conditions are concrete.

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 openWorld behavior, so the bar is lower. The description adds useful context beyond annotations: currency is USD, refunds are negative, and dates use YYYY-MM-DD format. It does not disclose pagination behavior or how `limit` and `cursor` interact.

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 efficient sentences, front-loading the core purpose and then adding date/currency details. Every sentence contributes useful information with no obvious fluff.

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 annotations cover the safety profile. However, for a tool with five parameters and 0% schema description coverage, the missing explanation of `limit` and `cursor` leaves a notable gap in invocation guidance.

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 carry the burden of explaining all five parameters. It explains `kind`, `since`, and `until` meaningfully, but says nothing about `limit` or `cursor`, leaving critical pagination parameters undocumented.

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: 'Show money movements', and explicitly distinguishes two modes (`kind` "credit" vs "earnings"). It also differentiates from the account tool for balance checks, though it does not distinguish itself from the sibling transactions 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?

The description gives clear usage context for the two `kind` values and explicitly redirects agents to the account tool for current balance. It does not specify when to use this tool over the sibling transactions tool, but the main alternative 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?

Far exceeds the annotations: it discloses that encrypted storage is unlocked and an access pod spun up, that it re-locks after auto_lock_minutes, that a read & write key is required, that each confirmed call mints a new short-lived password, that the password is not persisted as an operation record, and how waiting/timeouts behave. The only mild tension is with idempotentHint=true, but the operation_id reuse rules explain the intended semantics.

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

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

Front-loaded with the core purpose and the credential-delivery warning, then organized into preview/confirm, timing, and operation_id sections. The operation_id paragraph is generic boilerplate that repeats across write tools, but it is load-bearing here because retries can mint new passwords.

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

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

Covers everything needed to invoke safely despite a rich output schema: the preview/confirm gate, the required key scope, the wait window and the 'no password yet, call again' outcome, and the handling rules for the returned credentials. Only the workspace parameter is left unexplained.

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 carries the burden and does well for four of five parameters: storage (pv_name from the storages tool), confirm (default false = no changes), wait (0–90, default 60, with timeout behavior), and operation_id (reuse preview ID or a pre-generated UUID, keep across retries). The workspace parameter is never mentioned, leaving one of five undocumented in both schema and text.

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

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

States a concrete verb and resource — 'Get an SSH login to a storage volume's files' — and immediately anchors it to a known analogue ('like the console's Connect'), which distinguishes it from siblings like ssh_access and storages. The scope qualifier 'only when the user asks to connect' further narrows what the tool produces versus adjacent storage 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?

Explicitly states when to use it ('only when the user asks to connect') and when not to act (do not run the command yourself, do not put the password in files, commits or other tools). It also gives the two-step protocol — confirm=false preview first, confirm=true after user agreement — and names the storages tool as the source of the storage identifier.

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 a safe idempotent read, so the description correctly spends its space on domain semantics instead: what a line is (vendor + product line + generation with fixed ddr_type, 0 = unknown), the fallback when no line is supplied, and what max_vcpus_per_pod/max_ram_per_pod represent. No contradiction with the readOnlyHint.

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 front-loaded sentences, each adding something distinct: purpose and pricing, definition of a line, downstream usage, capacity fields, and the spot tier. Dense but no filler; slightly heavy with backticked field names read in flow.

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 a single optional parameter, a full output schema, and safe-read annotations, the description supplies everything needed to call it and act on the result: the meaning of cpu_line, the no-argument default behavior, capacity limits, and the optional tier switch.

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 rental_type has no enum or description, so the description carries the load: it explains that 'spot' selects the cheaper preemptible tier, which is exactly the meaning the schema omits. Only the default 'demand' path is left implicit via the schema default.

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?

Opens with a specific verb and resource: 'Show the CPU lines a CPU pod can run on right now,' including pricing units (per vCPU core, per GiB RAM). The CPU framing implicitly contrasts with the 'gpus' sibling, but it never names that alternative, so sibling differentiation is only implied.

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 downstream routing: 'Pass its cpu_line to estimate_pod or create_pod; without one the cheapest line that fits is used.' It also states when to pick the spot tier. It stops short of stating when to use this versus the gpus or machines siblings.

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

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

The description goes far beyond the annotations, disclosing hourly credit spend, async pod startup, blocking behavior for model_set/hf_token_id, local volume billing persistence after deletion, max price cap behavior, error codes for Hugging Face gating, and that region is ignored. These are essential behavioral details for a mutating, open-world tool and do not contradict the annotations.

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

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

The description is front-loaded with the critical cost/confirm flow and then organizes details by parameter area, so the length is largely justified for a 30-parameter tool. It is still dense and repeats the multi-minute model_set/hf_token_id wait in multiple places, keeping it from being maximally concise.

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, annotations, and output schema, the description is largely complete: it covers creation flow, cost, async behavior, error paths, operation IDs, and most parameter semantics. The main gaps are the unexplained premium flags and rental_type, which are relevant for accurate 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?

With 30 parameters and 0% schema description coverage, the description does an excellent job explaining most parameters, including shapes for volumes, local_volumes, ports, template_ports, input_assets, watched folders, and operation_id. However, it leaves rental_type, cpu_premium, uptime_premium, and internet_premium unexplained, which prevents a perfect score.

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

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

The description opens with a specific verb and resource ('Create a pod') and immediately explains the key cost and preview semantics. It clearly distinguishes the preview behavior (confirm=false) from actual creation (confirm=true), so an agent understands what the tool does without opening the schema.

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

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

It gives explicit operational guidance: call with confirm=false first to get an estimate, then confirm=true only after the user agrees to the price; poll the pods tool for status; use operation_status after timeouts; reuse operation_id for retries. It also names conditions for model_set and hf_token_id, including license acceptance requirements.

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 are present but the description adds substantive behavior beyond them: hourly billing by capacity whether mounted or not, preview-vs-commit semantics, storage_type/disk_type/region handling and refusal of hostPath, and visibility lag before the volume appears in the storages tool. The operation_id paragraph covers idempotency/retry and timeout recovery, which is exactly the kind of context annotations alone don't 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?

Front-loaded with the core action and size constraint, then organized into coherent paragraphs for behavior, caveats, and the operation_id protocol. Every sentence carries information, though the operation_id/retry block is generic boilerplate that lengthens the definition relative to the tool-specific content.

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 mutating billed resource with an output schema, the description is nearly sufficient: it covers creation, billing, preview/confirm, encryption, warning thresholds, type handling, and follow-on steps. The main gap is that `max_price_per_hour` (a cost-control parameter with real consequences) and workspace targeting go unmentioned.

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 must carry all parameter meaning, and it does for most: size_gb minimum of 10, encrypted at-rest, usage_warning plus its 0-1 threshold default of 0.9, storage_type/disk_type/region accepted-and-ignored behavior, confirm, and operation_id. However `max_price_per_hour` is never explained, and `name`/`workspace` are left undocumented, so a few semantics gaps remain.

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 (create an nfs storage volume) with its scope (attachable by any pod in the workspace) and billing model. It also distinguishes itself from siblings by routing local storage to create_pod `local_volumes` and post-creation attachment to create_pod `volumes`.

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 the two-step flow: call with confirm=false to get an estimate, then confirm=true after user agreement. It also names the when-not case (local storage cannot be created standalone) and the fallback path (create it with a pod instead).

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 destructiveHint=true and idempotentHint=true, so the description's job is to add the operational context, which it does: the dependency failure when a serving is deployed, the preview-then-confirm gate, and the timeout recovery path via operation_status. That is substantial beyond the structured 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?

Front-loaded with the core action and its blocker, then the confirm flow, then the operation_id rules. Four dense sentences, all earning their place; the operation_id guidance is slightly repetitive but not wasteful.

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 shapes needn't be described. For a destructive open-world operation, the guidance covers the confirmation gate, dependency failure, and retry semantics. It stops short of stating permission requirements or how workspace selection changes the target, which for a multi-tenant delete is a real residual 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%, so the description must carry the load. It explains confirm (default false) and the reuse/new-operation semantics of operation_id thoroughly, but says nothing about registration_id (the only required parameter) or workspace scoping. Half the parameters remain undocumented in both places.

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 ("Delete a model registration") and immediately distinguishes it from a nearby sibling concern by noting it fails while a serving of that model is deployed — separating it from delete_serving. An agent can tell what this removes without opening the schema.

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

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

The two-phase flow is spelled out explicitly: confirm=false (default) only previews, confirm=true performs the delete only after user agreement. It also names the alternative for checking state (operation_status) and prescribes retry behavior, leaving nothing 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?

Goes well past the annotations by spelling out consequences: attached network storage survives while hostPath volumes are destroyed only when named in delete_local_storages. It also documents the operation_id lifecycle and prescribes checking operation_status and resource state after a timeout before retrying — exactly the retry-safety context annotations 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?

Front-loaded with the destructive action, then the confirm protocol, then storage side effects, then the operation_id contract — a sensible ordering. The operation_id paragraph is slightly boilerplate-heavy but each sentence carries distinct retry or idempotency 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?

An output schema exists so return values need no explanation, and the description fills the remaining gaps: preview semantics, selective volume deletion, and timeout recovery. An agent could execute this safely without consulting anything else except the pod/workspace parameter meanings.

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 carries the burden, and it does so for three of five parameters: confirm's preview semantics, delete_local_storages' pv_name matching, and operation_id's reuse rules. The `pod` and `workspace` parameters remain unelaborated, leaving a small gap.

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

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

States a specific verb and resource plus a scope qualifier ('permanently'), and the preview/confirm framing makes clear this is the destructive end-state operation. It does not explicitly contrast itself with the obvious sibling stop_pod, leaving the permanence-vs-suspend distinction to be inferred.

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 an explicit call sequence: preview with confirm=false, obtain user agreement, then re-call with confirm=true. That is clear operational guidance. It stops short of naming alternatives (stop_pod for reversible shutdown) or stating when deletion should not be attempted at all.

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 substantial non-obvious context: the default is a non-mutating preview, the user must agree before confirming, and operation_id must be reused across retries or a new operation is created. This is exactly the kind of guidance annotations 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?

The preview/confirm contract is front-loaded in the first two sentences, followed by operation_id rules and timeout recovery. Every sentence adds operational information; nothing is filler.

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

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

For a destructive, open-world write tool with an output schema (so return values need no explanation), the description covers the confirm gate, operation identity, and failure recovery — everything needed to invoke it 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?

With 0% schema description coverage, the description must carry the load, and it thoroughly explains confirm (default false, preview semantics) and operation_id (UUID generation, reuse rules). The required 'serving' integer parameter is never explained — no hint that it is a serving ID — leaving a gap for one of three parameters.

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

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

States a specific verb and resource: 'Delete a serving and its endpoint.' An agent can immediately distinguish this from siblings like deploy_serving, scale_serving, pause_serving, and servings.

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 documents the two-step flow (confirm=false preview, then confirm=true), the operation_id requirement, and the timeout recovery path via operation_status. Names a concrete alternative behavior rather than leaving the agent to infer it.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds substantial beyond-schema context: the dry-run preview behavior, what the preview includes (pods that mount it), the storage_in_use refusal, and operation_id idempotency semantics. It does not explicitly say the deletion is irreversible beyond 'all data on it', but the core behavioral traits are well 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 destructive action and preview-first pattern are front-loaded, which is appropriate for a dangerous tool. It is dense with multi-line formatting but each sentence carries operational value; it could be slightly tightened but is not bloated.

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 described, and annotations cover the safety profile. The description fills the remaining gaps: dry-run flow, sibling reference for the storage identifier, error condition, and operation_id lifecycle. An agent has everything needed 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It documents `storage` as the pv_name from the storages tool, explains `confirm` semantics precisely, and defines `operation_id` use across preview, confirmation, and retries. Only `workspace` is left undocumented, which is a minor gap.

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

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

States a specific verb and resource with scope: 'Delete a storage volume and all data on it.' This clearly distinguishes it from create_storage, update_storage, and connect_storage siblings. An agent can tell exactly what this tool does without opening the schema.

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

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

Explicitly describes the two-phase workflow: confirm=false returns a preview, confirm=true executes after user agreement. It also names the refusal condition (storage_in_use), the required operation_id handling, and timeout recovery guidance. This is near-complete 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?

Annotations only say non-readOnly, non-idempotent, openWorld. The description goes well beyond: it discloses the billing model (per replica per hour, worst case = price_cap × max_replicas), a preview-before-commit safety gate, and the operation_id idempotency contract (reuse across retries, new ID = new operation). That is exactly the behavioral context annotations cannot express.

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 core deploy/preview behavior is front-loaded in the first three sentences, which earns its space. The trailing operation_id paragraph is generic cross-tool guidance that dilutes focus slightly, but nothing is verbose 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 risky bits (cost, confirmation, retries) are well covered. However, for a 10-parameter financial-impact mutation with zero schema descriptions, half the parameters remain semantically opaque, leaving the definition short of 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% with 10 parameters, so the description must compensate. It meaningfully explains confirm, price_cap_per_hour, max_replicas (via the cost formula), model_registration_id, and operation_id, but leaves autoscale, min_replicas, max_context_tokens, share_idle_capacity, and workspace completely undefined.

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?

"Deploy an already-registered model as a serverless serving (inference endpoint)" names a specific verb, resource, and clarifies what a 'serving' actually is. It also implicitly separates this from register_model (which comes before) and from sibling lifecycle tools like scale_serving/pause_serving/delete_serving.

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 states the two-phase flow: confirm=false returns only a cost summary, then call again with confirm=true after user agreement. It also routes the agent to the models tool for model_registration_id or register_model first, and gives operation_id reuse rules including what to do after a timeout.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral detail: no resource is created, statuses are enumerated, failures mean the repo could not be read, and auth may be needed for private repos.

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 important information is front-loaded: what the tool checks and that nothing is created. The status semantics and context_length note are compact and every sentence adds useful operational meaning.

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 fully described, and annotations cover the safety profile. However, with 0% schema description coverage, the description should explain all three parameters, and the workspace parameter is omitted.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It explains the huggingface_repo format and the purpose of hf_token_id for private repos, but the workspace parameter is not addressed at all.

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: checking whether a Hugging Face repo can be served. It also distinguishes itself from registration by saying 'before registering it; nothing is created,' which helps separate it from sibling tools like register_model.

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: run this before registering a model, and pass hf_token_id for private repos. It does not explicitly name register_model as the follow-up action, but the workflow context is 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?

Annotations already declare readOnly/idempotent/non-destructive, so the description focuses on what they can't convey: links are temporary with an expiry, file contents are never returned, and linked assets yield nothing. It omits any auth or rate-limit context, keeping it just short of a 5.

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

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

Three tight sentences: capability first, then return shape, then narrowing and the edge case. Every sentence adds information with no restatement of the name or 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?

Covers the operational essentials for a read-only tool: what comes back (`path`, `size_bytes`, `url`, expiry), that contents are not included, and the linked-asset dead end. Some return detail overlaps with the existing output schema, and the asset/task selection rule is left implicit.

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 carries the burden and does: it explains the `asset_...`/`task_...` ID prefixes and gives concrete glob examples for `paths` (["config/*", "*.safetensors"]). It does not clarify the mutual-exclusivity or optionality relationship between `asset` and `task`, despite zero required parameters.

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

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

States a specific verb (get) and resource (temporary download links) and immediately splits the two modes: an asset's files vs a task's output files. An agent can distinguish it from siblings like `assets` or `tasks` without opening the schema.

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

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

Gives clear selection context (use `asset` for asset files, `task` for task outputs) and an explicit exclusion: linked assets fetched from Hugging Face or CivitAI have no download links. It stops short of naming an alternative sibling tool or stating that exactly one of `asset`/`task` must be supplied.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive, and the description reinforces this by stating nothing is created and no credit is spent. It also adds behavioral context beyond annotations, including that max_price_per_hour is checked against the estimate, that over-cap placement fails asynchronously, and that local volumes are billed hourly even while stopped and after pod deletion.

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 call order, then proceeds through parameters in a dense but mostly purposeful way. Given 28 parameters and 0% schema coverage, most sentences earn their place, though the result is a long wall of text that could be easier 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 complex 28-parameter tool with no schema descriptions but an output schema and useful annotations, the description provides enough operational context to construct estimates correctly. The output schema covers return values, and the description fills in pricing, storage, port, asset, and token behavior beyond what structured fields provide.

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 carry parameter meaning, and it does so for most of the 28 parameters: workspace, template_id, GPU/CPU sizing, volumes, local_volumes, ports, env, command, input_assets, watched folders, model_set, and hf_token_id all get concrete syntax and behavior. However, it does not explain notable parameters such as rental_type, cpu_premium, uptime_premium, or internet_premium, so it stops short of full coverage.

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

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

The description states a specific verb and resource: estimate the hourly price of a pod before creating it. It immediately distinguishes this from the mutation sibling by saying nothing is created and no credit is spent, and directs the agent to call create_pod afterward. An agent can tell exactly what this tool is for 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?

It gives an explicit call order: call estimate_pod first, show the user the price and hardware, then call create_pod with the same arguments. This directly names the alternative and the condition that selects it, leaving little 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?

Goes well beyond the readOnly/idempotent/non-destructive annotations: it explains that nothing executes, that max_price_per_hour caps only the compute rate while storage, Asset Hub retention and fetch-time charges are billed separately, and that the estimate is not a total-bill ceiling. It also discloses the output_include null-filter edge case, which is exactly the kind of surprising behavior an agent needs.

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

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

Front-loads the core purpose and the 'nothing runs' guarantee, then groups parameters logically. It is dense and some sentences run long (the output_include glob sentence), but nearly every clause carries operational information an agent would otherwise have to guess.

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 description covers the compute-pricing model, resource selection, and output filtering thoroughly. The remaining gap is the undocumented set of ancillary parameters (env, args, workspace, secret_keys, webhook_url, requirements) on a fairly complex 18-parameter tool.

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 coverage across 18 parameters the description carries the full burden, and it delivers for the important ones: script size limit and flush requirement, image/template_id, the mutually exclusive gpu_model vs cpu_preset choice with concrete preset examples, max_duration's 3600..86400 range, input_assets attachment syntax, and output_include glob semantics. However, env, args, workspace, secret_keys, webhook_url and requirements get no explanation at all, leaving roughly a third of the parameters undocumented anywhere.

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 ('Estimate a one-off task's compute hourly price') and immediately bounds the scope with 'nothing runs', which cleanly separates it from submit_task and from estimate_pod. An agent can tell what it returns (a price) without opening the schema.

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

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

The phrase 'before submitting it; nothing runs' gives a clear usage context and implies the pairing with submit_task, and the max_price_per_hour caveat warns about misusing the estimate as a bill ceiling. It stops short of explicitly naming submit_task as the follow-up or stating when estimate_pod would be preferred over this 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?

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the description correctly focuses on what annotations can't convey: an auth-dependent response shape (prices without a key, availability plus max GPUs per pod with one). That is genuinely useful behavioral disclosure; rate limits or caching behavior are not mentioned.

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: what it returns first, then the auth-dependent behavior, then the two parameter hints. Every sentence carries information and nothing is repeated from the schema or annotations.

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-value detail is correctly omitted, and the auth-tier and filtering behavior are covered. The remaining hole is the undefined `rental_type` vocabulary, which an agent would need in order to actually pass a non-default value.

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 carry parameter meaning and it largely does — "spot" for the preemptible tier and `min_vram_gb` as a VRAM filter. The gap is that the schema defines `rental_type` as a free-form string with no enum, and the description never states the full set of valid values or the "demand" default.

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: show GPU types available for rent now, with per-GPU hourly USD prices. It is clearly distinguishable from mutation-oriented siblings like create_pod or estimate_pod. It does not explicitly contrast itself with the near-twin `cpus` sibling, so it stops short of the top score.

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: it works anonymously for prices but needs a key for live availability, and it tells the agent to use `rental_type` "spot" for the cheaper preemptible tier. What's missing is any statement about when to prefer this over `estimate_pod` (cost estimation) or `machines` before creating a pod.

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

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

Adds substantial behavior beyond the annotations: nothing is copied, the asset is available immediately, there is no storage charge, and consuming pods download from the source at start time. It also discloses the auth requirement (saved token/key id in `source_credentials`), an error-handling instruction, and the operation_id contract (reuse the preview ID, a new ID means a new operation, check `operation_status` after a timeout) — which meaningfully clarifies the annotated idempotentHint=false.

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

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

Front-loads the core action and source formats before diving into side effects and the operation_id protocol; nearly every sentence carries new information. It is a dense multi-concern block, however, and the operation_id paragraph could be tightened or split for scanability.

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 are legitimately omitted, and the description covers the heavy concerns for a 9-parameter import: source shapes, credentials, subsetting, no-copy billing implications, and retry/idempotency protocol. Remaining gaps are the semantics of `workspace`, `name`, and `asset_type`, plus any pointer to how the resulting asset is then consumed via `assets`.

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 must carry the load, and it does for the most consequential parameters: `source` formats, `paths` glob semantics, `revision` semantics, `hf_token_id`/`civitai_key_id` sourcing, and the `operation_id` lifecycle. It leaves `name`, `workspace`, and `asset_type` entirely unexplained, and doesn't reconcile the 'every write requires operation_id' claim with the schema marking it nullable/default null.

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

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

States a concrete verb ('Link') plus the resource and its target type ('as an Asset Hub asset'), and enumerates the accepted source forms (HF repo 'owner/name' or URL, CivitAI URL, direct file URL). The follow-on clause 'so pods and tasks can use it as `input_assets`' makes the effect distinguishable from sibling tools like `assets`, `detect_model`, or `source_credentials`.

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

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

Explains the operating context clearly: use this so pods/tasks can download the artifact, use `paths` globs to link a subset, `revision` to pin a branch/tag/commit, and `source_credentials` ids for private/gated sources. It gives no explicit when-not or named alternative tool (e.g., versus `assets` or `detect_model`), so it stops short of full routing guidance.

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

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

Annotations already declare read-only/idempotent/non-destructive, so the bar is lower, yet the description goes far beyond: it explains the watcher start-and-wait behavior, the 64 KiB cap flagged by `truncated`, the `next_cursor` continuation model for external providers, the flush=True requirement for task scripts, and the meaning of a `none` source or "may be behind" note. It also flags the prompt-injection risk of log content, which no annotation conveys.

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 core action and its two addressing modes are front-loaded, and each subsequent clause carries operational content (fallback behavior, pagination, size cap, safety note). It is dense rather than padded, though the final safety sentence is long and could be tightened.

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 7-param, zero-required read tool with subtle async behavior, the description covers addressing, waiting semantics, pagination, truncation, and the empty-output case. An output schema exists, but the description still usefully names the `next_cursor`, `truncated`, and `none` fields an agent must react to.

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% across 7 params, so the description must carry the load, and it explains 6 of them: `pod` (name or display name, requires `workspace`), `task` (task_id), `tail` (≤1000), `wait` (default 8), and `cursor`. Only `container` is left undefined in both schema and 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?

Opens with a specific verb and resource plus scope: read the last `tail` lines (≤1000) of a pod's or a task's logs. The dual-target nature (pod vs task) is stated immediately, which distinguishes it from adjacent siblings like tasks or pods that only list objects.

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

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

Gives a clear use case ("see why something is not working") and explicit branch conditions: pass `pod` with `workspace` or `task` with `task_id`; call again with wait > 0 when a watcher couldn't start; pass `cursor` to read only new lines. It does not name alternative tools (e.g. operation_status for task status vs logs), so the routing against siblings is incomplete.

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/openWorld, so the safety profile is covered. The description adds real behavioral detail beyond that: the fields each item carries (online status, GPU model/count, hourly earnings, uptime 0..1) and the constraint that live metrics are single-machine only. Pagination and rate-limit behavior 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 the purpose and the list-vs-single distinction, then units. It is dense but every clause carries information; the unit-conversion arithmetic is the only part bordering on over-specification.

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 an output schema present, the description doesn't need to enumerate return fields, yet it does so usefully for units. The real gap is that a paginated list tool (limit/cursor, 0% schema coverage) never explains how paging works or what the cursor represents.

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 carry the load. It explains `include_metrics` and the meaning/units of everything inside `metrics`, but says nothing about `limit` or `cursor`, and it refers to 'machine_id' while the actual parameter is named `machine`, which could cause a mis-invocation.

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 their machines, or show one by machine_id') and scopes it to users who host hardware on Meshive. The list-vs-single distinction is explicit, so an agent can pick the right mode without opening the schema.

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

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

Gives clear context (hosting users) and a conditional instruction: set `include_metrics` for a single machine's live usage, which implicitly rules it out for bulk listing. No sibling alternative is named (e.g., cpus/gpus), so it stops short of full routing guidance.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real context beyond that: the registration_id is the handoff key to `deploy_serving` and workspace accepts either an id or a label. It stops short of describing list size, ordering, or pagination behavior, which is the remaining gap for a 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?

Three short sentences, each doing distinct work: what it lists, how to create a new entry, and how to fill the one parameter. Front-loaded with the purpose and zero 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 explained, and the description covers routing, the parameter source, and the downstream handoff. It is slightly thin on what a returned list looks like when empty or whether results span all workspaces when the parameter is omitted, but it is sufficient to call correctly.

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

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

Schema coverage is 0% and the single parameter has no title-level description, so the description carries the burden and does it well: `workspace` takes the id from the `workspaces` tool, a label also works, and it may be omitted when the user has only one workspace. Only the exact format of a label is left implicit.

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

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

States a specific verb and resource ('List the models a workspace registered for serving') and immediately ties the result to a downstream consumer by naming `registration_id` as what `deploy_serving` takes. This separates it cleanly from `model_sets`, `register_model`, and `deploy_serving` without needing 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?

Explicitly routes the creation path to `detect_model` and `register_model`, and gives a concrete conditional for the optional parameter ('omit it if the user has only one'). It also tells the agent where the workspace value comes from, so there is nothing left to infer about when and how to call this.

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

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

Annotations already cover read-only/idempotent safety, but the description adds real behavioral context the annotations cannot: `hf_token_required` semantics (downloads use the user's own workspace token), what a nonzero `license_unknown_count` implies for downstream claims, and how `gated_sources.mode` ("auto" vs "manual") changes access. The instruction to treat catalog names/descriptions as data is a valuable prompt-injection guard.

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

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

Front-loaded with purpose and the actionable slug-passing instruction before any field documentation, and every sentence carries semantic weight. It is dense but long, and the later field enumeration partially duplicates the existing output schema, so it is not maximally tight.

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?

Rich enough for an agent to call correctly and interpret the tricky fields (VRAM estimates, licensing, gating) despite a bare 2-parameter schema. The residual gap is parameter-level: no guidance on `template_id` provenance or the optional `workspace` fallback, though output semantics are more than covered.

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 carry parameter meaning. It explains the relationship between `template_id` and the downstream `model_set` slug, but never says where `template_id` comes from (the `templates` tool) and never mentions the `workspace` parameter at all.

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

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

States a specific verb and resource (list the model sets a pod template recommends) and grounds it in the console's model-set tiles, which makes the concept immediately graspable. It also distinguishes the output from the generic 'models' sibling by tying every set to a template_id.

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

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

Explicitly tells the agent how to consume the result: pass a set's `slug` as `model_set` to estimate_pod/create_pod with the same `template_id`, and one pod takes one set. It also covers the negative case (`selectable` false with `reason` means no sets apply), but never contrasts the tool against siblings like `models` or says when not to call it.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's job is semantics — and it delivers: 'done means the API response was saved; poll the returned task/transaction for actual execution' tells the agent the status is about acceptance, not completion. The reconciliation rule for pending/unknown prevents a duplicate-write failure mode that no annotation conveys.

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 short sentences, front-loaded with the action and its constraint, then input sourcing, then status semantics, then the failure rule. Every sentence adds information an agent needs and none repeat structured fields.

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

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

Output schema exists, so return values need no explanation here; the description instead covers the things the schema cannot — what 'done' actually means, what to do next, and what never to do. Nothing needed to invoke this 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 0%, so the description carries the full burden, and it largely does: it names the source of operation_id and clarifies method/path with concrete examples (submit_task=POST /tasks, create_pod=POST /pods). It loses a point because it refers to a nested 'operation_lookup.method/path' that does not match the flat three-parameter schema, leaving the exact path format (version prefix, query string) unresolved.

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 ('check a write's durable acceptance record') plus the negative scope ('without submitting it again'), which immediately separates it from the write siblings like submit_task and create_pod. An agent can tell it apart from the mutating 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?

Explicitly says where the inputs come from ('operation_id and operation_lookup.method/path from the write result/error') and gives a hard rule for the ambiguous case ('pending/unknown require reconciliation, never a new operation_id'). That is an explicit when-to-use plus a when-not-to-do-something-else, which is the top of this scale.

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

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

Adds substantial behavior beyond annotations: paused servings stop billing and stop answering requests, resuming restarts billing, and the confirm flag gates the costly direction. It also explains the operation_id contract (new ID = new operation, keep it across retries), which is exactly the kind of context the idempotentHint annotation 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?

Front-loaded with the core action and mode semantics, then confirmation gating, then the operation_id contract, then timeout recovery. Every sentence carries information, though the operation_id paragraph is dense and could be broken into shorter statements.

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. For a mutation tool the description covers prerequisites, confirmation flow, idempotency, and failure recovery well; the only shortfall is the undocumented `serving` identifier.

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 carry parameter meaning — and it does for three of four: paused (true/false semantics and consequences), confirm (default false and what each value does), and operation_id (reuse from preview or generate a UUID, keep for retries). The required `serving` parameter is never explained, leaving a gap.

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

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

States a specific verb (pause/resume) plus the resource (a serving) and immediately clarifies the two modes via the paused flag. It does not explicitly distinguish itself from siblings such as scale_serving, delete_serving, or deploy_serving, which an agent may also consider when changing a serving's lifecycle.

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

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

Gives explicit conditional guidance: pausing needs no confirmation, while resuming (paused=false) with confirm=false only previews state and requires a second call with confirm=true after user agreement. It also prescribes recovery behavior after a timeout (check operation_status and resource state before retrying).

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new behavior: system downloader pods are hidden unless include_system, are free and cannot be stopped/deleted; secret values return null unless show_secrets, and read-only API keys return "***". It also explains stop_reason_code and same_node_unavailable_reason semantics for diagnosing stopped pods.

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 dense sentences, each carrying distinct information, with the primary list-vs-single-pod distinction front-loaded. Some return-shape detail (endpoints, connect_credentials, MiB units) is packed into the middle and could be trimmed given an output schema exists, but nothing is filler.

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

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

An output schema exists so return-value explanation is bonus rather than required, and the description still covers the tricky parts (secret nulling, system pod visibility, stop diagnostics). The only real omission is pagination behavior via limit/cursor, which matters for an 8-parameter list tool.

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 carries the load and documents six of eight parameters meaningfully — pod, workspace (id/label/"all"), status (filter), include_system, include_metrics, show_secrets — plus units for returned metric fields. The pagination pair (limit, cursor) is never mentioned, leaving a gap for a tool with a limit/cursor 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?

Opens with a specific verb and resource ('List the pods (GPU/CPU containers)') and immediately declares the two modes: list within a workspace, or show a single pod by pod_name/display name. An agent can distinguish this read tool from siblings like create_pod, stop_pod, or gpus without opening the schema.

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

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

Explicit routing rules: pass workspace="all" to span workspaces, omit it when the user has only one; set include_metrics only for a single pod; use show_secrets with a single pod only when the user asks for the login. It even states the fallback behaviors (display name works as pod_name, labels work as workspace id).

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

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

Annotations already cover safety (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the description correctly spends its words elsewhere: no cost at registration, download deferred until deploy, private-repo auth via hf_token_id, and retry/timeout semantics tied to operation_id. The only weakness is a mild tension with idempotentHint=false, since 're-registering returns the existing registration' reads as idempotent behavior—though it is arguably about identity rather than effect.

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 core purpose, cost model, and prerequisite are front-loaded in the first two sentences, with mechanics after. The operation_id paragraph is somewhat generic boilerplate that likely repeats across all write tools, but it is justified given the retry guidance.

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 annotations carry the safety profile; the description supplies the non-structured essentials (prerequisite, deferred download, dedupe, auth, retry). Only the undocumented optional parameters (name, workspace, context_length) leave a real gap for an agent configuring a registration.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partly does: it explains `framework` (vllm default or sglang), `hf_token_id` provenance (from source_credentials), and `operation_id`, but says nothing about `name`, `workspace`, or `context_length`. Roughly half of the 7 parameters remain undocumented anywhere.

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 ('Register a Hugging Face model for serving') plus the immediate output contract ('return its `registration_id` for deploy_serving'), which chains it to the correct downstream sibling. It is clearly distinguishable from detect_model, models, model_sets, and deploy_serving.

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 names a prerequisite ('Run detect_model first'), states the repeat-call behavior ('registering the same repo again returns the existing registration'), and routes the result to deploy_serving. It also explains the operation_id discipline and what to do after a timeout (check operation_status).

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds substantial traits beyond them: the restart preserves machine and storage, execution is asynchronous, and the operation_id protocol governs retries so a new ID means a new operation. The timeout-then-verify-instead-of-retry advice is exactly the kind of hazard disclosure annotations cannot carry.

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 most important fact (in-place, asynchronous) before the operation_id protocol, and every sentence carries real operational information. It is dense but not padded, though it could be split slightly more clearly between 'what it does' and 'how to call it'.

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 described, and the async/polling/retry lifecycle is well covered for a mutating tool. Gaps remain around preconditions (must the pod be running?), what happens to in-flight work on the pod, and when to choose start_pod instead.

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 carry parameter meaning. It thoroughly explains the least obvious parameter (operation_id: reuse the preview's ID or generate a UUID, keep it for confirmation and retries), but `pod` and `workspace` — including the nullable default — get no explanation at all.

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 ('Restart a pod') plus distinguishing scope detail: 'in place (same machine, same storage)'. That scope phrase implicitly separates it from stop_pod/start_pod and delete_pod+create_pod, but it never names those siblings 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?

Gives clear operational context — it is asynchronous, so poll pods for `running`; every write needs an operation_id reused across retries; after a timeout check operation_status before retrying. What is missing is explicit selection guidance among siblings (start_pod vs restart_pod vs delete+create).

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

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

Adds substantial context beyond the annotations: which edits are gated behind confirm=true, which apply immediately, the two-phase preview-then-confirm protocol, and the retry rule after a timeout. The operation_id guidance (reuse the ID; a new ID means a new operation) directly explains the idempotentHint=true contract in operational terms.

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?

Mutation surface is front-loaded in the first sentence and the confirm rule follows immediately, so the important information leads. The second sentence is an em-dash run-on that packs three cases together, costing some readability, but no sentence is disposable.

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 re-described, and the description still tells the agent that a preview returns current state plus the requested change. For a 7-parameter mutation tool the operational story is complete; only the serving identifier format is left implicit.

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 carries the load, and it does explain confirm, autoscale, min/max replicas, price_cap_per_hour, and operation_id semantics well. The one gap is the required `serving` parameter—identity format (numeric ID vs name) and min<=max constraints are never stated.

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?

Opens with a specific verb and resource plus the exact mutables: 'Change a serving's replica range, autoscaling, or per-replica price cap.' That cleanly separates it from deploy_serving, pause_serving, and delete_serving, which are the adjacent siblings an agent could confuse it with.

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?

Strong conditional routing inside the tool: cost-raising changes with confirm=false only preview, while lowering the range / disabling autoscale / lowering the cap apply immediately. It does not name sibling alternatives (e.g. deploy_serving for initial creation, pause_serving for stopping), so an agent must infer those from the sibling list.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered; the description adds real value beyond that by summarizing the payload (replica counts, status, endpoint_url, hourly price in USD) and explaining cross-tool resolution of the workspace id. It does not mention pagination behavior, even though limit/cursor exist.

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: purpose first, payload second, parameter semantics third. No filler, and the most decision-relevant information (what it lists, what it returns) is front-loaded.

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

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

With a read-only tool, full annotation coverage, and an output schema that documents return values, the description covers what an agent needs to select and call it. The only meaningful omission is pagination guidance for limit/cursor, which the output schema and conventions partially imply.

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 carry parameter meaning. It explains `workspace` thoroughly (id source, 'all', omit-if-single) and implies `serving` via 'show one by serving_id', though that name does not match the actual schema key `serving`. `limit` and `cursor` are never mentioned, leaving the pagination parameters undocumented anywhere.

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

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

States a specific verb and resource ('List the serverless model deployments (servings)') and covers both modes: bulk listing in a workspace or fetching a single item by id. An agent can immediately distinguish this read tool from the sibling mutations (deploy_serving, scale_serving, delete_serving).

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 concrete routing guidance for the workspace parameter ('id from the workspaces tool', 'pass "all" for every workspace', 'omit it if the user has only one'), which resolves the main ambiguity in calling this tool. It does not explicitly contrast with alternatives such as querying pods or model_sets, but the usage context is otherwise 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?

Annotations already declare idempotent/non-read-only/non-destructive, and the description adds substantial context on top: storage cost implications of enabling folders, the preview-vs-apply asymmetry (adds are gated by confirm, removals apply immediately), and optimistic concurrency via expected_version. The `operation_id` retry contract and the timeout guidance toward operation_status are exactly the kind of behavioral detail annotations can't express. It stops short of saying what happens to files under a folder that is dropped from the set, which is the one behavior a caller most needs to know given a whole-set replace.

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

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

Front-loaded with purpose and the read-first instruction, then progressively more conditional detail. Dense but nearly every sentence carries operational weight (shapes, cost gate, version conflict, operation_id). The template-move workaround is long and slightly tangled, but it prevents a real failure mode, so it earns its space.

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 7-parameter, whole-set-replacement mutation with optimistic locking and a two-phase confirm flow, the description covers purpose, data shapes, concurrency, cost gating, and retry semantics, and it can lean on the existing output schema for return values. It is nearly complete except for the undocumented `workspace` parameter and the unspecified effect on files in folders removed by the replace.

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 must carry every parameter, and it does for most: concrete shapes for `template` and `user`, the meaning of `expected_version`, the default/false semantics of `confirm`, and the operation_id lifecycle. The notable gap is `workspace`, which is never mentioned anywhere and remains fully opaque. `pod` is only implied by context.

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 opening sentence gives a specific verb and resource (replace a running pod's watched folders) plus the key operational property that it applies without a restart. It also names the sibling `watched_folders` as the read counterpart, so an agent can separate this write tool from the read tool immediately.

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

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

It states the workflow explicitly: read watched_folders first, send the WHOLE set back, carry `revision` into `expected_version`, and re-read on conflict. It also gives the precise alternative path for the case this tool can't handle (template folder can't be moved — disable it and add the path to `user`), plus the confirm=false → confirm=true agreement gate.

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, so the safety profile is covered; the description still adds meaningful context beyond them — secrets are never returned, and credentials are provisioned in the console rather than here. It doesn't mention ordering, empty-workspace behavior, or limits, which keeps it off a 5.

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

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

Three tight sentences, front-loaded with purpose and the secret-safety guarantee, then invocation guidance and parameter guidance. No filler; every sentence carries distinct 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 read-only, one-optional-parameter tool with annotations and an output schema, the description covers purpose, downstream usage, credential creation path, and parameter fallback behavior. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 0% and the single `workspace` parameter is undocumented in the schema, so the description must compensate — and it does, explaining that it takes a workspace id, that a label also works, and that it may be omitted for single-workspace users. Minor gap: no format example for the id.

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

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

States a specific verb and resource ('List the Hugging Face tokens and CivitAI keys saved in a workspace') and immediately scopes the return to id and label only. An agent knows exactly what this returns and that no other sibling tool does this.

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 routes the agent: pass an id as `hf_token_id`/`civitai_key_id` to detect_model, register_model, or import_asset for private or gated sources, and notes credentials are added in the console (so this tool cannot create them). The workspace sourcing rule (id from workspaces tool, label also works, omit if only one) is spelled out.

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

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

The description says `each call issues a new password`, which contradicts the annotation `idempotentHint: true`; repeated identical calls would produce new credentials rather than no additional effect. Although the description otherwise adds useful security and expiry context, this direct conflict is serious enough to score 1.

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 safety instructions are front-loaded, which is good. However, the generic operation_id/write-retry paragraph is lengthy and confusing for a tool whose schema has no `operation_id` field, so not every sentence clearly earns its place.

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

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

The description covers the main return values and key safety constraints, and an output schema exists so return formatting need not be explained. Still, it omits input parameter semantics and introduces an `operation_id` requirement that is not represented in the schema, leaving gaps 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 the two input parameters. It only implies that a `pod` is involved and never mentions the optional `workspace` parameter, leaving both parameters 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 states a specific verb and resource: issuing a one-time SSH login for a pod, and names the returned artifacts (`command`, `password`, `expires_at`). This is distinguishable from generic pod lifecycle siblings and tells an agent exactly what the tool produces.

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 guidance (`only when the user asks to connect`), clear prohibitions (`never run the command yourself or put the password in files, commits or other tools`), and a recovery path (`check operation_status` after a timeout). This leaves little ambiguity about invocation context.

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

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

The description says any_node and wait_any_node can permanently delete unpreserved workspace files and that allow_data_loss is required for explicit consent. This contradicts the annotation destructiveHint=false, which declares the tool non-destructive.

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 long but appropriately front-loads the core behavior and confirmation model before covering placement and data-loss semantics. It is dense and somewhat run-on, but most sentences carry operational information needed for 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?

It covers the confirmation flow, placement choices, data-loss consent, billing resumption, asynchronous polling, and operation_id retry behavior. The main gap is that the workspace parameter is not described, and the destructive data-loss behavior creates annotation inconsistency.

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 carry parameter meaning, and it explains confirm, the placement values, allow_data_loss, and operation_id in useful detail. However, it does not explain the workspace parameter at all, leaving one of the six parameters undocumented.

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: start a stopped pod, and notes that hourly billing resumes. It also distinguishes the action from siblings such as stop_pod and restart_pod by focusing on starting an already-stopped pod.

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 two-step confirmation guidance: confirm=false only previews state and price, and confirm=true should be used only after the user agrees to pay again. It also details when to omit placement versus choose each placement option, and when allow_data_loss may be set.

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 the annotations, the description discloses billing behavior: pod billing stops but attached storage keeps being billed. It also discloses the asynchronous nature of the change, the polling pattern, and the retry semantics around operation_id and operation_status.

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 scope, then follows with the delete_pod alternative, async polling, and operation_id rules. Every sentence provides actionable guidance for correctly invoking or retrying the tool.

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 an output schema exists, the description does not need to explain return values, and the annotations already cover safety/idempotency. It is nearly complete for an async mutation tool, but the `workspace` parameter remains unexplained.

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 does substantial compensation: it defines `pod` as the pod_name from the pods tool and explains operation_id reuse and retry behavior in detail. However, the optional `workspace` parameter is never described, so one of the three parameters remains undocumented.

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: stop a running pod by scaling to zero. It also distinguishes this from delete_pod, which removes the pod entirely, so an agent can select between them without opening either 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?

It explicitly says to use delete_pod to remove the pod entirely, and explains that stopping is asynchronous and requires polling pods for `stopped`. The operation_id guidance also tells the agent how to handle preview/confirmation/retries and timeout recovery.

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

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

Adds substantial context beyond annotations: billing stops, the task must be queued or running, operation_id must be reused for retries, and a new ID means a new operation. It also advises checking operation_status and resource state after a timeout, which is important behavioral guidance for a mutation tool. This is consistent with idempotentHint=true and destructiveHint=false.

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 provides necessary operational details. It is efficient, though the phrase 'Every write requires operation_id' is slightly broader than this specific tool and could be tightened.

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 an output schema exists, the description need not explain return values. It covers the mutation's effect (billing stops), prerequisites (task_id source), idempotency guidance, and timeout handling—complete for an agent 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?

Schema description coverage is 0%, but the description fully compensates: it explains that `task` is the task_id from the tasks tool, and it details `operation_id` semantics—required for writes, reuse the preview ID or generate a UUID, keep it across retries, and a new ID creates a new operation.

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 ('Stop a queued or running task') and clarifies the task scope (queued or running). It also identifies the source of the task identifier, distinguishing it from siblings like stop_pod and submit_task without needing 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 conditions for use: stopping queued or running tasks, with billing implications. It also provides operational guidance for operation_id and retry behavior after timeouts, though it does not explicitly compare against alternatives like delete or restart.

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/openWorld, so the safety profile is covered. The description adds real behavioral context beyond them: the units of total_size and available_size (MiB, with a GiB conversion hint), the 0..1 range of usage_rate, and the meaning of linked_pods. It says nothing about pagination behavior despite limit/cursor existing, which keeps it off a 5.

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

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

Three sentences, front-loaded with the two operational modes and then the field semantics. Every sentence carries information; the only slight inefficiency is that unit/semantics detail precedes the workspace guidance an agent needs to pick arguments.

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-value explanation is largely redundant (though the unit hints are still helpful). What is missing is pagination: with limit and cursor in the schema and a list-shaped tool, an agent has no idea whether results are truncated or how to iterate, and the storage/pv_name naming mismatch 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?

Schema description coverage is 0%, so the description must compensate, and it only partially does: `workspace` is fully explained (id source, "all", omission) and `storage` is obliquely covered by the reference to `pv_name`. However `limit` and `cursor` are never mentioned and the description names the parameter `pv_name` while the schema calls it `storage`, leaving an agent to map the two.

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

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

States a specific verb and resource ('List the storage volumes') plus the second mode ('show one volume by its `pv_name`'), which immediately separates it from create_storage, update_storage, delete_storage and connect_storage. An agent can identify it as the read-only enumeration tool from the description alone.

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 concrete conditions for the `workspace` argument: take the id from the workspaces tool, pass "all" for every workspace, or omit when the user has a single workspace. It does not explicitly contrast the list mode with the single-volume mode or warn about needing pv_name to fetch one item, so there is no explicit when-not guidance, but the usage context is 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?

Beyond the annotations, it discloses billing behavior ('billed while it runs, up to max_duration'), that max_duration is a hard stop, that max_price_per_hour caps only compute and not storage/retention/fetch charges, and that the estimate is not a total-bill ceiling. It also explains output_include filtering semantics and the requirement to reuse operation_id across confirmation and retries.

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 long but front-loads the core purpose and confirmation workflow before moving into execution, pricing, asset, output, and retry details. Most sentences carry useful constraints, though the output_include null-handling sentence is slightly convoluted and the overall length is substantial.

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 the description need not explain return values, and it already covers the critical workflow, billing, output filtering, and retry behavior. It is nearly complete for safe invocation, with minor gaps around several secondary parameters (workspace, secret_keys, requirements, webhook_url).

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 across 20 parameters, the description carries the explanatory burden and does so well for the ambiguous/complex ones: script/image/template_id, gpu_model/gpu_count/gpu_vram_gb/cpu_preset, max_duration, max_price_per_hour, input_assets, output_include, confirm, and operation_id. It leaves several parameters (env, args, workspace, secret_keys, webhook_url, requirements) to inference, which keeps it from a 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?

The description opens with a specific verb and resource: 'Submit a one-off task (a script that runs to completion on a GPU or CPU).' It distinguishes the tool from long-running pod tools by defining the task as one-off and to-completion, and it explicitly names the sibling tools used for follow-up (tasks, logs).

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 an explicit two-step confirmation workflow (confirm=false returns an estimate; call again with confirm=true after user agreement), explains how to poll status via tasks and read output via logs, and gives retry guidance after timeouts using operation_status. It also states the exact-one-of rule for gpu_model vs cpu_preset.

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, so the bar is lower; the description still adds value by disclosing the status vocabulary and that the detail view surfaces cost and exit code. It stays silent on pagination behavior, which matters because `limit` and `cursor` exist.

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

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

Three short sentences, front-loaded with the two operating modes, then filters, then the workspace caveat. No filler and no restatement of the title.

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

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

Output schema exists so return values need not be explained, and the mode distinction is complete. However, a paginated list tool with `limit` and `cursor` in the schema and zero description coverage leaves the agent without default page size or continuation semantics — a meaningful gap for exactly this kind of tool.

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 carry all parameter meaning. It does well for 3 of 5 (`task` with its 'task_...' shape, `status` with concrete enum-like values absent from the schema, `workspace` with the id-vs-label and single-workspace omit rule), but `limit` and `cursor` are never mentioned, leaving paging entirely undocumented.

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 and resource ('List serverless tasks (one-off GPU jobs)') and immediately clarifies the two modes: list-in-workspace vs. single detail lookup by task_id. The name 'tasks' is ambiguous on its own, so the parenthetical gloss and the id format example do real disambiguation work against siblings like submit_task and stop_task.

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 concrete operational guidance: filter with `status`, use the id from the workspaces tool for `workspace`, and omit workspace when the user has only one. It does not explicitly exclude misuses (e.g., 'do not use to submit or stop tasks'), but the read-only listing intent is unambiguous given the sibling names.

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=true, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds non-obvious behavior beyond them: the default result set is official templates only, and workspace scoping must be requested. It omits any mention of pagination despite `limit`/`cursor` existing.

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 with the primary list mode front-loaded, followed by scoping and then filtering. Every sentence adds a distinct, actionable fact and 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 shape needn't be described, and the dual list/get modes, workspace default behavior and filter vocabularies are all covered. The remaining gap is pagination semantics for `limit`/`cursor` and the `template` vs `template_id` naming mismatch, which an agent must resolve from the schema alone.

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

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

Schema description coverage is 0%, so the description carries the full burden; it partially compensates by enumerating plausible `app_type` values (ide, framework, custom) and `hardware_type` values (gpu, cpu, any) that the schema lacks. However, `limit` and `cursor` are never explained, and the description calls the selector `template_id` while the schema field is `template`, which invites a wrong argument 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 ('List the pod templates') plus the exact scope: official templates by default, official plus a workspace's custom ones when scoped. It also declares the second mode ('show one by template_id'), so an agent knows this single tool covers both list and get without consulting siblings.

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

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

Gives explicit conditional guidance: pass `workspace` to include custom templates, omit it for official-only, and cross-references the `workspaces` tool as the id source. It also names the two filters. It stops short of saying when to prefer this over creating a pod with `create_pod`/`estimate_pod`, so no true exclusions are offered.

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 the annotations, the description discloses important behavior: empty list means nothing in flight, transaction_id lookup has no time window, downloads can pause in verification/storage wait, and init_logs is untrusted text. These details materially affect interpretation of 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 definition is front-loaded with purpose and then supplies dense operational details without obvious filler. It is longer than typical, but the length is mostly justified by the amount of field-level behavior it clarifies.

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 an output schema and rich annotations, the description covers most of what an agent needs: list-vs-lookup behavior, workspace handling, retention semantics, and result interpretation. The main gap is the lack of explanation for limit and cursor.

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 carry parameter meaning. It strongly explains workspace and transaction_id, but limit and cursor are not mentioned at all, leaving pagination semantics undocumented.

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 clear verb and resource: showing in-flight pod operations or one operation by transaction_id, including why it is slow or failed. It is easy to distinguish from generic pod management, but it does not explicitly differentiate itself from the sibling operation_status 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 explicit usage guidance: use the list for in-flight operations, pass transaction_id to inspect how one ended, and note that the list drops finished operations and keeps failures only briefly. It also explains workspace selection, including 'all' and single-workspace omission.

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?

Goes far beyond the annotations: states which fields are locked (pod type, premiums, image), that running pods restart while renames do not, that inputs and watched folders are preserved, that a node move permanently deletes unpreserved workspace files and requires separate consent via allow_data_loss, and that max_price_per_hour refuses an edit. It also discloses the operation_id lifecycle and the timeout-recovery procedure, which no structured field conveys.

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

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

Front-loaded with the core purpose and the confirm preview/apply rhythm, then organized by concern (hardware, template, env/ports, storage, failures). For a 28-parameter mutation tool almost every sentence earns its place, but the single dense block makes it harder to scan than a lightly sectioned version would.

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 an output schema exists, return-value explanation is not required, yet the description still characterizes the preview contents (`changes`, before/after hourly price, `restarts`). Combined with the failure modes, consent gates, and operation_id rules, an agent has everything needed to invoke this correctly and 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?

With 0% schema description coverage across 28 parameters, the description carries the full burden and largely discharges it: it explains gpu_model/gpu_vram_gb/gpu_count versus cpu_line, the reset-vs-preserve rules for vCPU/RAM, pod-total semantics for vcpu/ram_gb, env/secret_keys/remove_env, the three port parameters with a concrete example object, volumes vs local_volumes vs detach_storages, and the consent flags. Only `workspace` goes unmentioned.

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: "Change an existing pod like the console's Edit: pass only what changes," immediately distinguishing it from create_pod/estimate_pod by scoping it to mutation of an existing pod. It also anchors the required `pod` argument to the pods tool, so an agent knows the prerequisite lookup.

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 the two-step flow: call with confirm=false (default) for an estimate, then call again with confirm=true only after the user agrees. It also gives conditional branches for node_migration_required, harvest_roots_orphaned, and enable_folder_saving, each with the exact follow-up argument to pass and the consent required before passing it.

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