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

Annotations already declare readOnlyHint=true, and the description adds value beyond that by disclosing what the config contains (min/max replica bounds, target ongoing requests) and the target-default behavior. It does not discuss failure modes, but for a simple read this is solid.

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 single-line summary followed by a compact Args block; no filler sentences. The Args list necessarily restates the schema fields given zero schema documentation, so it earns its space.

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

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

With no output schema, the description usefully summarizes the returned bounds, and all three parameters are explained for a 2-required-param tool. Remaining gaps (error conditions, permissions) are minor for a read-only getter.

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: it labels application and deployment by role and explains that target should be omitted to use the default. It adds real meaning beyond the bare property 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+resource (get autoscale config) and even previews the returned fields (min/max replicas, target ongoing requests). The [READ] tag distinguishes it from the sibling autoscale_config_update, though it does not name that sibling 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?

No when-to-use context, prerequisites, or alternatives are given. The reader must infer that this is the query counterpart to autoscale_config_update purely from naming convention.

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 context beyond the annotations: it labels itself [WRITE][risk=medium], notes the change is applied live 'without a redeploy', and calls the operation 'reversible'. These are genuine behavioral facts the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=true) do not convey, though it never states required permissions or what failure looks like.

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

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

Front-loads the [WRITE][risk=medium] tag and the core purpose in one line, then enumerates args compactly. The Args block is justified given 0% schema description coverage, and there is no filler prose.

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 6-parameter mutation tool with no output schema and zero schema descriptions, the description covers purpose, all parameters, risk level, and reversibility. Remaining gaps (permissions, cross-parameter validation, effect on in-flight traffic) are minor but real for a medium-risk live config change.

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 parameter burden, and it does: all six params get meaning ('per-replica concurrency target', 'floor'/'ceiling', 'inference target name from config; omit for the default'). It stops short of stating numeric constraints (e.g., min <= max) or validation behavior.

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 action and resource: live-tuning autoscale bounds (min/max replicas, concurrency target) without a redeploy. This distinguishes it from read-oriented siblings like autoscale_config_get and from scale_replicas_up/down, though it never names those alternatives explicitly. Clear enough for an agent to pick the right tool.

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

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

Provides useful per-parameter usage guidance ('omit to leave unchanged', 'omit for the default'), which implies partial-update semantics, but gives no explicit when-to-use-versus-alternatives framing against scale_replicas_up, scale_replicas_down, or routing_policy_update. 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 [READ] tag is consistent with readOnlyHint=true. Beyond annotations, the description discloses the computation model (throughput gauge x GPU hourly cost) and, importantly, the degradation behavior when no throughput metric exists ('insufficient-data forecast'), which the annotations do not convey.

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

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

Purpose is front-loaded in the first sentence, followed by mechanism, degradation behavior, and a clean Args block. Slightly verbose in the middle sentence, but every clause 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?

With no output schema, the description still names the returned concept (cost of serving 1M tokens) and the fallback state, and it documents all three parameters. It stops short of describing the actual response shape or units in the return payload, a minor gap for a computed read tool.

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

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

Schema coverage is 0%, so the description must carry the parameter burden, and it does: gpu_hourly_cost is defined with a concrete example (cloud on-demand rate), num_gpus is described as the backing GPU count with a default, and target is explained as a config name that can be omitted for the default.

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

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

The description gives a specific verb+resource: it derives a $/1M-token unit cost from live vLLM throughput, and even explains the multiplication mechanism. It is unambiguous about what the tool produces, though it never explicitly distinguishes itself from the metric-oriented siblings (request_metrics, gpu_utilization) beyond being the cost-attribution tool.

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance. With ~40 siblings in the same server, the description leaves the agent to infer that this is the cost tool purely from its name and purpose statement.

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

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

Annotations already declare a non-read-only, destructive, non-idempotent operation; the description adds genuine value beyond them by flagging [WRITE][risk=high] and warning that unfinished requests can be dropped. It does not state whether the dropped-request behavior is avoidable or what the failure mode is, so it stops short of 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?

The risk tag and the destructive consequence are front-loaded before the Args block, and no sentence is wasted. The standard Args listing is slightly redundant with the clearly named schema properties but keeps the entry self-contained.

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

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

For a 4-param, no-output-schema mutation tool this covers what an agent needs: operation type, risk, side effects, preview escape hatch, and per-param meaning. Missing only a note on what a successful or failed redeploy returns and how long it takes.

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 — and it documents all four args, including the non-obvious target semantics ('Inference target name from config; omit for the default'). application and deployment are only described shallowly, so it does not fully compensate.

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: force a deployment to re-apply new config. It implicitly distinguishes itself from creation tools like model_deploy and disruption tools like replica_restart, though it never names a sibling explicitly, so it lands at clear-but-not-differentiated.

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 one actionable when: use dry_run=True to preview before applying. It does not say when to prefer this over replica_restart, model_deploy, or scale_* siblings, nor what prerequisites (e.g. config already changed) must hold, leaving the selection decision mostly to inference.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this with the '[READ]' tag while adding genuine value beyond the annotation: it discloses what fields come back (status plus current/target replica counts) and where the 'application' identifier originates. It does not cover auth requirements or rate limits, but for a simple read tool that is a minor 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?

Front-loaded one-line summary followed by a tight Args block; every line conveys a distinct piece of information with no filler.

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

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

With no output schema, the description must convey return content, and it does mention status and replica counts, though it doesn't enumerate possible status values. For a three-parameter read-only lookup whose safety profile is already in annotations, this is complete enough to invoke 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 carries the full parameter burden and does so well: it labels 'application' as a Serve application name and points to serve_deployment_list, identifies 'deployment' as the deployment within that application, and explains 'target' as an inference target from config with the default behavior when omitted. Only the exact expected string formats are left unspecified.

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 ('One deployment's status') and names the returned fields (status, current/target replica count), so an agent knows exactly what it gets back. It also ties itself to serve_deployment_list as the source of application names, which hints at differentiation, though it doesn't explicitly contrast with other deployment tools like deployment_redeploy.

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 '[READ]' tag and the reference to serve_deployment_list suggest this is the inspection step in a deploy/status workflow, and 'omit for the default' clarifies the optional target. There is no explicit when-to-use vs. when-to-use-an-alternative guidance.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: it explains which signals it correlates (queue backpressure, KV/token-cache pressure, cache locality) and what it produces (a ranked cause plus the knob to turn). No contradiction with the read-only hint; only missing detail is any latency/cost of the analysis.

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 [READ][RCA] tags and the core action, then the mechanism, then the sibling contrast, then args. Every sentence earns its place. The bracketed tags and the trailing 'Args:' block are slightly telegraphic but not wasteful.

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

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

There is no output schema, so the description must characterize the return, and it does: a ranked cause plus the recommended knob. The sole parameter is explained and the default behavior is stated. Adequate for a read-only single-parameter diagnostic, though it does not hint at the size/shape of the ranking.

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

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

Schema description coverage is 0% and the single 'target' param has only a default of null, so the description carries the full burden — and it does, explaining that target is an inference target name from config and that omitting it selects the default. No enum or format examples are given, so 5 is not warranted.

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: ranks probable causes of a latency spike for a serving engine. Crucially it names the sibling it differs from, diagnose_latency_spike, and the axis of difference (engine-agnostic vs vLLM-specific), so an agent can pick between them without opening either schema.

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

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

It clearly routes the agent: use this for engines other than vLLM, use diagnose_latency_spike for vLLM. That is an explicit alternative plus a selecting condition. It stops short of a full when/when-not statement (e.g. no prerequisite that a spike actually be observed first), so it is not a 5.

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

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

The readOnlyHint annotation already establishes the safe-read profile, so the bar is lower; the description goes beyond it by naming the internal signals it correlates (queue depth, KV-cache pressure/preemption, prefix-cache locality) and the shape of the result (a ranked cause list plus a recommended knob). It omits any mention of cost/latency of the analysis itself, keeping it from a 5.

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

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

Front-loads the type tags and the one-line purpose before the correlation detail and Args block — well ordered and mostly tight. The correlation sentence is arguably more than strictly needed for selection, but it earns its place by clarifying output.

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 single-optional-param, read-only diagnostic with no output schema, the description is nearly complete: it covers purpose, when to call, inputs, and the nature of the returned ranked causes. Minor gaps remain around target naming and whether it scopes to one target or the whole cluster.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it explains that 'target' is an inference target name sourced from config and that omitting it uses the default. It does not specify valid name formats or how to discover targets, but the single optional param is largely 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+resource ('Rank the probable cause of a TTFT/latency spike') and adds a secondary output ('the knob to turn'), which is concrete. The [READ][RCA] tags reinforce intent. It stops short of explicitly distinguishing itself from the near-identical sibling diagnose_engine_latency, so sibling differentiation is only implied.

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

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

Provides a clear trigger: 'call this first on "why is inference slow"', which routes the agent to start here. However, it never names an alternative or a when-not condition, and the close sibling diagnose_engine_latency is left unaddressed.

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, and the [READ] tag restates that. The description adds that this is an RCA/explanation tool rather than a raw metric fetch, which is genuinely useful context, but it says nothing about what the diagnosis returns, confidence, or any rate/cost considerations.

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 tags and the core action, then the argument, with no filler sentences. The 'Args:' block is slightly formal for a one-parameter tool but costs nothing in 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?

With no output schema, the description needs to convey what a diagnosis yields; the cause list partially does this but the agent gets no sense of the response shape or whether remediation hints are included. For a multi-step RCA tool this is adequate but thin.

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 for the single parameter — and it does: 'Inference target name from config; omit for the default' explains both the value source and the optional/default behavior. That fully compensates for 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 and resource: explain an under-used GPU, with the diagnostic categories (batching / idle / overprovision) named up front. The [READ][RCA] tags immediately separate it from the plain metric siblings such as gpu_utilization, 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: an agent infers it should call this when a GPU looks under-utilized, and the cause list hints at what it searches for. There is no explicit when-to-use versus gpu_utilization or the other diagnose_* siblings, and no exclusions or 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?

With annotations present the bar is lower, yet the description adds substantial context beyond them: it discloses that the tool performs no drain and returns a teaching error, that the limitation is REST-vs-Python-API, and that dry_run previews the same unavailability 'rather than a false green.' It does not describe the error/return shape, but the key behavioral traits are well covered.

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 [WRITE][risk=high] marker and the crucial unavailability fact, then structured with an Args block. The middle sentences restate the unavailability theme a few times ('no per-replica drain endpoint' / 'Python-API capability only' / 'refuses'), a touch of redundancy, but nothing is wasted overall.

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

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

No output schema exists, and the description nonetheless explains that the tool refuses and what the dry_run preview does. For a refusal/teaching stub with a 5-param signature, the essential facts (unavailable, why, correct alternative) are all present; only the concrete error-response format is left implicit.

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

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

Schema description coverage is 0%, so the description must carry the load — and its Args section documents all five parameters: application, deployment, replica_id (with source hint 'from replica_list'), dry_run (behavior when true), and target (default behavior when omitted). This compensates well for the empty schema, though the per-parameter detail is brief.

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 (drain one replica) and immediately clarifies the actual behavior — the tool refuses with a teaching error because per-replica drain is not exposed over Ray's REST API. It distinguishes itself from siblings by routing surplus-replica retirement to a scale-down instead. Slight naming oddity: the title implies a working drain while the body says it is a stub, but the description resolves this clearly.

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

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

Explicitly states the when-not (no per-replica drain endpoint; Python-API only) and the alternative ('To retire surplus replicas, scale the deployment down — the controller drains them gracefully'). An agent knows not to rely on this tool and exactly what to do instead, with no inference required.

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

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

readOnlyHint=true already establishes this as a safe read, and the '[READ]' tag merely repeats that. The description adds that the check runs 'via its health probe' and that a default target exists when omitted, but says nothing about timeout/latency behavior or what a positive vs negative probe means. With annotation coverage the lower bar applies, so a 3 is fair.

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

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

The core statement is front-loaded in the first line and the single argument is documented compactly. The 'Args:' block is slightly heavier formatting than needed for one optional parameter, but nothing is wasted or 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?

For a single-optional-parameter, read-only liveness probe with no output schema, the description covers the operation, the runtime scope, and the default-target behavior, while the annotation covers safety. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 0%, so the description must carry the load and it does: 'target: Inference target name from config; omit for the default' explains both the value source and the omitted-parameter behavior, which is exactly the information an agent needs and cannot get from the bare anyOf string 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?

Names a specific resource (the serving engine runtime: vLLM / SGLang / TGI) and a specific operation (liveness check via health probe), which separates it from siblings like engine_inventory, engine_queue_depth, and kv_cache_stats. It never explicitly says which sibling to prefer, so it falls just short of a 5.

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

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

The only usage guidance is the parameter hint 'omit for the default', which is really parameter semantics rather than when-to-use guidance. There is no statement of when to reach for this probe versus engine_inventory, engine_queue_depth, or the diagnose_* tools, so usage is only implied by the purpose.

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, and the description adds genuine context beyond it: it is engine-agnostic and explains that served ids come from /v1/models on vLLM/SGLang versus /info on TGI. No contradictions; it does not cover return format or pagination, but for a single-target read tool the added backend detail is meaningful.

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

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

Front-loads the read tag and core purpose, then spends one sentence on engine-specific sourcing and one short line on the arg. No padding, though the engine-by-engine sentence is arguably more detail than needed for a simple inventory call.

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

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

For a one-parameter, no-output-schema read tool this is nearly complete: purpose, safety signal, engine-agnostic behavior, and the target parameter are all covered. Only the shape of the returned inventory is left implicit, which is acceptable for a simple identity lookup.

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

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

Schema description coverage is 0%, so the description carries the burden, and it does so well: 'target: Inference target name from config; omit for the default' explains both the meaning of the value and the null/default behavior. This compensates for the bare anyOf string/null schema.

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

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

The description names a specific resource (running-model identity + engine server info) and explicitly tags it as a read operation, so an agent knows what it returns. It distinguishes itself from the many sibling engine/metrics tools only implicitly via 'identity ... engine-agnostic' and never names a sibling it is not, such as model_info or engine_health.

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

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

Usage is implied by the '[READ]' tag and the nature of an inventory call, and it explains how vLLM/SGLang vs TGI report ids, but there is no explicit 'use when' framing or alternative. With so many adjacent tools (engine_health, model_list, model_info), the lack of routing guidance is a real gap.

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 a safe read, so the bar is lower. The description adds the [READ] marker and note that it applies to any engine, but says nothing about return shape or whether values are instantaneous vs averaged.

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 chunks with the leading role stated first, then minimal arg documentation. 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 single optional-param read tool with no output schema, the definition covers purpose, scope, and param behavior adequately. Only minor gaps (units/interpretation of the depth values) remain.

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 explain the single param: "Inference target name from config; omit for the default," clarifying both meaning and default-fallback behavior that the bare string/null schema lacks.

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 resource and metric ("Running vs waiting requests") and characterizes its role as "the leading backpressure signal (any engine)", so an agent knows what the tool returns. It does not, however, distinguish itself from sibling queue_depth, which appears to cover similar ground.

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 leading backpressure signal" implies when the tool is useful (backpressure diagnosis) and "(any engine)" clarifies scope, but there is no explicit when-to-use/when-not or named alternative among the many engine_* diagnostic siblings.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered, and the '[READ]' prefix is redundant with that. The description does add one piece of real behavioral context – '(where the engine exposes them)' signals that some metrics may be unavailable depending on the backend – but says nothing about return format or time windowing.

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 elements – a bracketed tag plus metric list, and a single Args line. Front-loaded and free of filler, though the '[READ]' tag duplicates the readOnlyHint annotation.

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 single-optional-param read tool with annotations covering safety, the description tells the agent what it returns (the metric names) and how to scope it (target). It lacks only time-range/pagination context, which is minor here.

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, and it does: 'target: Inference target name from config; omit for the default' explains both the value source and the default behavior. That meaningfully exceeds the empty schema, though it doesn't give format examples.

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

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

The description states a specific resource set – TTFT / TPOT / e2e latency plus generation-token totals – which is far more concrete than the generic name. It does not, however, distinguish itself from the sibling 'request_metrics' or 'diagnose_engine_latency', leaving the agent to guess which latency-metric tool to pick.

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 no alternatives are named despite 'request_metrics', 'diagnose_engine_latency', and 'diagnose_latency_spike' being obvious competitors. The only routing information is the param note 'omit for the default', which is about invocation, not tool selection.

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

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

readOnlyHint=true already tells the agent this is a safe read, and the '[READ]' prefix merely restates it. The description does add the concrete payload shape (per-node count, util %, memory used/total), which is useful behavioural context. It says nothing about permissions, refresh cadence, or cost of the call.

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

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

Two compact lines: the read-only marker and payload summary come first, then the single argument. Nothing is padded and the most important information is front-loaded.

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

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

With no output schema, the description correctly carries the burden of describing return values (count, utilisation %, memory used/total) and resolves the only parameter's default behaviour. The remaining gap is the absence of routing guidance against the many overlapping diagnostic siblings, which matters given this tool's crowded neighbourhood.

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 schema alone leaves 'target' opaque, but the description compensates by explaining it is an inference target name from config and that omitting it selects the default. That is exactly the semantic gap the schema fails to fill, though 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?

The description names a specific resource (GPU) and precisely enumerates what it returns: per-node GPU count, utilisation %, and memory used/total. That is far more than a restatement of the name. It does not explicitly contrast itself with related siblings such as diagnose_low_utilization or kv_cache_stats, so it falls just short of a 5.

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

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

The '[READ]' tag signals this is a non-mutating observation tool, which is weak usage guidance. There is no statement of when to prefer this over the many other diagnostic siblings (diagnose_low_utilization, engine_inventory, kv_cache_stats), nor any exclusion or precondition.

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, and the '[READ]' marker merely restates it. The description does add value by naming the three metrics returned, but says nothing about refresh behaviour, aggregation window, or whether a missing target errors versus falling back to default.

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 metric list is front-loaded in one sentence and the argument note is terse. The 'Args:' block is mildly redundant formatting for a single optional parameter but carries the non-obvious default semantics, so it 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?

For a simple read-only stats tool with no output schema, listing the three reported metrics is the key missing piece an agent needs, and it is present. Only minor gaps remain, such as units or aggregation window for the reported numbers.

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, and it does: 'Inference target name from config; omit for the default' explains both the source of valid values and the defaulting behaviour, which the bare anyOf/null schema 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?

States a specific resource (KV-cache stats) and enumerates exactly what it reports: utilisation, prefix-cache hit rate, and preemption count. This distinguishes it from siblings like engine_request_metrics and request_metrics, though it never names those siblings explicitly.

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

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

There is no when-to-use guidance, no mention of alternatives among the many metrics/health tools in the sibling list, and no prerequisites. The only usage hint is the parameter note 'omit for the default', which is about input, not tool selection.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=true, so the safety profile is covered structurally. The description adds the [WRITE][risk=medium] classification and the 'hot-load' semantics (live engine, no restart), but does not disclose what happens on name conflicts, whether an existing adapter is evicted, or any permission 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?

It is front-loaded with the operation type and risk marker, then one purpose sentence, then a compact Args block. Every line earns its place, and the Args block is justified by the schema's zero description coverage.

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

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

For a mutation tool with annotations but no output schema, the definition covers purpose and all parameters adequately. However, behavioral gaps remain for a medium-risk hot-load operation: conflict/replacement behavior, interaction with lora_unload, and any effect on engine state or memory are unstated.

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

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

Schema description coverage is 0%, so the description must carry the full parameter burden, and it does: lora_name as the name to register, lora_path as a local path or HF repo id, and target as a config-defined inference target with 'omit for the default' behavior. Every parameter gains meaning not present in the bare schema titles.

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 precise verb and resource: 'Hot-load a LoRA adapter onto the running engine,' which is clearly distinct from sibling operations like model_deploy or lora_unload. It does not explicitly name or contrast those siblings, so it lands at clear-but-no-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?

Usage is only implied: 'Hot-load ... onto the running engine' suggests the engine must already be running and that this adds an adapter without a redeploy. There is no explicit when-to-use vs lora_unload/model_deploy guidance, no prerequisites, and 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 already flag destructiveHint=true and idempotentHint=false, but the description adds the concrete consequence ('traffic on it starts failing'), which is exactly the impact an agent needs before invoking a destructive op, and it offers a preview escape hatch via dry_run. It stops short of permissions, reversibility, or recovery guidance.

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

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

Front-loads the [WRITE][risk=high] severity marker, then the impact, then the safe preview path, then a compact args block. Every sentence earns its place with no filler.

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

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

For a destructive, three-parameter tool with no output schema, the definition covers severity, impact, preview path, and all parameter semantics; annotations carry the safety profile. Nothing essential for correct 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 description coverage is 0%, so the description carries the full burden — and it documents all three parameters: lora_name with a source cross-reference (model_list), dry_run's preview behavior, and target's default-when-omitted behavior. Only minor ambiguity remains (e.g., whether lora_name must exist beforehand).

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 ('Hot-unload a LoRA adapter') and immediately qualifies the scope ('Hot') plus the observable effect on traffic. An agent can distinguish it from the lora_load sibling on name semantics alone.

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

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

Gives a usable hook ('traffic on it starts failing') and an explicit safe path ('Pass dry_run=True to preview'), which is real usage guidance. However, it never contrasts with alternatives such as lora_load, model_undeploy, or replica_restart, and states no when-not conditions.

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

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

Annotations already declare write/destructive/non-idempotent, and the description adds real behavioral context beyond them: the app is merged into declarative config with existing apps preserved, replica counts come from the app's own config, and deployment names only exist after materialisation. Auth/permission requirements and failure behavior are still unstated, and 'existing apps preserved' sits a little uneasily beside destructiveHint=true.

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 [WRITE][risk=medium] tag and the core purpose are front-loaded, and the Args block is compact. The final parenthetical about deployment names is a touch convoluted, but no sentence is wasted.

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

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

For a non-idempotent mutation with no output schema, the description covers merge semantics, replica behavior, and naming. It stops short of permissions, error/rollback behavior, or what a successful response returns, so it is strong but not exhaustive.

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 document all three args: application semantics ('create/replace'), import_path format with an example ('module:app'), and target ('omit for the default'). This compensates well for the empty schema, though the descriptions stay terse.

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 ('Deploy a Serve application from an import path'), plus the operational mode (merge into declarative config). This clearly separates it from siblings like model_undeploy and deployment_redeploy without needing to open any schema.

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

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

It offers a sequencing hint ('set replica counts afterward with serve scale'), which is genuinely useful, but never says when to choose this over deployment_redeploy, nor any preconditions or exclusions. 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?

readOnlyHint=true already covers the safety profile, so the bar is lower. The description adds the "[READ]" marker and the useful caveat that the permission field is best-effort (i.e., may be incomplete), which the annotations do not convey. It says nothing about error behavior for an unknown model_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?

Two short lines: a front-loaded one-sentence summary of what is returned, then a tight per-argument list. No filler or repetition.

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

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

For a simple read-only getter with no output schema, naming the returned config fields and the best-effort caveat gives the agent enough to call it and interpret the result. The absence of any note on missing/unknown model_id handling is the only real gap.

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

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

Schema description coverage is 0%, so the description must carry the full load — and it does document both parameters: model_id's provenance (model_list) and target's meaning plus its omission default. Only the string format of target is left unspecified.

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 — read one model's config — and enumerates the fields returned (max length, root/parent, permission). The word "One" implies the counterpart to the sibling list tool, but it never names model_list as the plural alternative, so it stops short of explicit 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?

Usage is only implied: it tells the agent where model_id comes from (model_list) and that target may be omitted for the default. There is no statement of when to prefer this over model_list or the other model_* tools, and no 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?

Beyond the readOnlyHint annotation, it discloses the three-valued return contract (true/false/null) and explicitly warns that null means UNKNOWN, not awake — a real trap for an agent. It also states the VLLM_SERVER_DEV_MODE=1 precondition and that other servers report the route as absent rather than failing vaguely, which is rich, non-obvious behavioral detail.

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 read tag and core question, then return semantics, then the precondition, then args. No sentence is filler; the structure maps cleanly onto what an agent needs in order of priority.

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

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

No output schema exists, and the description compensates by fully documenting the return values and their edge case. Combined with the dev-mode precondition and the param explanation, nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 0%, so the description carries the full burden for the single 'target' param, and it does: 'Inference target name from config; omit for the default.' That fully explains source and default behavior, though it adds no format or naming convention detail.

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

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

The description opens with a specific read verb and resource: '[READ] Whether the vLLM engine is suspended in Sleep Mode.' The read framing and the query semantics clearly separate it from the mutation siblings model_sleep and model_wake, so an agent can select it without opening any schema.

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

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

Usage is implied (check sleep state) but the description never states when to reach for this versus model_sleep/model_wake or as a precondition to waking. The dev-mode caveat is useful context but is a behavioral constraint rather than routing guidance.

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

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

readOnlyHint=true already declares the safety profile, so the '[READ]' tag is largely redundant. The description does add that LoRA adapters are flagged in the output, which tells the agent something about content. No contradiction, but limited extra behavioral context beyond 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?

Front-loads the purpose in one line, then the parameter note. Short and efficient with minimal waste, though the '[READ]' prefix duplicates the annotation and adds 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?

For a simple, annotation-covered list tool with no output schema, the description covers what it returns (served models with LoRA flagged) and how the single optional parameter behaves. Sufficient to invoke correctly, though auth/prerequisite context is absent.

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 here, and it does: it explains 'target' as an inference target name from config and states that omitting it uses the default. That meaningfully compensates for the undocumented schema parameter.

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 (served vLLM models) with scope ('all served'). It implicitly contrasts with model_info (single-model detail), though it never names the sibling explicitly. Clear purpose without explicit 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?

No explicit when-to-use or when-not-to-use guidance, and no alternatives named among the many model_* siblings (model_info, model_deploy, model_undeploy). Usage is only implied by the '[READ] All served models' phrasing, with a small hint that omitting target selects the default.

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 destructiveHint=true and readOnlyHint=false; the description goes well beyond them by explaining what is actually destroyed/freed at each level, that level=2 causes a disk reload on wake, that dry_run previews without suspending, and how errors surface on non-dev servers. This is exactly the extra context annotations cannot carry.

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

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

The [WRITE][risk=high] tag is front-loaded and the purpose sentence comes before the mechanics, which is good ordering. The Args block repeats the level=1/level=2 explanation already given in the prose, a minor redundancy that keeps it from a 5.

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 mode-switching write with no output schema, the description covers the safety profile, the state transition, wake-up implications, the dev-mode prerequisite, and the failure mode. An agent has everything needed to decide and 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 carry all meaning, and it defines all three parameters including the defaulted level, the dry_run preview behavior, and target ('omit for the default'). It could have clarified the accepted string form of target, but the coverage gap is largely closed.

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 ('Suspend the engine via Sleep Mode') plus the operational consequence ('it stops serving requests'). The name model_sleep is vague on its own, but the description disambiguates it against siblings like model_wake, model_is_sleeping, and model_undeploy.

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

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

Gives a clear use case ('Frees GPU memory between bursts'), names the counterpart tool to undo it ('The engine serves nothing until model_wake'), and states the prerequisite (VLLM_SERVER_DEV_MODE=1). It does not compare against other memory-freeing siblings such as scale_to_zero or model_undeploy, so the agent must still infer when Sleep Mode is preferable to those.

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 destructive=true and non-idempotent, but the description adds genuinely new behavioral context: it destroys the whole application (all deployments), it is irreversible without the original import path, and dry_run provides a preview. This goes meaningfully beyond the annotation flags without contradicting them.

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 risk tag and the core verb, followed by the irreversibility caveat and a compact per-argument list. Every sentence earns its place with no filler.

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

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

For a destructive, no-output-schema tool this is nearly complete: risk, scope, reversibility, and all params are covered. It stops just short of stating whether auth/permissions are required or what dry_run returns, but nothing critical for correct 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?

With 0% schema description coverage, the description carries the full burden and documents all three params: application (sourced from serve_deployment_list), dry_run, and target (omit for default). This compensates well, though target's exact format is only lightly described.

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 ('Tear down a whole Serve application') and scopes it precisely by noting it removes all deployments, which distinguishes it from narrower siblings like scale_to_zero or replica_restart. The [WRITE][risk=high] tag immediately frames the operation.

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

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

Gives a clear operational tip ('pass dry_run=True to preview') and signals irreversibility, so an agent knows the safe path. However, it never names an alternative sibling or an explicit when-not condition, leaving sibling routing (e.g. vs scale_to_zero) to inference.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, but the description adds non-obvious behavior: no undo record is kept, the reason (vLLM does not report sleep level), the VLLM_SERVER_DEV_MODE=1 requirement, and how an unsupported server surfaces the error. This is materially more than the annotations provide.

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

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

Front-loaded with the [WRITE][risk=medium] tag and the core purpose, then the routing/undo rationale, then args. The middle paragraph about guessing sleep levels is slightly digressive but justifies a real decision the caller has to make.

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 2-param mutation tool with no output schema, the description covers safety signals, the environment precondition, the irreversibility caveat, an alternative tool, and both parameters. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must carry the params, and it documents both: dry_run as a non-waking preview and target as a config name with 'omit for the default'. It does not clarify target syntax/id format, so it falls just short of fully compensating 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 ('Resume serving after Sleep Mode') plus the observable effect ('weights return to GPU'), and explicitly frames itself as the inverse of model_sleep. An agent can distinguish it from every sibling 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?

Names the complementary tool (model_sleep), the condition under which to prefer it ('call model_sleep with the level you want instead' when re-sleeping), and the dry_run preview path. It also states the precondition that Sleep Mode requires VLLM_SERVER_DEV_MODE=1 and what happens otherwise.

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 some behavioral context by labeling the metric as the 'leading backpressure signal' and clarifying the [READ] nature, but it does not describe data freshness, units, return shape, or any operational caveats. With annotations carrying the main burden, this is a modest but non-zero addition.

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

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

The description is short and front-loaded, with the leading sentence summarizing the metric and the Args block adding grounded parameter context. It is efficiently sized, though the dash-separated clause is slightly telegraphic.

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

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

For a one-parameter read tool with no output schema, the description is adequate but incomplete: it does not mention when to prefer it over engine_queue_depth or other metrics, and it offers no return-value expectations. Given the busy sibling set of metrics and diagnostic tools, more routing context would help.

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 schema gives no per-parameter documentation. The description compensates by explaining that the single 'target' parameter is an 'Inference target name from config' and that omitting it selects the default. That is useful semantic guidance above the bare schema, though the format or valid names are not specified.

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

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

The description uses a clear verb-less but specific noun phrase: it reports 'Running vs waiting requests' for an inference target. It distinguishes itself from siblings like engine_queue_depth and request_metrics by framing the metric as a 'backpressure signal', though it does not explicitly name an alternative. The [READ] tag and metrics focus make the purpose legible.

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 what the metric is but gives no guidance on when to use this tool versus alternatives such as engine_queue_depth, engine_request_metrics, or request_metrics. The only usage-like hint is 'leading backpressure signal', which implies diagnostic context but does not say when to select queue_depth over a sibling.

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, and the '[READ]' prefix merely repeats that. The description does add real value by enumerating the data categories returned (capacity, headroom, pending placement groups), but discloses nothing about permissions, cost, or how stale/live the snapshot is.

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, front-loaded lines with the action and payload stated first and no filler. The 'Args:' block is slightly formal for a single optional parameter but costs almost nothing.

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

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

With no output schema, the description is the only source of return information, and it gives only a terse summary of the payload without structure, units, or interpretation of 'headroom'. It is sufficient to call correctly but not sufficient to use the result confidently.

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 single parameter, and it does: 'target: Inference target name from config; omit for the default' explains both the source of valid values (the config) and the defaulting behavior. Minor gap: it does not say whether the name matches a config key or a display name.

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

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

The description names a concrete resource scope (cluster-wide CPU/GPU capacity, headroom, pending placement groups) rather than restating the name, so an agent can tell it apart from utilization-style siblings like gpu_utilization. It stops short of explicitly contrasting itself with ray_dashboard_status or engine_inventory, which also report cluster state.

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

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

There is no when-to-use or when-not-to-use guidance and no named alternative, despite a crowded sibling set (gpu_utilization, ray_dashboard_status, engine_inventory, diagnose_low_utilization) that overlaps in subject matter. Usage is only implied by the word 'capacity'.

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, and the description's [READ] tag plus 'controller health + counts' confirms the safety profile and hints at the return content. It adds no detail on permissions, rate limits, or freshness of the reported counts, so it stays at the minimum-viable level given annotation coverage.

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 single sentence with the read marker and resource up front, followed by a compact Args block. No waste, though the Args header is slightly formal overhead for one 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?

For a read-only status tool with no output schema and one optional parameter, the description covers what it returns and how to invoke it with or without a target. Missing only the usual read-tool caveats about staleness or auth, which are minor here.

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 explains target is an inference target name sourced from config and that omitting it selects the default. That resolves the key ambiguity for the sole optional parameter.

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: serves controller health plus app/deployment counts, with a [READ] marker. An agent can separate it from cluster-wide siblings like ray_cluster_resources or replica-level tools like replica_list, though it doesn't name a specific alternative.

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 and no alternatives named among the many sibling diagnostics. The only context is the parameter note about omitting target for the default, which is invocation help rather than usage guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the safety profile is covered. The description adds the [WRITE][risk=medium] tag and the fact that both submitted and running jobs are affected, but says nothing about whether cancellation is graceful or what state the job ends in.

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 [WRITE][risk=medium] marker and a one-line purpose, followed by a compact args block. Every element adds information, though the args block partly restates schema property names.

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

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

For a two-parameter mutation with annotations covering safety and no output schema, the description is largely sufficient: both params explained, provenance given, default behavior noted. Minor gap is the absence of any post-cancellation outcome or failure behavior.

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

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

Schema description coverage is 0%, so the description must carry the burden, and it does document both parameters: job_id with its provenance (from ray_job_list) and target as an inference target name from config with the rule to omit it for the default. Only the job_id format itself is left unspecified.

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

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

States a specific verb and resource ('Stop a submitted/running Ray job') and clarifies it works on jobs in either state. It also points to ray_job_list as the source of job ids, which helps distinguish it from the sibling that enumerates jobs, though it does not name any alternative cancellation path.

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 'submitted/running' qualifier implies the condition under which cancellation applies, and the reference to ray_job_list implies the expected workflow. However, there is no explicit when-not guidance and no statement of alternatives or prerequisites (e.g., auth or ownership).

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, but the description adds real behavioral context: the exact return envelope keys and, importantly, the truncation semantics with an explicit corrective action. That is the kind of non-obvious trait the schema and annotations cannot convey, since there is no output schema.

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

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

Front-loaded with purpose, then return shape, then the actionable truncation warning, then args — a sensible order. The Args block partly repeats defaults already present in the schema, which is minor waste in an otherwise tight description.

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 2-parameter, no-required-input, no-output-schema read tool, the description covers purpose, both parameters, the return envelope, and the truncation edge case. An agent has everything needed to call it and interpret the result 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 both parameters — and it does: `target` is "Inference target name from config; omit for the default" and `limit` is the maximum rows with a default of 100. The meaning is recovered, though "from config" remains slightly vague about where that name comes from.

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 leads with a specific verb+resource ("Submitted Ray jobs") and enumerates the visible fields (id, status, entrypoint, start time), which is more than enough for an agent to know what this returns. It is implicitly distinguished from ray_job_cancel by the "[READ]" marker, but no sibling is named explicitly, keeping it just short of a 5.

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

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

It gives concrete conditional guidance: omit target to use the default, and if `truncated` is true re-run with a higher limit instead of treating the result as complete. What's missing is any statement of when to pick this over adjacent tools like ray_cluster_resources or ray_dashboard_status, so 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?

readOnlyHint=true already establishes the safety profile, so the '[READ]' prefix adds little. The description does add useful context by naming the replica state values returned, which matters because there is no output schema. It does not describe permissions, pagination, or ordering.

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?

Brevity is appropriate: a front-loaded classification tag, one sentence of purpose, and a compact args list. The '[READ]' tag is somewhat redundant with the annotation but does help scanability; otherwise every line 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?

For a simple three-parameter read with no output schema, the description covers all inputs and pre-empts the main unknown (what states come back). Missing only peripheral detail such as error behavior when the deployment name is unknown.

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 does document all three parameters, including the non-obvious semantics of 'target' (from config, omitted for the default). It omits format/identifier details, but the top-level meaning of every parameter is 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?

Clear verb+resource: lists replica states scoped to one deployment, and enumerates the possible states (running/starting/draining). It distinguishes itself from a global list by 'for one deployment,' though it does not explicitly position itself against siblings like deployment_status or drain_replica.

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

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

There is no when-to-use guidance. Nothing says whether this is for monitoring, pre-drain checks, or debugging, nor how it differs from deployment_status (status summary) or replica_restart (mutation). The only usage hint is 'omit for the default' on target.

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 discloses behavior the annotations cannot express: the tool is a deliberate no-op that 'refuses with a teaching error,' and dry_run previews that refusal honestly. There is mild tension with destructiveHint=true / idempotentHint=false, which reflect the nominal write intent rather than actual effects, but the description resolves that ambiguity rather than creating it, so this is added value, not a 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?

Front-loaded with the [WRITE][risk=high] marker and the single most important fact, then rationale, alternatives, and args. Slight redundancy in stating REST unavailability twice ('NOT available over Ray's REST API' and 'exposes no per-replica restart endpoint over REST'), but the repetition is arguably deliberate emphasis for a refusal tool.

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

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

For a tool that can never succeed, the description covers everything an agent needs: why it fails, what the error is, that dry_run mirrors the failure, and what to do instead. With no output schema and only nominal annotations, nothing material is left unexplained.

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

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

Schema coverage is 0% (bare titles only), so the description carries the burden and largely does: it defines application, deployment, replica_id with its provenance ('from replica_list'), dry_run's effect, and target's default-omission semantics. It does not restate types, but the meaning of each parameter is clear.

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 one Serve replica) and immediately negates it with the crucial scope fact: it is NOT available over Ray's REST API. This lets an agent distinguish it from siblings like drain_replica, scale_replicas_up/down, and deployment_redeploy without opening any schema.

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

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

Explicitly says when not to use it (no per-replica REST endpoint exists; the controller respawns unhealthy replicas itself) and names concrete alternatives ('scale the deployment down then up, or redeploy'). It even explains that dry_run returns the same unavailability rather than a false positive, closing the obvious loophole an agent would try.

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 the safety profile, and the '[READ]' prefix merely restates it. The description adds no behavioral context such as the time window the metrics cover, aggregation granularity, or whether data is live versus historical, so it clears the lower annotation-assisted bar but adds little.

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 lines with the metric list front-loaded and no filler. The 'Args:' block is slightly over-formatted for a single parameter but still earns its place by documenting the target.

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 metrics tool with no output schema and only a readOnlyHint annotation, the definition is minimally sufficient: it says what metrics are returned and how target selects the source. It omits the observation window, units, and refresh behavior, which matter for interpreting latency metrics.

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

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

Schema coverage is 0% and the schema only carries a title and null default, so the description must compensate. It does so by explaining that 'target' is an inference target name drawn from config and that omitting it selects the default, which is meaningful semantics beyond the bare schema.

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

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

The description names the concrete outputs (TTFT / TPOT / e2e latency plus generation-token totals) and marks the tool as a read operation, so an agent knows exactly what data comes back. It does not, however, distinguish itself from the sibling engine_request_metrics, which sounds like an overlapping metrics endpoint, so the purpose is clear but not differentiated.

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 only guidance is about the target argument (omit for default), which is parameter usage rather than when-to-use guidance. There is no statement of when to reach for this tool versus engine_request_metrics, queue_depth, or the diagnose_* siblings, leaving selection entirely to inference.

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

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

Annotations declare readOnlyHint=false and destructiveHint=true, but the description states the tool performs no operation at all and only returns a teaching error. The described behavior is effectively a read-only no-op, which directly conflicts with the destructive write profile the annotations advertise.

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 [WRITE][risk=medium], then the critical caveat, then a structured Args block. The NOTE is somewhat long but every clause (no REST endpoint, refuses, redeploy in source) 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?

For a tool whose contract is to refuse, the description is complete: it explains why no endpoint exists, what the tool will do instead, the remediation path, and every parameter. With no output schema needed, nothing an agent requires is missing.

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

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

Schema description coverage is 0%, so the description carries the full burden — and it does: the Args block documents all four parameters (application, deployment, policy, target) and even supplies the allowed policy values (prefix_aware / round_robin / session_affinity) that the schema lacks as an enum.

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

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

The description names a specific verb+resource (switch a deployment's request-routing policy) and then immediately discloses that the tool actually refuses with a teaching error, which distinguishes it from real mutators like deployment_redeploy or autoscale_config_update. The opening line is slightly misleading before the NOTE corrects it, so it falls short of a clean 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 explicitly tells the agent when NOT to use the tool (there is no REST endpoint) and what to do instead (change the policy in the deployment's source and redeploy). That is actionable routing guidance, though it does not compare against specific sibling tools by 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 already declare the operation as non-read-only and destructive. The description adds meaningful context beyond that: high risk level, reversibility to the prior count, and the side effect of potentially stranding in-flight requests, with dry-run as a mitigation.

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

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

The description is front-loaded with a compact risk/direction prefix and then structured arguments. The fit is appropriate for a five-parameter tool with no schema descriptions, though the phrase 'reversible → prior' is slightly cryptic and could be clearer.

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 complexity (write, high-risk, destructive, five parameters, no output schema), the description covers the critical behavioral and parameter details. It could mention permissions or the interaction with undo/rollback tools, but is otherwise complete enough 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 carries the full burden of explaining parameters. It documents all five parameters, including optional ones, with clear semantics: application name, deployment name, new lower replica count, dry_run preview behavior, and target defaulting.

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 ('Lower') and resource ('deployment's replica count') with production scope. The directionality directly distinguishes it from the sibling scale_replicas_up, so an agent can select 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?

Provides a useful operational hint ('pass dry_run=True to preview') and notes the risk of stranding in-flight requests. However, it never states when to choose this tool over alternatives like scale_to_zero or autoscale_config_update, leaving the core when-to-use decision implied by the 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 already declare readOnly=false, idempotent=false, destructive=true; the description adds meaningful context beyond that — medium risk, reversibility to the prior state, and the fact that dry_run reads the live current count and fails early if the deployment is absent. The 'reversible' framing usefully softens the destructiveHint, though no auth/permission or undo mechanics are detailed.

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?

Well front-loaded: the [WRITE][risk] tag, the core action, the dry_run rationale, then Arg docs. The dry_run sentence is longer than strictly necessary, but it conveys a non-obvious failure-mode benefit rather than padding.

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 mutating tool with no output schema, the description covers direction, reversibility, dry-run semantics, and every parameter, leaving little an agent needs before calling it. Missing only permission/auth prerequisites and any rate/limit behavior.

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

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

Schema coverage is 0%, so the description must carry the burden, and it documents all five parameters including the non-obvious ones: num_replicas is constrained to a higher value, and target is 'from config; omit for the default'. Entries for application/deployment are brief but sufficient alongside their required status.

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 ('Raise a deployment's replica count'), immediately distinguishing it from the sibling scale_replicas_down and scale_to_zero. The [WRITE][risk=medium] tag further classifies the operation, so an agent identifies 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?

Gives clear operational guidance for dry_run=True, including why the preview is more accurate than a naive target-only check. It does not explicitly name the direction-based alternatives (scale_replicas_down / scale_to_zero) as exclusions, but the 'raise ... (higher) replica count' framing implies the boundary.

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 write/destructive/non-idempotent, but the description goes further: it states the operation is reversible to the prior replica count, warns of cold-start latency and possible ingress stranding, and offers dry_run as a safe preview. That is exactly the extra behavioral context the annotations cannot carry.

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

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

Front-loaded with the risk tag and core action, followed by consequences and then the argument list — a sensible ordering with little waste. The Args entries for application/deployment are near-tautological, but given 0% schema coverage they still earn their 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?

For a high-risk mutation with no output schema and 0% schema coverage, the description covers reversibility, side effects, preview, and all parameters. It stops short of mentioning how to restore replicas afterward (wake/scale-up path) or any permission requirements, but nothing essential to correct 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 description coverage is 0%, so the description must compensate, and it does via the Args block: it clarifies application is the serve application name, deployment the deployment name, dry_run previews the change, and target comes from config with a default if omitted. The entries are brief but cover all four parameters meaningfully.

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 — park a deployment at 0 replicas — and the 'at 0 replicas' scope inherently distinguishes it from sibling scaling tools such as scale_replicas_down or scale_replicas_up. The [WRITE][risk=high] tag further signals the operation class without ambiguity.

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?

Motivation is implied ('Stops the cost bleed') and the dry_run preview is suggested, but there is no explicit when-to-use/when-not guidance and no named alternative such as model_sleep, model_undeploy, or scale_replicas_down. An agent must infer the appropriate scenario.

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 [READ] tag and readOnlyHint=true both signal a safe read, and the description adds the scope ('All') and the returned fields. With annotations already covering safety, this is reasonable but adds little beyond the read-only profile.

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 [READ] marker and the resource, then the returned fields, then a compact Args block. No filler, though the Args formatting is slightly verbose for a single optional 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?

For a single-optional-param list tool with no output schema, the description covers the resource, returned fields, and the sole parameter. It is largely complete, missing only the sibling-differentiation an agent might want.

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

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

Schema coverage is 0% and the schema only exposes a bare 'Target' title, so the description carries the full burden. It compensates well by explaining target is an 'Inference target name from config' and that omitting it uses the default.

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

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

States a specific verb (list/READ) and resource (Ray Serve deployments) and enumerates the returned fields (status, replica count, target). An agent can tell it lists all deployments, though it does not explicitly differentiate itself from the sibling deployment_status or replica_list.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor any named alternative among the many siblings. The only hint, 'omit for the default', describes the target argument rather than when to choose this tool.

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

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

Annotations only declare readOnly=false, idempotent=false, destructive=true. The description goes well beyond them by explaining that the inverse executes via its own governed tool with its own audit name and risk level, that dry_run previews without running, and that a token is single-use — non-obvious governance and lifecycle behavior an agent cannot infer from the schema.

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?

Purpose is front-loaded before an Args block, and every line carries information (single-use constraint, dry-run preview). The audit sentence is somewhat wordy with repeated 'its own ... its own', but it is not padding.

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 no-output-schema mutation, the definition covers mutation semantics, governance/auditing, preview mode, and the single-use token constraint. It does not describe failure modes such as an expired or already-applied token, which for a destructive non-idempotent write would be useful.

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 does: undo_id is sourced from undo_list or a write result's `_undo_id`, dry_run previews the inverse tool and params, and target is only forwarded when the inverse tool accepts a target. That conditional semantics for `target` is exactly the kind of detail the bare schema omits.

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 ('Apply a recorded undo by dispatching its inverse tool') and immediately qualifies it as a WRITE at medium risk. It is clearly distinguishable from the sibling undo_list, which only lists tokens, whereas this one consumes them.

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

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

Gives concrete operational guidance: obtain undo_id from undo_list (or an `_undo_id` in a write result), and use dry_run=True to preview before executing. It stops short of explicit when-not-to-use or naming a true alternative path, 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?

Annotations only supply readOnlyHint=true; the description goes well beyond that by disclosing the return shape, that truncation is *measured* via an extra-row fetch, and that effectVerified=false means the reversed change is only PROBABLE, with a caution to check live state and not over-report. This is meaningful operational context the annotations cannot carry.

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

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

Front-loaded with purpose and the sibling handoff, then structured paragraphs for return value and the effectVerified caveat. Every sentence carries information, though the emphasis on truncation being 'measured, not guessed from a length coincidence' is slightly verbose for the value it adds.

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

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

With no output schema present, the description supplies the return JSON shape, the meaning of every field an agent must act on (returned, limit, truncated, effectVerified), and the follow-up behavior for truncation. Nothing needed to call or interpret it correctly is missing.

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

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

Schema description coverage is 0% and no param has an enum, so the description must compensate, and it does fully: limit is documented as default 50 / capped at 500, and target is documented as ignored with the reason (host-local undo state, kept for CLI uniformity).

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 recorded, not-yet-applied undo tokens') plus ordering ('most recent first'). The [READ] tag and the reference to undo_apply make it clearly distinguishable from the sibling that actually applies tokens.

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

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

Explicitly routes the agent: 'Use the undoId with undo_apply.' and tells it to re-run with a higher limit when truncated rather than reporting a partial list as complete. It lacks an explicit 'when not to use this' condition, so it falls just 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.