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

Annotations indicate destructiveHint=true, so the agent knows this is a destructive operation. The description adds that it returns a request_id for the cancel operation itself, which is useful context beyond the annotations. However, it doesn't explain what happens to the canceled requests, whether cancellation is immediate, or any side effects. With annotations covering the destructive nature, a 3 is appropriate.

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 core action. Every sentence contributes useful information: action, parameter usage, and return behavior.

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

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

The tool has two parameters, one undocumented, and an output schema exists so return values needn't be explained. The description covers the main action and return id but neglects the all_users parameter and lacks guidance on when to use this versus other cancel tools. Adequate but with clear gaps.

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, but it only mentions request_ids and says nothing about the all_users parameter. This leaves one parameter completely undocumented, failing to meet the low-coverage burden.

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

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

States a specific verb+resource: 'cancel pending API requests', which clearly distinguishes it from siblings like skypilot_job_cancel or skypilot_managed_job_cancel. However, it doesn't explicitly differentiate from those cancel siblings or from skypilot_api_stop (which might also cancel server operations). Still, the focus on 'API requests' is reasonably clear.

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

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

The description says to specify request_ids to cancel specific requests, but gives no guidance on when to use this tool versus skypilot_api_stop, skypilot_job_cancel, or skypilot_managed_job_cancel. No when-not conditions or alternatives are mentioned.

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?

readOnlyHint=true already establishes safety, a low bar. The description usefully adds that the response covers health, version, commit, and authentication details. It stops short of describing whether authentication details imply credential exposure or what format is returned, though the output schema covers the shape.

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

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

A single front-loaded sentence with no waste; every listed field adds value for the caller.

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?

Complete for a simple read-only introspection call: no params, annotations carry safety, and an output schema documents return shape. The only omitted element is differentiation from sibling status tools.

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

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

Zero parameters, so the baseline is 4. The description correctly implies no inputs are needed, consistent with the empty schema.

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

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

States a specific verb ('Get') and resource ('SkyPilot API server information') with an enumerated field list, so the agent knows exactly what is returned. It does not distinguish itself from the closely-named sibling skypilot_api_status, leaving ambiguity about which to choose.

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

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

Usage context is implied by the read-only, no-argument nature of the call, but there is no explicit when-to-use guidance or routing to alternatives such as skypilot_api_status or skypilot_api_server_logs.

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

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

Annotations only declare destructiveHint=false, so the description carries most of the behavioral burden. It usefully discloses a significant side effect ('Sets the endpoint globally so all subsequent SkyPilot calls use it') and the OAuth2 re-authentication semantics of relogin, which the annotations do not convey. It omits idempotency behavior and what happens when already logged in, keeping it below 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 the core action before the side effect and the parameter hint. No filler, though the third sentence is somewhat tacked on rather than integrated.

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. However, with 0% schema coverage across three parameters and a global-state mutation, the definition leaves the agent unsure how endpoint and service_account_token interact with the login flow, which is a real gap for a tool whose whole purpose is establishing auth context.

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

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

Schema description coverage is 0%, so the description must compensate, but it only explains one of three parameters (relogin). Neither endpoint nor service_account_token is clarified — e.g., what endpoint means when null, or how a service account token replaces interactive OAuth2 login.

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 first sentence gives a specific verb+resource ('Log in to a remote SkyPilot API server'), which is unambiguous against siblings like skypilot_api_logout, skypilot_api_status, and skypilot_api_info. It stops short of explicitly contrasting itself with those siblings, so it lands just under the top tier.

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

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

Usage is implied rather than stated: the agent can infer this must precede server calls, and the description gives one conditional ('Set relogin=True to force re-authentication'). There is no explicit when-to-use/when-not guidance, no prerequisites (e.g., whether a server must be started first), and no mention of the logout counterpart.

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 supply destructiveHint=true, and the description earns credit beyond that by disclosing exactly what is destroyed ("Clears all cookies and settings") and the precondition (remote servers only). It still doesn't say whether the operation is reversible or what happens if called against a local server, but the added context is substantive.

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 with zero filler; purpose and the destructive effect are front-loaded, and the precondition is held to the end where it belongs.

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 cover the safety profile. The description covers purpose, effect, and precondition; only the failure/edge behavior (e.g., calling it against a local server) is unaddressed, which is a minor gap for a no-arg session 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?

Zero parameters, so the baseline is 4. There is nothing for the description to disambiguate in the schema, and it correctly avoids inventing parameter detail.

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

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

States a specific verb+resource ("Log out of the remote SkyPilot API server") and adds a scope qualifier ("Only works for remote API servers"). An agent can immediately distinguish this from the sibling skypilot_api_login 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 description gives an implied usage condition ("Only works for remote API servers") which is useful, but never names the counterpart tool (skypilot_api_login) or states when an agent should prefer logout vs. other session-ending operations. Adequate but leaves routing 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?

The readOnlyHint annotation already declares this is a safe read operation. The description adds that it returns a snapshot of the log output, which usefully clarifies it is not a streaming or follow interface, but it leaves out whether it requires prior authentication or how large the snapshot might be. With annotations covering safety, this modest addition merits a 3.

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 front-loaded with the core action, return behavior, and the one parameter hint. There is no filler or repetition, and the most important information comes first.

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 correctly avoids that. For a single optional parameter tool with readOnlyHint, the description covers the essential call semantics, though it could be more complete about prerequisites or how the snapshot relates to streaming alternatives.

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 input schema does not document the tail parameter beyond its type and default. The description compensates by explaining that tail limits the number of lines returned, which adds needed meaning. However, it does not clarify units or what happens when tail is omitted, so it only partially fills the gap.

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

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

The description states a specific verb and resource: 'Get SkyPilot API server logs'. It is clearly distinguishable from siblings like skypilot_serve_logs or skypilot_job_logs because it names the API server specifically. It is slightly more than a bare restatement but stops short of differentiating it from the other log-related 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?

There is no guidance on when to use this tool versus alternatives such as skypilot_serve_logs or skypilot_download_logs. The only usage hint is about the tail parameter, which is parameter semantics, not tool selection. An agent must infer the appropriate context without help.

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 cover openWorldHint and destructiveHint=false. The description adds real behavioral context: deploy mode 'fully utilizes resources', metrics and basic auth are optional add-ons, and foreground mode would permanently block the server so it is unsupported. That is meaningful disclosure beyond the annotations.

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

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

Three tight sentences with zero filler; the primary action is front-loaded and the limitation note is appropriately placed last.

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 key operational semantics for a start tool. It is slightly incomplete given the undocumented host and metrics_port parameters, but otherwise sufficient.

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 deploy, metrics, and basic auth (with 'fully utilizes resources' for deploy), but leaves host and metrics_port completely undocumented, so it only partially compensates for the coverage 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 ('Start the SkyPilot API server'), which cleanly distinguishes it from sibling lifecycle tools like skypilot_api_stop and skypilot_api_status. It is clear, though it does not explicitly name the sibling alternatives.

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

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

It gives the condition for deploy=True and mentions optional metrics/auth, and it flags that foreground mode is not available via MCP. However, it offers no explicit when-to-use-this-vs-skypilot_api_stop/status guidance or prerequisites, so usage is only implied.

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?

readOnlyHint=true is consistent with a listing operation. The description adds a real behavioral trait beyond annotations: by default only pending and running requests are returned, and finished ones require all_status=True. That default-scope disclosure is valuable; return format and pagination behavior are left unstated but the output schema covers returns.

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

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

Three tight sentences, front-loaded with the core operation and followed by filter guidance. No wasted words; the filter list is slightly terse but not padded.

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 operation plus most filter semantics. The only shortfalls are the undocumented 'fields' parameter and the absence of routing guidance against skypilot_get_request, both minor for a read-only 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?

Schema coverage is 0%, so the description carries the load. It explains request_ids, cluster_name, all_status (with its semantic effect), and limit (caps results), but 'fields' is merely named with no indication of what fields are valid or what selecting them does. That is a meaningful gap for one of five params.

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

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

States a specific verb (List) and resource (API requests) with a clear default scope (pending and running). It does not, however, distinguish itself from the sibling skypilot_get_request, which an agent could reasonably confuse this 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?

Gives usage context for the filters (optional filtering, all_status to widen scope, limit to cap), which is implied guidance but not explicit when-to-use. It never states when to prefer this listing tool over skypilot_get_request for a single request, nor when-not to use it.

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

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

Annotations already declare destructiveHint=true, so the safety profile is covered structurally. The description adds non-trivial behavioral context beyond that: the locality restriction and the concrete error behavior for remote servers, which tells the agent this call can fail deterministically on the wrong target.

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, action stated first, then the two constraints. Every sentence carries distinct information with no repetition of the title 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 values need not be explained, and the destructive nature is carried by annotations. For a zero-parameter, locally-scoped stop operation, the action plus the locality/error constraint is everything an agent needs to invoke it correctly.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to document. No parameter-related text is needed and none is misleading.

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 precise verb+resource ("Stop the SkyPilot API server") that an agent can immediately separate from skypilot_cluster_stop, skypilot_api_cancel, skypilot_api_status, and skypilot_api_logout. The scope qualifier ("API server") targets exactly one subsystem, so no schema inspection is needed to route correctly.

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 precondition and an explicit failure condition: it only works on locally hosted servers and raises an error for remote ones. It does not name an alternative to use for remote servers (e.g. whether any sibling handles that case), which is the only missing piece.

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 readOnlyHint annotation already signals a non-mutating operation, and the description adds the useful default-scope behavior and what infra types are covered. The word 'enable' creates mild tension with readOnlyHint, though the core stated function (verify/check) is consistent with it, so it is not a hard contradiction. It discloses no permission or rate-limit context.

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

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

Three sentences that are front-loaded with the primary action ('Check and enable infrastructure credentials') followed by scope defaults and optional scoping. Efficient, with no filler, though the leading phrase slightly duplicates the verification clause.

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 unnecessary. The description covers the key behaviors (default = all infra, optional workspace scoping) for a simple 3-parameter tool; the only gap is that the 'verbose' parameter goes 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. It explains 'infra' (clouds, Kubernetes, SSH, Slurm) and its null default (checks all), and the 'workspace' scoping parameter, but leaves 'verbose' entirely unexplained, so compensation is only partial.

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: it 'checks and enable[s] infrastructure credentials' and 'verifies that credentials are configured correctly' for clouds, Kubernetes, SSH, and Slurm. This is clear and concrete, but it does not distinguish itself from related siblings such as skypilot_enabled_clouds or skypilot_validate, so an agent must infer the boundary.

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 useful default behavior ('If no infra specified, checks all supported infrastructure') and workspace scoping, which is implied usage guidance. However, it never states when to prefer this tool over alternatives like skypilot_enabled_clouds or skypilot_validate, and there are no exclusions.

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 provide idempotentHint, so the description carries most of the behavioral burden and does well: it discloses idle-based stopping, that down=True tears the cluster down, that -1 disables the timer, and that a hook runs before autostop. It stops short of stating required permissions or the fate of running jobs.

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, followed by tightly packed sentences that each add a distinct behavioral or parameter fact. No filler and no redundancy.

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

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

An output schema exists (request_id is mentioned but need not be described), and the description covers the destructive-mode flag, timer semantics, idle detection, and hooks. The only gap is the undocumented hook_timeout parameter for this 6-parameter mutation 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 must compensate, and it explains down, idle_minutes (-1 to disable), wait_for (with enumerated values and default), and hook. However, hook_timeout is left undocumented in both schema and description, leaving one meaningful parameter unexplained.

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 ("Set an autostop timer for a cluster") and immediately clarifies the resulting lifecycle behavior. This is clearly distinct from siblings like cluster_stop, cluster_down, or tail_autostop_logs, so an agent can identify it 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 description explains what happens when the tool is invoked but never states when to prefer it over cluster_stop or cluster_down, nor any prerequisites. Usage is only implied by the semantics of the parameters rather than an explicit when/when-not routing.

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 destructiveHint annotation already declares this is a destructive operation, but the description adds real value beyond it: it specifies that all associated resources are deleted and that data on attached disks is irreversibly lost, and it notes the request_id return. It stops short of stating approval/authorization requirements or whether the teardown is async.

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, zero filler, and the destructive consequence is stated immediately after the action. Everything is front-loaded and each sentence 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 existence of an output schema excuses it from explaining return values beyond the request_id mention. But the undocumented 'purge' parameter and the absence of any when-to-use/routing guidance leave real gaps for a destructive 2-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?

Schema description coverage is 0%, so the description carries the full burden, and it does not mention the 'purge' parameter at all even though that boolean plausibly controls whether resources are force-deleted. Only cluster_name is implicitly covered by the phrase 'a cluster'.

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 ('tear down a cluster completely'), and the adverb 'completely' hints at the distinction from the sibling skypilot_cluster_stop. However, it never names the softer alternative, so an agent must infer the difference from the word 'completely' 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?

No when-to-use guidance is given. With siblings like skypilot_cluster_stop and skypilot_cluster_autostop available, the description never explains when an agent should tear down versus merely stop, nor any preconditions such as the cluster being stopped first.

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?

readOnlyHint=true already declares the safety profile, so the bar is lower. The description adds that results are a mapping of port numbers to endpoint URLs, which is useful behavioral context, but says nothing about auth needs, cluster-state requirements, or empty/failure cases.

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

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

Three compact sentences, front-loaded with the core purpose, then the optional filter, then the return shape. No wasted words.

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

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

For a simple two-parameter read tool with an output schema present, the description covers purpose, filter, and return shape adequately. Minor gaps remain around cluster-state prerequisites, but nothing essential for invocation 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%, so the description carries the burden. It clarifies that 'port' may be given as a number or a name—matching the schema's integer/string anyOf—and that it is optional, adding real meaning beyond the bare schema. cluster_name semantics are 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+resource ('Get the endpoint(s) for a cluster') with a clear scope, and the resource is distinct from siblings like cluster_status or cluster_exec. It doesn't explicitly differentiate from alternatives, but the purpose is unambiguous.

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

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

The description mentions the optional port filter but gives no when-to-use context, no prerequisites (e.g., cluster must be up), and no alternatives. The only 'guidance' is parameter behavior, not selection criteria.

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 real behavioral context beyond annotations: it syncs the workdir, runs commands, and returns a request_id that must be polled via a named sibling. Annotations only say openWorld/destructive=false, so this async/polling contract is genuinely new info. Missing: what happens to existing cluster state or whether commands run detached.

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 does, what it does behaviorally (sync + run), and the return/poll contract. Front-loaded with the core action, no filler.

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

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

With an output schema present, the description need not explain return values, and its request_id/polling tip is a helpful extra. The two unexplained boolean params (down, dryrun) are the main gap given 0% schema coverage.

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% – four parameters are completely undocumented in the schema, so the description must compensate. It explains task_yaml (a SkyPilot task YAML string) but says nothing about cluster_name, down, or dryrun. Partial compensation only, hence baseline-ish 3.

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 (execute a task) and resource (an existing cluster), and distinguishes from launch/start siblings by 'existing cluster'. An agent can pick this out from skypilot_cluster_launch or skypilot_cluster_start without opening a schema.

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

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

Makes clear it operates on an *existing* cluster, implying you must have launched/started one first, and points to skypilot_get_request for polling. However it never states when NOT to use it (e.g. use cluster_launch for new clusters) nor mentions prerequisites explicitly.

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

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

Annotations are sparse (openWorldHint=true, destructiveHint=false), providing minimal behavioral context. The description adds valuable detail: it explains that fast=True skips cloud availability checks, describes wait_for autostop idling semantics, mentions optimize_target, and states that the tool returns a request_id with instructions to poll. This is significant behavioral disclosure beyond the annotations. However, it doesn't cover potential side effects, error handling, or what happens on failure.

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 compact and front-loaded: it states the core action first, then in a series of sentences details key parameters and return behavior. It avoids unnecessary fluff. No major structural issues, though it could be organized with bullet-like separation for clarity.

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 (11 parameters, open-world operation), the description is moderately complete. It covers the main action, some important parameters, and the return mechanism, but it omits guidance on many parameters, prerequisites, and potential side effects. The presence of an output schema reduces the need to describe return values, but the description still leaves gaps for an agent to call the tool correctly in all scenarios.

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. It explains the semantics of optimize_target, fast, and wait_for, and mentions task_yaml. However, it does not explain other parameters like down, dryrun, no_setup, cluster_name, retry_until_up, clone_disk_from, or idle_minutes_to_autostop. With 11 parameters and only 3-4 covered, the description adds some value but leaves many 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 clear dual purpose: 'Launch a new cluster or submit a task to an existing cluster,' which is a specific verb+resource. However, the tool name itself is 'cluster_launch' and the description adds the task-submission facet, but it doesn't explicitly differentiate from similar siblings like skypilot_managed_job_launch or skypilot_pool_apply. Distinguishing from those would require more context.

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

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

No explicit when-to-use or when-not-to-use guidance is provided beyond the basic purpose. The description mentions some parameter effects (optimize_target, fast, wait_for) but doesn't say when to choose this tool over alternatives like skypilot_managed_job_launch or skypilot_pool_apply, nor does it state prerequisites such as authentication or cloud credentials.

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=false and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context ('Reattaches preserved disks'), but says nothing about what force, down, or retry_until_up do to the restart 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?

Three tight sentences with the core action front-loaded and no filler. Efficient, though the middle 'reattaches disks' detail could be folded in more economically.

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 return value needn't be explained. But for a 6-parameter mutation with 0% schema coverage, omitting force, down, retry_until_up, and idle_minutes_to_autostop leaves the agent unable to invoke it correctly for non-default cases.

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 the burden, yet it documents only wait_for (including its 'jobs_and_ssh'/'jobs'/'none' values). Five of six parameters — down, force, retry_until_up, idle_minutes_to_autostop, cluster_name — are given no meaning beyond their names.

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 previously stopped cluster'), and the qualifier 'previously stopped' implicitly distinguishes it from skypilot_cluster_launch (new cluster) and skypilot_cluster_stop. It never names a sibling explicitly, so it falls short of a 5.

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

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

'Previously stopped cluster' implies the precondition for use, and the wait_for sentence gives conditional guidance for one parameter. However, there is no explicit when-not or named alternative among the many cluster siblings (launch, stop, down, autostop).

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

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

Annotations only declare readOnlyHint=true, so the safety profile is covered. The description goes beyond that by spelling out the three refresh modes and their semantics (NONE = no refresh, AUTO = only autostop/spot clusters, FORCE = all), which tells the agent when the call may reach out to providers. It stops short of noting cost/latency of FORCE or any permission implications of all_users.

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, no filler, and the core purpose is front-loaded ahead of the optional details. The field enumeration in sentence two is mildly redundant given an output schema exists, but it costs little.

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 correctly focuses on scoping and refresh behavior. The main gap is that all_users is never explained, which matters in a multi-user cluster system, but otherwise the agent has enough to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does well for refresh (all three values defined, default stated, enum absent from the schema) and cluster_names (empty means all), but the all_users parameter is never mentioned in either the schema or the description, leaving one of three parameters semantically opaque.

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 gives a specific verb and resource ("Get the status of SkyPilot clusters") and enumerates the returned fields, which clearly separates it from mutation siblings like skypilot_cluster_stop/start/down. It does not, however, explicitly distinguish itself from adjacent read tools such as skypilot_status_kubernetes, skypilot_pool_status, or skypilot_cluster_endpoints.

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 default-scope rule ("If no cluster_names provided, returns all clusters") gives implicit usage guidance for the no-argument case. There is no explicit when-to-use guidance, no prerequisites, and no direction toward alternatives when a different flavor of cluster/pool/kubernetes status is what the agent actually wants.

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

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

The description adds substantial behavioral context beyond the destructiveHint annotation: it explains billing implications ('billing for instances stops but disk charges continue'), data preservation on attached disks, what graceful=True does, and that a request_id is returned. It does not, however, explain the purge parameter's effect, which is a notable omission for a destructive-adjacent operation.

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

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

The description is four sentences, front-loaded with the core action, then side effects, a key parameter tip, and the return value. Every sentence adds value and there is no redundancy.

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

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

An output schema exists and annotations cover the destructive hint, so the description need not explain return values. However, it is incomplete for a 4-parameter stop tool because it omits purge and graceful_timeout semantics, and its blanket claim that 'data on attached disks is preserved' may be misleading if purge is set.

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 parameter semantics. It explains only graceful; it does not mention purge (which is likely destructive) or graceful_timeout, leaving three of four parameters undocumented. This is a significant gap given the low schema coverage.

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

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

The description states a clear verb and resource: 'Stop a running cluster.' It is unambiguous and specific. However, it does not explicitly differentiate from siblings like skypilot_cluster_down or skypilot_cluster_autostop, which would help an agent choose correctly.

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

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

Usage is implied by 'Stop a running cluster,' and the graceful tip provides some context for when to use that parameter. But there is no explicit guidance on when to prefer this over cluster_down, autostop, or api_stop, and no exclusions or prerequisites are stated.

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

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

With readOnlyHint=true, the safety profile is already covered. The description adds that terminated clusters are included and that costs are estimated based on resource types and duration, which is useful behavioral context beyond the annotation, but it doesn't discuss output format, accuracy limitations, or any rate limits.

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 concise sentences, front-loaded with the primary purpose, then scope details, then the optional filter. No wasted words.

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

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

The tool is simple (one optional parameter), and the description covers what the report includes and the filter option. Since an output schema exists, return values needn't be explained. It could mention cost units or estimation caveats, but is nearly complete for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that the optional 'days' filter restricts the report to a number of days, adding meaning beyond the schema's bare integer type. No default or format details are given, but the core semantics are clarified.

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 ('Get cost reports for all clusters'), and notably mentions including terminated clusters, which distinguishes it from cluster_status-type tools. It is clear without needing sibling names, though it shares 'list-like' semantics with other status tools.

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

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

The description implies usage for cost estimation and mentions the optional days filter, but provides no explicit guidance on when to choose this tool over alternatives like cluster_status or api_info, nor any exclusions. Usage is implied but not stated.

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

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

Annotations only declare readOnlyHint=true, so the description must carry most of the behavioral burden. It usefully discloses the observable side effect that a browser window is launched and that a page can be preset, but says nothing about prerequisites (server running, authentication) or whether the call blocks awaiting the UI. Partial but real added context.

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

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

Two short sentences with the primary action front-loaded and the optional parameter mentioned second. No waste, though it is minimal rather than maximally informative.

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 safety profile is covered by readOnlyHint. However, the description omits any prerequisite or authentication context for a tool that depends on a live SkyPilot environment, leaving a gap for an otherwise simple definition.

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% for the single optional starting_page parameter, so the description must compensate. It does state the parameter is optional and controls the landing page, which is meaningful, but gives no accepted values or format examples (e.g., 'jobs', 'clusters'), leaving ambiguity.

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 ('Open'), resource ('SkyPilot dashboard'), and medium ('default web browser'), so an agent immediately understands the action. It does not explicitly distinguish itself from the sibling skypilot_jobs_dashboard, which is a plausible source of confusion, so it falls short of a 5.

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

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

There is no statement of when to use this tool versus alternatives, no mention of the closely related skypilot_jobs_dashboard sibling, and no prerequisites such as a running API server or prior login. Usage is only implied by the verb.

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?

readOnlyHint=true is already supplied by annotations, so the safety profile is covered. The description does add that files land in a local directory and that a job-ID-to-path mapping is returned, but it omits key behavior: what happens when job_ids is null, and whether existing local files are overwritten. Consistent with annotations, no contradiction.

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

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

Two tight sentences, front-loaded with the action and followed by the return shape. No wasted clauses, though it is on the terse side for a tool with unstated parameter behavior.

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

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

An output schema exists, so the return-value sentence is somewhat redundant, and the description omits the two things an agent actually needs: how to pick among the sibling download_logs tools and what a null job_ids means. Adequate but with clear gaps for a tool in a crowded family.

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% for both parameters, so the description must carry the load. It implicitly references job IDs via the return mapping but never explains that job_ids selects which logs to fetch or that a null default means all jobs; cluster_name is not explained either (though self-evident).

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

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

States a specific verb+resource ('download job logs from a cluster') and even names the destination ('to a local directory'), which is more than a tautology. However, it does not differentiate itself from the four sibling download tools (managed_job_download_logs, serve_download_logs, pool_download_logs), so an agent cannot tell which of them applies to a plain cluster job without opening each 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?

No when-to-use guidance is given, and critically no distinction from skypilot_managed_job_download_logs / serve_download_logs / pool_download_logs, which share nearly the same name pattern. The agent is left to infer that 'cluster' jobs are the scope.

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 establish readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: it states the return is a list of cloud names, and that expand=True changes the granularity by expanding Kubernetes and SSH into individual resource pools. It doesn't cover edge cases such as what happens when no clouds are enabled.

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 tightly packed sentences with the core purpose front-loaded, followed by the return value and then the two parameter behaviors. No filler or repetition; every sentence adds 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 small read-only listing tool with an output schema present, the description covers purpose, return type, both parameters, and the expansion behavior. There is no meaningful gap an agent would need to fill before invoking 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 the param burden, and it does explain both parameters: expand=True expands Kubernetes/SSH into resource pools, and workspace scopes the listing to a workspace. It compensates well for the schema gap, though it could be more precise about the expanded output shape.

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 gives a specific verb and resource with a qualifier that narrows scope meaningfully: 'List all clouds that have been enabled (credentials configured)'. This distinguishes it from sibling tools like skypilot_workspaces or skypilot_kubernetes_node_info, though it never names an alternative explicitly.

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

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

Usage is implied rather than stated: you call it to discover which clouds are usable, and set expand=True when you want Kubernetes/SSH broken out into resource pools. There is no explicit when-to-use vs. when-not guidance and no named alternative, leaving the agent to infer the 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?

Annotations declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the crucial behavioral trait that the call 'blocks until the request finishes' — a significant latency/waiting characteristic not conveyed by the annotations. No mention of timeout behavior, which would round this out.

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 core purpose and followed by usage and the blocking trait. 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 described. The description covers purpose, trigger, and blocking behavior. It omits timeout/failure behavior for a blocking call, but is otherwise complete for a single-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?

The single request_id parameter has 0% schema description coverage, so the description carries the burden. It does explain where request_id comes from (tools that return a request_id), which adds useful meaning, but doesn't specify the format or any constraints.

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

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

States a specific verb+resource: waiting for a SkyPilot request and returning its result. It distinguishes itself from sibling status/log tools by making clear it is the blocking operation tied to a request_id, though it doesn't explicitly contrast itself with skypilot_api_status or skypilot_stream_and_get.

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 to use it 'after calling tools that return a request_id' and names example producers (skypilot_cluster_launch, skypilot_cluster_stop). It gives clear triggering context but no when-not guidance, e.g., when a non-blocking status check or stream would be preferable.

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 annotations already declare destructiveHint=true, so the agent knows the operation is destructive. The description adds the mutual-exclusivity constraint between job_ids and cancel_all and mentions the return of a request_id, but does not describe other behavioral traits like irreversibility details, confirmation requirements, or side effects beyond the annotation.

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

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

The description is three sentences: it front-loads the core action, then gives parameter usage, then notes the return. It is efficiently sized with no wasted text, though the final return-value sentence is slightly redundant given the presence of an output schema.

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 four parameters, a destructive annotation, and an output schema, the description covers the key invocation rules and mutual exclusivity. It is nearly complete, though it could briefly clarify cluster_name's role or explicitly differentiate this tool from sibling cancel operations.

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. It explains the meaning of job_ids, cancel_all, and all_users, and explicitly notes the mutual exclusivity between job_ids and cancel_all. Only cluster_name is left without added semantic detail, but its required and self-descriptive name limits the gap.

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

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

The description states a specific verb and resource: cancel jobs on a cluster. It clearly communicates the action, but does not differentiate this tool from sibling cancel tools like skypilot_managed_job_cancel or skypilot_api_cancel, leaving the agent to infer which cancel variant is appropriate.

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 explains how to invoke the tool with job_ids, cancel_all, and all_users, including that job_ids and cancel_all are mutually exclusive. However, it gives no guidance on when to choose this tool over alternatives such as skypilot_managed_job_cancel, so tool-selection context is only implied.

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

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

With readOnlyHint=true, the safety profile is already known, but the description adds important behavior: it returns a snapshot, not a stream; it shows the last N lines with default 100 and 0 meaning all; and it defaults to the latest job when job_id is omitted. These details go beyond the annotation and help the agent invoke it correctly.

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 core action, followed by behavioral clarifications. No wasted words; every sentence adds useful information about the returned data or parameter behavior.

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

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

Given the tool's simplicity, the presence of an output schema, and the readOnlyHint annotation, the description is nearly complete. It covers snapshot behavior, tail semantics, and job_id fallback. The only minor gap is that it does not mention cluster_name explicitly or prerequisites like the cluster being running, but these are largely inferable.

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 tail's default and the special value 0 for all lines, and it explains job_id's fallback behavior when omitted. cluster_name is required but self-evident from context, so the description compensates well for the lack of schema descriptions.

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: 'Get a snapshot of logs from a job running on a cluster.' It is clear, though it does not explicitly distinguish this tool from similar siblings like skypilot_managed_job_logs or the various download_logs tools. The scope 'job running on a cluster' is helpful but not a full sibling differentiation.

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

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

The description provides behavioral context ('snapshot', 'Does not stream/follow logs') and a default for missing job_id, which implies when to use it, but it does not explicitly say when to choose this tool over alternatives such as skypilot_managed_job_logs or skypilot_download_logs. No exclusions or direct alternatives are 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?

The readOnlyHint annotation already establishes this as a safe read operation. The description adds what is returned (job IDs, names, statuses, submission times, resource usage), which is useful, but the output schema likely covers the same ground and no auth, rate-limit, or pagination behavior is 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?

Two tightly written sentences, front-loaded with the core purpose and followed by the return fields. Every sentence 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 definition covers purpose and return fields, and annotations handle safety. However, it omits usage guidance and leaves two of three parameters undocumented, which is a meaningful gap 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 compensate, but it does not. 'Cluster's job queue' loosely implies the required cluster_name, yet the optional all_users and skip_finished parameters are left completely unexplained.

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: 'List jobs on a cluster's job queue.' This distinguishes it from a managed job queue and from single-job status tools, but it does not explicitly name or contrast with siblings like skypilot_managed_job_queue or skypilot_job_status.

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 no when-to-use guidance, no prerequisites, and no alternatives. Usage is only implied by the purpose, and with many sibling tools available, an agent gets no help selecting this one over alternatives.

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, so the safety profile is covered. The description adds that it opens the default web browser and provides a dedicated monitoring view, which is useful behavioral context beyond the annotation. However, with an output schema present and no mutation concerns, the remaining behavioral disclosure is limited.

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

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

Two concise sentences, front-loaded with the primary action and then a clarifying note about the view. There is no redundant or wasteful language.

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

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

Given no parameters, an output schema, and readOnly annotation, the description is largely complete. It could mention whether authentication or a running dashboard server is required, but for a simple browser-opening tool, it provides adequate context.

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

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

The tool accepts zero parameters, so there is no parameter semantics to document. Per the guidelines, zero parameters gives a baseline of 4. The description appropriately focuses on the action rather than 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?

The description states a specific action and resource: opening the managed jobs dashboard in the default browser. It clearly distinguishes from siblings like skypilot_dashboard (general dashboard) and skypilot_managed_job_queue (querying queue data) by specifying 'managed jobs dashboard'. It lacks mention of sibling alternatives, but the resource is unambiguous.

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

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

Usage is implied: use this to visually monitor managed jobs. There is no explicit when-to-use guidance or reference to alternatives such as skypilot_dashboard or skypilot_managed_job_queue. An agent can infer the context but must guess at boundaries.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds the meaningful default-behavior disclosure (omitted job_ids returns the latest job). It does not mention behavior when the cluster doesn't exist, job not found, or authentication requirements.

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

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

Two short sentences, zero filler, with the primary action front-loaded and the default-behavior caveat following. Every sentence 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?

An output schema exists, so return values need not be described. The description covers the optional-parameter fallback, giving most of what an agent needs; only error/precondition behavior for the required cluster_name 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 must carry parameter meaning. It explains the optional job_ids behavior well (defaults to latest job) but says nothing about the required cluster_name or what forms a job_id takes. Partial compensation, not full.

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

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

States a specific verb and resource ('Get the status of specific jobs on a cluster'), which distinguishes it from skypilot_cluster_status (cluster-level). However, it does not differentiate from the closely-named sibling skypilot_job_queue, leaving the agent to infer the boundary.

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 fallback rule ('if no job_ids provided, returns the status of the latest job') gives useful invocation context, but there is no guidance on when to prefer this over skypilot_job_queue or skypilot_job_logs, and no stated prerequisites.

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

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

Annotations only declare destructiveHint=false, so the description carries most of the burden. It correctly discloses the NVIDIA-only limitation and that cleanup_only removes resources, plus that a request_id is returned. It does not say whether the labeling mutates cluster state persistently, whether it requires elevated permissions, or what the request_id is used for beyond this 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, front-loaded with the core action and then the constraints. No filler. Slightly terse given the parameter gap, but structurally efficient.

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 optional and the request_id mention suffices. Still, for a mutating cluster operation with two entirely undocumented parameters and no stated prerequisites or scope of effect, the description is only minimally adequate.

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

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

Schema description coverage is 0%, so the description must compensate for three undocumented parameters. It only explains cleanup_only. context and wait_for_completion are left completely unexplained in both schema and description, leaving the agent to guess their meaning and defaults.

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 (Label) and resource (GPU nodes in a Kubernetes cluster), and names the integration context (SkyPilot). Could be sharper about which nodes get labeled, but it is clearly distinguishable from siblings like skypilot_kubernetes_node_info (read-only inspection) or skypilot_status_kubernetes.

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 mention of cleanup_only=True removes labeling resources provides an implied when-to-use path, and the NVIDIA-only scope narrows applicability. However, it never states prerequisites (e.g., kubectl access, target cluster selection) or when to prefer alternatives such as skypilot_kubernetes_node_info.

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 declare readOnlyHint=true, so the safety profile is already known. The description adds what data is returned (CPU, memory, GPU), which is useful, but does not cover authentication, rate limits, or pagination. With annotations covering the read-only nature, a 3 is appropriate.

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

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

Two sentences, front-loaded and with no extraneous information. Every part 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?

Given that an output schema exists, the description need not explain return values. It covers purpose and scope adequately, though it lacks usage guidance and parameter explanation. For a simple read-only tool, it is mostly 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 description coverage is 0% for the single 'context' parameter. The description does not explain the 'context' parameter at all, so it fails to compensate for the low schema coverage. However, with only one optional parameter and an output schema present, baseline 3 is reasonable.

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+resource: 'Get resource information for all nodes in a Kubernetes cluster', and lists what is shown (CPU, memory, GPU). It clearly distinguishes from the sibling skypilot_slurm_node_info by specifying Kubernetes, though it does not name that sibling in the description.

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

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

There is no explicit guidance on when to use this tool versus alternatives like skypilot_slurm_node_info or skypilot_status_kubernetes. Usage is only implied by the scope (Kubernetes nodes).

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?

readOnlyHint=true already establishes this is a safe read, so the bar is lower. The description adds that it 'Returns a mapping of accelerator names to available quantities', but since an output schema exists this return-shape note is largely redundant, and it says nothing about filtering defaults or scope behavior.

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

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

Three short sentences, front-loaded with the core action followed by return and filter detail. No filler, though the return sentence partly duplicates output-schema 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?

Output-schema presence relieves it of explaining return values, but for a 5-parameter tool with 0% schema description coverage, the description leaves gpus_only and all defaults unaddressed, and provides no help distinguishing it from skypilot_list_accelerators.

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 5 parameters, so the description must carry more. It names four filter dimensions (name, region, quantity, clouds) that map to name_filter, region_filter, quantity_filter, and clouds, but leaves gpus_only undocumented and adds no format, syntax, or default semantics.

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 available accelerators and their available counts') and clarifies scope by noting it returns a mapping of names to quantities. It is clear about what it does, but does not explicitly distinguish itself from the nearby sibling skypilot_list_accelerators.

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 offers no when-to-use guidance, prerequisites, or contrast with the very similar skypilot_list_accelerators sibling. The only usage hint is the list of filter dimensions, which is implied rather than framed as a selection rule.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the non-obvious default that non-GPU accelerators are excluded unless gpus_only is disabled, but this is largely a restatement of the schema default; undocumented behaviors such as require_price defaulting to true (filtering out unpriced accelerators) 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?

Four short sentences, front-loaded with the core purpose before the option guidance. The repeated 'Set X=Y to...' phrasing is slightly mechanical but each sentence carries information; minimal waste.

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 read-only safety is covered by annotations. The gaps are the undocumented all_regions and require_price parameters and the lack of disambiguation from the accelerator-counts/realtime-availability siblings.

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 8 parameters, so the description must compensate. It names the name, region, quantity and cloud filter dimensions plus the gpus_only and case_sensitive defaults, but leaves all_regions and the consequential require_price untouched, so roughly a quarter of parameters remain unexplained.

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 available accelerators (GPUs/TPUs) across clouds') with scope made explicit. It does not, however, distinguish itself from the closely named sibling skypilot_list_accelerator_counts or skypilot_realtime_gpu_availability, so an agent must infer the boundary.

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

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

Usage is implied through parameter guidance ('Set gpus_only=False to include...', 'Set case_sensitive=False...'), which tells the agent when to flip options. There is no explicit routing to alternatives (e.g. the accelerator-counts tool or realtime availability tool), so the when-not guidance is absent.

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 give destructiveHint=true; the description goes beyond that by scoping exactly what is destroyed (the local cluster created by local_up) and by disclosing the local-API-server prerequisite, which is a real operational constraint. It does not describe reversibility or failure behavior, but it adds meaningful context over the annotation.

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 action and scope, and the precondition follows immediately. The final 'Returns a request_id' sentence is largely redundant given a declared output schema, so it is tight but not perfectly waste-free.

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

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

For a simple teardown tool with an output schema and a destructiveHint annotation, the description covers action, scope, and precondition adequately. The notable gap is the undocumented 'name' parameter, leaving the agent unsure whether any selector should be passed.

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

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

The single parameter 'name' has 0% schema coverage and is never mentioned in the description, which instead refers to 'the local Kubernetes cluster' in the definite, implying no selector is needed. With low coverage the description should compensate for the unexplained parameter but does not.

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 (tear down) and resource (the local Kubernetes cluster started by local_up), and pins its identity to the counterpart skypilot_local_up, which distinguishes it from the many other *_down siblings (cluster_down, ssh_down, pool_down, serve_down).

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?

Adds a clear precondition — 'Only works when the API server is running locally' — and implies the inverse pairing with local_up as the correct context. It stops short of explicitly naming when to prefer cluster_down or other teardown tools, so it is clear context without full alternative routing.

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 give openWorldHint=true and destructiveHint=false, so the safety profile is partly covered, and the description adds two non-obvious behaviors: a hard precondition (API server must be local) and an asynchronous return ('Returns a request_id'). It stops short of disclosing persistence/lifecycle (does the cluster survive, how is it torn down) or any auth requirements.

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 action, then the key flag, then the precondition and return value. No filler and no redundancy with the schema.

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

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

For a zero-required-parameter setup tool with an output schema, the essentials are mostly present, but the request_id is mentioned without saying it should be polled via the sibling skypilot_get_request, and no lifecycle/cleanup counterpart is referenced. The preconditions and flag semantics are 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 coverage is 0% for all three parameters, so the description must carry the meaning. It explains gpus=True as GPU passthrough (useful beyond the bare boolean default), but 'name' and 'port_start' are left entirely unexplained — no hint that name is a cluster identifier or what port range port_start begins.

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: 'Launch a local Kubernetes cluster for SkyPilot.' That is clearly distinct from the cloud-cluster siblings, but the description never names or contrasts with the obvious counterpart skypilot_local_down (teardown) or skypilot_cluster_launch, so sibling differentiation is only implicit.

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

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

'Only works when the API server is running locally' is a genuine precondition that constrains when the call can succeed. However, there is no guidance on when to choose this over skypilot_cluster_launch, skypilot_ssh_up, or other environment-setup siblings, and no note that skypilot_local_down is the matching cleanup call.

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

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

Annotations only declare destructiveHint=true; the description adds substantive behavior beyond that – the return value (request_id), that graceful waits for in-progress data uploads, and that all_users widens scope to every user. This is meaningful disclosure of side effects and scope for a destructive 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?

Four tight sentences, front-loaded with the action and then the selection constraint before the optional flags. No filler, and the return value is appended efficiently.

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 and the description still names the return value, and it covers the mutually-exclusive selection modes plus the two behavioral flags. Only graceful_timeout is left unexplained, a small gap for a mostly complete destructive-operation definition.

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 the load and largely does: it explains name, job_ids, pool, cancel_all (with mutual exclusivity), all_users, and graceful with semantics. It omits any explanation of graceful_timeout, leaving one of seven 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?

States a specific verb and resource ('Cancel managed jobs'), which separates it from the regular-job sibling skypilot_job_cancel by resource name. It does not, however, explicitly route agents away from other cancel-family siblings such as skypilot_api_cancel, 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?

Gives a concrete operating rule – provide exactly one of name, job_ids, cancel_all, or pool, and notes these are mutually exclusive – which is genuine invocation guidance. It lacks when-to-use-vs-alternative routing (e.g., when to prefer skypilot_job_cancel or skypilot_api_cancel), so it is clear context without exclusions.

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?

readOnlyHint=true already covers the safety profile, so the description is not required to restate it. It does add useful behavior: the controller=True switch redirects output to controller logs, and local_dir controls the save location. However, the refresh parameter's effect is never explained, leaving a behavioral gap.

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

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

Four short sentences, front-loaded with the core action and then the selection/option details. No filler, though it is slightly list-like rather than tightly structured.

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. For a 5-param read tool this is mostly adequate, but the unexplained refresh parameter and the lack of any name/job_id mutual-exclusion note leave an agent with missing decision context.

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

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

Schema description coverage is 0%, so the description carries the param burden. It meaningfully explains name, job_id, controller, and local_dir (4 of 5), but refresh is undocumented in both the schema and the description, and no guidance is given for resolving name vs. job_id conflicts.

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 (Download) and resource (logs from a managed job) with a clear destination (local directory). It is distinguishable from skypilot_managed_job_logs (view vs. download) only by inference, not by explicit contrast, so it falls short of a 5.

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

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

It says how to select a job (name or job_id) and when to use the controller flag, but gives no explicit guidance on when to prefer this tool over skypilot_managed_job_logs or skypilot_download_logs. Usage is implied rather than stated.

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

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

Annotations only declare openWorldHint=true and destructiveHint=false; the description adds genuine behavioral context beyond that — spot/hardware failure recovery and the request_id return. It omits whether launch is asynchronous/blocking, which matters for a launch operation whose result is an ID.

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

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

Four compact sentences, front-loaded with the core action before optional-parameter notes. Minor tautology in 'Set pool to target a specific worker pool', otherwise efficient with no filler.

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

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

Output schema exists so return value detail isn't required, annotations cover safety, and the description covers input shape, multi-doc groups, and the two key optional params. It doesn't connect request_id to the follow-up retrieval tools (skypilot_get_request, skypilot_stream_and_get) an agent would need next.

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 does for three of four parameters: task_yaml accepts a YAML string (single or multi-document for job groups with parallel execution), pool targets a worker pool, num_jobs launches multiple copies. Only 'name' is left unexplained, and no format examples are given.

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 ('Launch a managed job') plus a distinguishing behavioral trait (automatic recovery from spot preemptions/hardware failures). It separates this from skypilot_cluster_launch by virtue of 'managed job', but never names a sibling explicitly, so it stops short of a 5.

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

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

It explains what the optional parameters do (pool targets a worker pool, num_jobs launches copies) which implies usage, but gives no when-to-use vs the sibling launch/queue tools and no prerequisites or exclusions. Usage is inferable rather than stated.

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 readOnlyHint annotation already covers the safety profile, and the description adds substantial behavioral context: snapshot semantics, default 100 lines with 0 meaning all, no streaming/following, and the controller/task switches. This goes well beyond what the 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?

Front-loaded with the core purpose, then a series of compact, value-bearing sentences. No filler; each clause documents a distinct behavior or parameter.

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 needn't be described, and the description covers most parameters and the non-streaming behavior. The lone gap is the undocumented 'refresh' parameter, which is minor given the otherwise thorough coverage.

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 burden and largely succeeds: it explains tail (default 100, 0 for all), name-or-job_id selection, task (name or 0-based index), and controller. Only the 'refresh' parameter is left unexplained.

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

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

States a specific verb and resource ('Get a snapshot of logs from a managed job'), which an agent can distinguish from sibling tools like skypilot_job_logs and skypilot_managed_job_download_logs. It does not explicitly name those siblings, but the 'snapshot' framing and 'managed job' scoping are clear.

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

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

'Does not stream/follow' signals this is a snapshot rather than a streaming operation, implying usage versus tools like skypilot_stream_and_get. However, it never names an alternative or states when to prefer this over download_logs or the regular job_logs, so routing is only implied.

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?

readOnlyHint=true already establishes the safety profile, and the description adds genuine behavioral context beyond it: the refresh=True path hits the cluster and is explicitly 'slower but up-to-date.' It also enumerates what is returned (statuses, submission times, recovery info, counts), though it does not mention pagination limits or result caps.

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

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

Four compact sentences with the core purpose front-loaded and no filler. It is dense but each sentence carries information; it stops just short of ideal because the return-value sentence lists fields an existing output schema already covers.

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 an 8-parameter tool with 0% schema coverage, four parameters (job_ids, fields, all_users, skip_finished) are undocumented in both the schema and the description. The output schema means return values need not be explained, and the refresh guidance is the most important piece, but the filtering parameters remain opaque to an agent.

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 explanatory burden, and it only partially does so. refresh gets real semantics (cluster fetch, slower but current) and limit/sort_by/sort_order are named with their purpose (pagination, sorting), but job_ids, fields, all_users, and skip_finished are never mentioned 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 managed jobs and their statuses') and tags the API version ('v2 API'), which is the only thing separating it from the sibling skypilot_managed_job_queue_v1. It does not, however, explicitly tell the agent when v2 is preferred over v1 or over skypilot_job_queue, so the differentiation is suggestive rather than decisive.

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

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

There is no statement of when to use this tool versus the near-identical skypilot_managed_job_queue_v1 or skypilot_job_queue siblings. The only conditional guidance ('Set refresh=True...') is about a parameter's cost/latency tradeoff, not about tool selection, so an agent gets no routing help.

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

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

Annotations already cover readOnlyHint=true, so the safety profile is settled. The description adds value beyond that: the return is a flat list with no pagination or sorting, and refresh=True pulls the latest state from the cluster. It stops short of explaining what refresh=False does (cached/stale), which would be the last behavioral gap.

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

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

Four tight sentences, front-loaded with the core action and return shape before the usage condition and the refresh hint. No filler, though it is slightly longer than strictly necessary.

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 legitimately absent. However, with 0% schema coverage on a 4-parameter tool, three filter parameters go entirely undescribed, which is a meaningful completeness gap for a listing tool an agent must filter 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% across 4 parameters, so the description carries the full burden and covers only refresh. The filtering parameters job_ids, all_users and skip_finished are undocumented in both schema and description, leaving an agent to guess at their semantics.

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

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

States a specific verb+resource ('List managed jobs and their statuses') and pins the variant with '(v1 API)'. It distinguishes itself implicitly from the sibling skypilot_managed_job_queue via the v1/compatibility framing, though it never names that sibling explicitly, which keeps it just shy of a 5.

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

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

Explicit when-to-use: 'for compatibility with older API servers or when the simpler return format is preferred.' That gives a real selection condition. It lacks an explicit alternative ('use X otherwise'), so it falls short of a 5.

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

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

Annotations declare readOnlyHint=true, so the safety profile is covered. The description adds that it analyzes clouds/regions/instance types and returns an optimized DAG, which is useful context beyond the annotation. However, it doesn't disclose potential costs, time taken, or whether it requires cloud credentials beyond what the schema implies.

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 concise sentences, front-loaded with the core action and followed by method and parameters. It is efficient with no wasted words, though it could be slightly more structured with bullets for the minimize options.

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 that an output schema exists, the description needn't explain return values, but it does mention returning the optimized DAG. For a tool with two parameters, one undocumented (task_yaml), and no annotation beyond readOnly, the description is fairly complete but misses explaining the required task_yaml input.

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. It mentions the 'minimize' parameter with allowed values ('COST' default or 'TIME'), providing crucial meaning beyond the bare schema. However, it does not explain 'task_yaml' at all, leaving one of two 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?

States a specific verb (find/optimize) and resource (execution plan for a task), and clarifies that it analyzes clouds, regions, and instance types for optimal placement. It is clear what the tool does, though it doesn't explicitly differentiate itself from siblings like skypilot_validate or skypilot_check.

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

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

The description implies usage (to find the best execution plan) but offers no explicit when-to-use or when-not-to-use guidance relative to alternatives. Sibling tools like skypilot_validate exist, but the description doesn't explain when to optimize versus validate. Usage context is only implied.

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 declare openWorldHint=true and destructiveHint=false, so the safety profile is partially covered. The description adds useful behavioral context: the tool is an apply-style upsert, it accepts a SkyPilot YAML, it supports rolling vs blue_green update strategies, and it returns a request_id. It does not discuss permissions or side effects on existing workers, but it meaningfully extends 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?

Four front-loaded sentences with no filler. The definition of a worker pool is useful but slightly verbose for the space; overall efficient.

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 (returns a request_id) so return format is covered externally. However, with 0% schema description coverage and no annotations for auth, the description should ideally mention pool_name semantics, workers, and when an update would disrupt existing jobs. It is adequate but leaves notable gaps for a mutating, open-world 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 compensate. It explains that task_yaml is a SkyPilot YAML string defining resources and that mode selects 'rolling' (default) or 'blue_green'. It does not mention the workers parameter or pool_name, leaving two of four parameters unexplained, but it covers the two most semantically loaded 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?

The description states a specific verb+resource ('Create or update a worker pool') and defines what a pool is ('a long-lived set of compute resources that can host multiple managed jobs'), which cleanly distinguishes it from sibling tools like skypilot_cluster_launch or skypilot_managed_job_launch.

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

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

The description implies usage (create/update pools, choose update strategy) but never states when to prefer this over alternatives like skypilot_cluster_launch or skypilot_serve_up, nor prerequisites. It's implied but not explicit 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?

destructiveHint=true is already declared, so the safety profile is covered. The description adds meaningful context beyond annotations: the purge flag forces deletion despite errors, and it discloses a return value (request_id). The key behavioral trait of error-forcing is unique to the description.

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, each earning its place: verb+resource, selection guidance, purge behavior, return value. No waste and 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?

An output schema exists, so return format need not be explained, yet the description still notes the request_id. For a 3-param destructive tool with 0% schema coverage, the description covers the essential invocation semantics and the error-forcing behavior. Minor gap: it doesn't clarify whether pool_names and delete_all can be combined.

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 parameter meaning. It explains the mutual exclusivity of pool_names vs delete_all (though not stated as exclusive, it says 'or') and clarifies purge semantics ('force deletion even with errors'), which the schema default of false does not convey.

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?

Specific verb (Delete) and resource (worker pool(s)), with the scope constraint made explicit. Among siblings like skypilot_pool_apply and skypilot_cluster_down, the resource (worker pool) and operation (delete) are unambiguous.

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

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

The description implies usage through the parameter guidance ('Specify pool_names or set delete_all=True'), which tells the agent how to invoke but not when to prefer this over alternatives. No explicit when-to-use or prerequisites are stated.

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?

readOnlyHint=true already declares this as a safe read, so the burden is lower. The description adds that logs are written to a local directory and that filtering is optional, but does not mention overwrite behavior, whether the local dir is created, or how much is downloaded by default (tail is unexplained).

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

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

Two tight sentences, front-loaded with the action and destination. No filler, though the second sentence packs two filter parameters without explaining the tail parameter at all.

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. But with 5 parameters at 0% schema coverage and no annotations beyond readOnly, the description leaves tail, pool_name, and local_dir semantics unstated, which is a gap for a download 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 compensate; it supplies the allowed values for targets ('controller', 'load_balancer', 'replica') and mentions worker_ids filtering. However pool_name, local_dir, and especially tail (a numeric limit) remain undocumented in both description and 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?

Specific verb+resource: 'Download worker pool logs to a local directory' clearly states what the tool does and its destination. It implicitly separates itself from related siblings by scoping to 'worker pool' logs, though it does not explicitly name the sibling variants (pool_logs, serve_download_logs, etc.).

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

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

No when-to-use guidance, no exclusions, and no alternatives named among the many log/download siblings (skypilot_pool_logs, skypilot_download_logs, skypilot_serve_download_logs). The mention of optional filtering is parameter guidance, not usage routing.

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

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

With only readOnlyHint=true in annotations, the description carries meaningful extra burden and delivers: it discloses snapshot (non-streaming, non-following) semantics and the tail=0-means-all special case. It doesn't state permission requirements or size/cost limits, but the behavioral profile is solidly richer than the annotation alone.

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 verb and resource, then target, then worker_id, then tail behavior and the streaming caveat. No filler; every sentence adds information an agent needs.

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

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

For a 4-parameter read tool with an output schema (so return values need not be described), the description covers target, worker_id, tail, and streaming semantics well. It leaves open how worker_id interacts with target (e.g. whether a replica id is required for that target), which is the main remaining gap.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it enumerates the three valid target values (controller, load_balancer, replica), explains worker_id's optionality, and gives tail's default and the non-obvious 0=all convention. Only pool_name semantics go unexplained, which is self-evident.

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

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

States a specific verb and resource ('Get a snapshot of logs from a worker pool') and enumerates the valid targets. It is clear on its own, but it never names the nearest sibling (skypilot_pool_download_logs) or otherwise explicitly separates itself from the other log tools, so it stops short of a 5.

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

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

There is no explicit when/when-not guidance or sibling routing. The closest thing is the implicit distinction created by 'snapshot' and 'Does not stream/follow', which signals this is the pull-once variant rather than a streaming/tail tool, but the agent must infer that against pool_download_logs, serve_logs, and the tail_* tools.

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, so safety is covered. The description adds that status, counts, and resource information are returned, but this largely duplicates the output schema. The default all-pools behavior is a useful behavioral detail, though no auth/rate-limit context is provided.

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 purpose followed by return contents and parameter behavior. No superfluous language, though it could arguably combine the last two sentences for tighter structure.

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

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

For a simple read-only status tool with an existing output schema and one optional parameter, the description covers purpose, return contents, and default behavior adequately. The main gap is explicit when-to-use guidance versus sibling pool tools.

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 the only parameter's effect clearly: providing pool_names filters results, omitting them returns all pools. It does not specify the expected string format, but the parameter name and behavior are well covered.

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 the status') and resource ('worker pools'), and describes the returned data. An agent can easily distinguish this from siblings like pool_apply, pool_down, and pool_logs, which perform different actions.

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

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

Provides a default-behavior note ('If no pool_names provided, returns all pools') but no explicit guidance on when to use this tool versus alternatives such as pool_logs, pool_apply, or cluster_status. Usage is only implied by the tool name.

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 declare readOnlyHint=true, so the safety profile is covered. The description reveals it queries a live cluster and shows current quantities, but says nothing about refresh cadence, cost/latency of the Kubernetes query, or whether results are cached. For a 'real-time' tool, that's a notable gap.

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

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

Three sentences, all substantive, front-loaded with the core purpose. Efficient, though the is_ssh sentence is a bit dense with parenthetical booleans.

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 isn't required. The description covers the query scope and three of four parameters. Missing only the context parameter's meaning, which is minor given the tool's otherwise clear scope.

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 compensates partially by explaining is_ssh's boolean semantics fully. However, context, name_filter, and quantity_filter receive no description beyond their names – name_filter's matching rules (substring? exact?) and quantity_filter's semantics (minimum available count) are not clarified.

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 (real-time GPU availability) with context (in a Kubernetes cluster). Explicitly distinguishes from the Slurm sibling via the Kubernetes qualifier, so an agent can pick it correctly.

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?

Describes filtering capabilities ('Filter by GPU name or minimum quantity') and explains the is_ssh parameter's semantics, implying usage. But there's no explicit when-to-use guidance relative to alternatives like skypilot_list_accelerators or skypilot_list_accelerator_counts.

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, so the safety profile is covered. The description adds 'real-time' and the output content (GPUs and quantities), which are useful behavioral details, but it omits rate limits, auth, or data freshness guarantees.

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

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

Three short sentences, front-loaded with the core purpose. No wasted words; each sentence adds a distinct piece of 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?

The description covers purpose, output summary, and all filters. With an output schema present and annotations covering read-only safety, it is largely complete, though it could clarify how multiple filters combine or the format of the cluster name.

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

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

Schema coverage is 0%, so the description must compensate. It maps each of the three filters to its purpose (GPU name, minimum quantity, Slurm cluster name), adding meaningful semantics beyond the bare parameter names, though it does not specify matching syntax or defaults.

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 real-time GPU availability') and resource ('Slurm cluster'), and the scope 'Slurm' distinguishes it from the sibling realtime_gpu_availability tool. An agent can identify its purpose 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?

Provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives such as skypilot_realtime_gpu_availability or list_accelerators, nor prerequisites like authentication.

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 idempotentHint=true, so the safety profile is partly covered. The description adds the source location it re-reads from, but says nothing about failure modes, permissions, or behavior if the file is absent.

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

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

Two short sentences, action first, guidance second, with no filler or redundancy.

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

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

An output schema exists so return values need not be explained, and this is a simple zero-argument operation. The definition is essentially complete, though it omits any note on what happens if the config file is missing or malformed.

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 baseline is 4. There is nothing for the description to disambiguate, and it introduces no misleading parameter language.

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 ('Reload'), the exact resource ('SkyPilot client-side configuration'), and even the source path ('~/.sky/config.yaml'). No sibling tool in the list deals with config reloading, so the agent can distinguish it cleanly.

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 use trigger: 'Use after making manual changes to the config file.' That clearly tells the agent when to invoke it, though it offers no when-not conditions or named alternatives.

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, so the safety profile is covered. The description adds two useful behavioral facts not in the annotations: the purge behavior (force deletion despite errors) and that a request_id is returned. It does not disclose whether teardown is reversible or what errors trigger the purge path.

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 primary action, then the targeting options, then the escape hatch and return value. 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?

For a three-parameter destructive tool with an output schema (so return-value detail is omitted correctly) and destructiveHint coverage, the description supplies the decisions an agent must make: how to target services and when to force deletion. The main remaining gap is the absence of usage guidance relative to sibling teardown tools.

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: it explains that service_names and delete_all are alternative selection modes and that purge=True forces deletion despite errors. Defaults and types come from the schema. The description does not mention that all three parameters are optional or what the default behavior is with no arguments.

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

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

Clear verb+resource ('Tear down service(s)') that distinguishes it from siblings like skypilot_serve_status or skypilot_serve_logs. The phrasing 'tear down' is slightly informal versus the sibling skypilot_serve_up, but the intent is unambiguous.

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

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

The description states the two alternative targeting modes ('Specify service_names or set delete_all=True'), which tells the agent how to use the tool but not when. There is no explicit condition distinguishing when to use this versus skypilot_serve_terminate_replica.

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?

readOnlyHint=true is already declared, and the description usefully adds that the output lands in a caller-specified local directory (a local side effect not conveyed by the annotation). It does not disclose overwrite behavior, whether files are appended or replaced, or any auth/scope requirements for the target service, which matters for a 5-parameter tool.

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