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

Annotations declare readOnlyHint=false, consistent with an install/update mutation. The description usefully adds the non-destructive scope boundary (top-level selectors untouched), which is real behavioral value beyond the annotation. It says nothing about auth needs, idempotency, or failure modes, so it is adequate but not rich.

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

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

A single front-loaded sentence: action first, then the constraint that disambiguates it. Every clause 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 zero-parameter, no-output-schema tool, the definition covers what it does and what it deliberately does not touch. Minor gap: no mention of what 'namespaced' install means operationally or any resulting state, but nothing required for correct invocation 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?

Zero parameters, so there is nothing for the description to document and the baseline is 4. No parameter-level semantics are needed or missing.

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 pair (install/update) and a precise resource (namespaced Delegation Worker provider), plus a scope boundary that separates it from provider_save/provider_delete siblings. It does not name a sibling explicitly, but the resource itself is distinctive enough for an agent to route correctly.

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

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

The clause 'without changing official top-level model/provider selectors' implies the scenario in which this tool is preferred over the general provider tools, but no alternative is named and no prerequisites are stated. Usage is inferable rather than explicit.

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 destructiveHint=false, so the safe read-only nature is covered. The description adds the scope of what is read (the namespaced Delegation Worker Codex provider) but nothing beyond that, such as return shape or caching behavior, which is acceptable for a trivial probe.

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

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

A single front-loaded sentence that states verb and object with zero waste. Nothing redundant 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 no-parameter, read-only probe with no output schema, the description is adequate: it names the exact entity being checked. It stops short of hinting at the return value (e.g. installed/not-installed or version), which would have made it fully self-contained.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing additional for the description to document here.

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

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

States a specific verb (Read) and a well-scoped resource (whether the Codex provider is installed). The name pair codex_status/codex_install in the sibling list makes the read-vs-install distinction inferable, though the description itself does not call out the sibling.

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

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

Usage is only implied: an agent infers this is called to check whether the Codex provider exists before installing or using it. There is no explicit when-to-use, no named alternative like codex_install, and no prerequisite stated.

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

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

Annotations already cover the read-only, non-destructive safety profile, so the description's added value is elsewhere: it discloses that the Worker profile is returned redacted and that NATIVE indicates a dormant Delegation Worker. Both are behavioral facts an agent cannot derive from the annotations or the empty 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?

Two short sentences, front-loaded with the return contents and closing with the one state semantic that needs decoding. No filler or restatement of the tool name.

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 carries the burden of telling the agent what comes back, and it lists the four returned facets plus the NATIVE semantics. It stops short of describing the shape of the response, but for a parameterless status read this is close to complete.

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

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

The tool takes no parameters (empty object schema), so the baseline of 4 applies; there are no argument semantics the description could or should add.

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 ('Read') and enumerates the four resources it surfaces: session mode, Worker profile, active Worker progress, and Codex connection status. That is more than a tautology and tells an agent this is an aggregate status read. It does not, however, distinguish itself from sibling single-purpose readers like session_mode_get, worker_status, or codex_status, which appear to overlap.

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 never says when to prefer this combined reader over session_mode_get, worker_status, or codex_status, nor when not to use it. The only interpretive guidance offered is the meaning of the NATIVE value, which explains a return state rather than a usage condition.

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

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

Annotations only declare readOnlyHint=false, so the description carries most of the behavioral burden. It usefully discloses that the deletion cascades to the encrypted credential reference, which is not derivable from the schema. However, it omits irreversibility, confirmation requirements, or any error/partial-failure behavior for a destructive operation.

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

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

One short sentence that front-loads the verb and the resource, with zero filler. Nothing is wasted.

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

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

For a single-parameter destructive tool with no output schema, the description covers the essential scope (what is removed) but leaves out irreversibility and any side effects on dependent workers or sessions. Adequate but with clear gaps for a delete operation.

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

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

Schema description coverage is 0% for the single 'id' parameter, so the description must compensate and it does not. It never states whose id this is (provider id vs credential id) or the accepted format, despite the 3-80 character constraint implying a specific identifier shape.

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

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

States a specific verb ('Delete') and resource ('a provider profile and its encrypted credential reference'), which clearly separates it from siblings like provider_save, provider_refresh and provider_probe. It does not explicitly name an alternative, but the action is unambiguous.

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

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

There is no guidance on when to use this tool versus provider_save or provider_model_override, and no stated prerequisites (e.g., whether the provider must first be disabled or unreferenced). The agent must infer usage entirely from the verb.

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

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

Annotations only state readOnlyHint=false, so the description does useful work by disclosing that the operation stamps provenance as 'operator_override' — a durable, auditable side effect an agent should know about. It still omits what exactly is mutated (capability flags? model metadata?), whether the override persists or is per-call, and any permission or auth requirement expected of an 'operator'.

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

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

Two compact sentences with the purpose stated first and no filler or repetition. It is tight, but the brevity comes partly at the cost of substance rather than being purely efficient.

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

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

For a mutating tool with zero annotation coverage beyond readOnlyHint=false, no output schema, and an undocumented nested 'override' object, the description is far too thin. An agent cannot determine the override's accepted fields, the effect on subsequent model calls, or how to recover/undo it.

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

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

Schema description coverage is 0% for 3 parameters, and the description supplies no parameter information at all. Most critically, the 'override' object — the actual payload of the tool — has no documented shape or expected fields, and providerId/modelId are never explained, so an agent has no basis for constructing a valid call.

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

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

The description conveys that this is an operator-level override affecting reasoning capability, which is more than a restatement of the name, but it never states a clean verb+resource (e.g. 'sets the reasoning capability override for a provider model') and never distinguishes itself from siblings like provider_save or provider_probe. An agent can guess the domain but not the exact effect.

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?

'when upstream metadata is absent' is a genuine, if narrow, usage condition, and 'Advanced operator' signals this is not a routine path. However, no alternative tool is named for the normal case (presumably provider_save/provider_refresh), and no explicit when-not or precedence guidance is given, so the routing is left implicit.

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 destructiveHint=false, so the safety profile is covered. The description adds that this is a compatibility check on a configured provider/model, but it does not disclose whether the probe performs live network requests, its latency/cost, or how to interpret a positive versus negative result.

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

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

A single tight sentence with the verb and the decision criteria front-loaded. It wastes no words, though the extreme brevity is arguably the source of the definition's gaps.

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 diagnostic with no output schema, an agent would benefit from knowing what the probe returns or when to reach for it over provider_refresh. The description conveys the purpose but leaves the parameter meanings and result interpretation 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% for two parameters, so the description must compensate and does not. It alludes to a "provider/model" pairing but never explains that `id` identifies the provider (required) while `modelId` optionally narrows the probe to a specific model.

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 ("Probe") and resource ("configured provider/model") and states exactly what it determines — whether the endpoint accepts Responses or requires Chat Completions compatibility. It is clear on its own, though it does not explicitly contrast itself with siblings such as provider_refresh or provider_model_override.

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, and no alternative tool is named. The diagnostic intent is only implied by the verb "Probe" rather than stated as a condition for selection.

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

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

Annotations declare readOnlyHint=true, meaning this is a safe operation with no side effects visible to the caller. The description adds 'refresh one provider model catalog and explicit reasoning metadata' but doesn't explain what refreshing does, whether it mutates cached data, or what triggers it. With annotations already covering safety, the description adds little beyond a restatement of intent.

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

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

The description is a single efficient sentence with no filler, front-loading the action. It is appropriately sized for a simple tool, though the phrase 'explicit reasoning metadata' could be seen as slightly opaque.

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

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

The tool lacks an output schema and annotations only cover safety, so the description must carry more weight. It fails to explain what a refresh entails, whether it returns anything, how id is used, or how it differs from provider_probe and provider_model_override. This leaves significant gaps for an agent to call it correctly.

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

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

Schema coverage is 0%, so the single string parameter 'id' is undocumented in both schema and description. The description doesn't clarify what the id refers to (provider id, catalog id?) or its format. However, with only one parameter, the baseline of 3 for zero-param tools does not apply; the gap is mild but present.

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 verb+resource ('Refresh... provider model catalog and explicit reasoning metadata'), which is clearer than the bare name. However, it doesn't distinguish this from siblings like provider_probe or provider_model_override, leaving the agent to guess the boundary. The phrase 'explicit reasoning metadata' is jargon that doesn't clarify 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?

No when-to-use guidance is provided. The description doesn't say when to refresh versus probe, save, or override, nor does it state prerequisites or expected outcomes. The agent must infer usage entirely from the name and 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 only supply readOnlyHint=false, so the description carries most of the burden. It adds real behavioral value: API keys are encrypted locally and never returned, and the call also exercises the model catalog (an outbound side effect). It still omits whether the catalog test can fail the save, and permission/auth requirements.

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

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

Two compact sentences, front-loaded with the primary action and followed immediately by the security-relevant caveat. No filler or repetition of the tool name.

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, yet the description does not say what a successful save returns (provider id, catalog test results), and with 0% schema coverage the parameter-level behavior is thin. The encryption disclosure is a meaningful addition, but the definition is only narrowly sufficient for a 7-parameter mutation tool.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate and largely does not. Only 'apiKey' is indirectly referenced via the encryption sentence; the meaning of id (create vs update switch), adapter, authType, headerName, and baseUrl is left entirely to the enum/type 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 pair and resource ('Create/update a provider profile') plus a secondary action ('test its model catalog'), so the upsert semantics are clear. It does not distinguish itself from close siblings like provider_refresh or provider_probe, which also touch provider model catalogs.

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

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

There is no statement of when to choose this over provider_refresh, provider_probe, or provider_model_override, and no prerequisites or exclusions are given. The only implied guidance is the 'create/update' phrasing, which the reader must infer means upsert behavior.

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 destructiveHint=false, covering the safety profile. The description adds only that the return is the current mode; it says nothing about when the mode changes or any side conditions.

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

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

A single front-loaded sentence with no filler; every word carries information.

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

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

For a parameterless read with annotations covering safety, the description gives enough to call it correctly and even hints at the return value. Without an output schema, a little more on the returned form would help, but nothing essential 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.

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

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

The description names a specific verb ('Read') and resource ('session mode') and enumerates the exact domain values (NATIVE or WORKER). It is unmistakably distinct from the sibling session_mode_set.

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 tool's narrow scope, but the description never states when to call it versus alternatives such as session_mode_set or delegation_status. No exclusions or prerequisites are given.

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

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

Annotations only declare readOnlyHint=false, so the description adds real value by disclosing the destructive side effect: switching to NATIVE cancels active Workers for this session. It doesn't mention reversibility beyond that or permission requirements, but the key state-change consequence is surfaced.

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

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

Two tight sentences, front-loaded with the action and immediately followed by the important side effect. 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 single-enum-param mutation with no output schema, the description covers the action, the values, and the notable side effect. Missing only permission/prerequisite 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%, but the single parameter is an enum with values explicitly named in the description text (NATIVE/WORKER). That compensates reasonably, though it adds no meaning beyond the enum values themselves. Baseline for a 1-param tool.

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

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

Specific verb (Set) + resource (session mode) + enumerated values (NATIVE/WORKER), and it pairs naturally against sibling session_mode_get as setter vs getter. An agent can tell exactly what this does.

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

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

The description implies the operation is per-session and that switching to NATIVE has a side effect, but gives no explicit when-to-use guidance or when to prefer WORKER vs NATIVE. Usage is left to inference.

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

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

The readOnlyHint=false annotation already establishes this as a mutating operation, so the bar is lower. The description adds real value beyond that by declaring the effect is 'immediate' and that only workers in the current supervisor session can be targeted. It still omits what happens to in-flight work, whether the cancellation is reversible, and whether the optional reason is recorded or surfaced anywhere.

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

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

A single efficient sentence with the urgency qualifier ('Immediately') front-loaded and zero filler. It is well-formed, though its brevity is partly under-specification rather than disciplined economy.

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 zero schema description coverage, no output schema, and only readOnlyHint as an annotation, the description is too thin. It says nothing about what state the worker is left in, whether partial results survive, permission requirements, or the role of the reason parameter.

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 for two parameters, yet it never mentions taskId or reason. 'An active Worker' loosely gestures at taskId, but the optional 500-character reason and its effect are entirely unexplained, leaving the agent to infer both from names alone.

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 pair ('interrupt and cancel') and a scoped resource ('an active Worker owned by the current supervisor session'), which clearly separates it from non-terminating siblings like worker_status or worker_wait. It stops short of naming which sibling to use instead when the goal is correction rather than termination, so it is clear but not explicitly 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?

Usage is only implied: the words 'active Worker' and 'owned by the current supervisor session' communicate the precondition that the target must be running and owned by the caller. There is no statement of when not to cancel, no alternative such as worker_steer for course-correction, and no guidance on the optional 'reason' field.

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 destructiveHint=false, so safety is covered; the description adds genuinely new context by guaranteeing secrets are never returned and by scoping what is read (configured vs. discovered). It does not, however, explain whether reading triggers a live discovery or what the refresh flag changes behaviorally.

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

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

Two short sentences with zero filler; the resource list is front-loaded and the security guarantee is placed last for emphasis. Nothing could be cut without losing information.

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

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

With no output schema, the description does describe the returned content (providers, models, reasoning controls) and excludes secrets, which is helpful. But the unexplained 'refresh' parameter and the absence of any note on caching/discovery freshness leave a meaningful hole for a catalog tool.

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

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

The single parameter 'refresh' has no description in the schema (0% coverage) and is not mentioned at all in the description. For a tool whose sibling provider_refresh implies a re-discovery concept, leaving the only parameter's semantics undocumented is a real 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 (Read) plus three concrete resources: configured providers, discovered models, and per-model reasoning controls. Compared with mutation siblings like provider_save, provider_delete, and provider_refresh, an agent can tell this is the read-only catalog accessor 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?

Usage is implied by the 'Read' framing and the presence of write/discovery siblings (provider_save, provider_probe, provider_refresh), but the description never says when to choose this over provider_probe or provider_refresh, nor any prerequisites. Adequate but leaves the agent to infer 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 readOnlyHint=false, confirming this is a write. The description adds meaningful context: renewal is bounded by an operator-configured hard runtime limit, and automatic renewal is enabled by default (implying a reason to do this manually). However it doesn't disclose failure modes, whether extraMs can exceed the hard limit, or what happens on rejection.

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

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

Two short sentences, front-loaded with the action. No waste.

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

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

Given a write operation with no output schema and 0% parameter coverage, the description should do more: explain extraMs semantics relative to the hard limit, what happens when the limit is hit, and when manual renewal is warranted. The hard-limit context helps but the param coverage gap leaves the agent under-informed.

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

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

Schema coverage is 0% and the description mentions no parameters. The three parameters (taskId, reason, extraMs) have no meaning added by the description beyond their names. With low coverage, the description should compensate; it does not.

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

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

States a specific verb+resource: 'Manually renew an active Worker lease.' Clear what it does, though it doesn't sharply distinguish from siblings like worker_steer or worker_wait which might also touch lease timing.

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?

Implies manual usage ('Manually renew') versus default automatic renewal, which gives some context. But no explicit when-to-use, no conditions for choosing this over waiting for automatic renewal or other alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and opening a panel is consistent with that. The description adds that the panel targets the current host session and that this surfaces an interactive control UI, but says nothing about whether it blocks, what it renders, or side effects.

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

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

A single front-loaded sentence with no filler; the scope qualifier ('current host session') is included without 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?

With no parameters and no output schema, the description is the only explanation an agent gets, and it does not indicate what the panel shows or what opening it accomplishes relative to the many worker_* status tools.

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

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

The tool takes zero parameters and the schema is fully described, so there is no parameter semantics burden on the description. Baseline 4 applies.

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

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

States a specific verb (Open) and a specific resource (Delegation Worker control panel) scoped to the current host session. This distinguishes it from action siblings like worker_start or worker_steer, though it never explicitly contrasts itself with 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as worker_status or session_mode_get for inspecting worker state. Usage is only weakly implied by 'control panel'.

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 destructiveHint=false, so safety is covered. The description adds useful scoping context: the settings are operator-selected and scoped to the current session, implying no arguments and a snapshot read. It says nothing about whether values can be stale, unset, or how they are refreshed, so it adds only modest context.

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

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

A single front-loaded sentence with no redundant content, scoping the read to the current session immediately.

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

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

For a zero-parameter read-only tool with annotations and no output schema, the description is largely sufficient and enumerates the categories of settings returned. It could briefly note what happens when no Worker profile is active, but no essential calling information 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?

The tool takes zero parameters, so there is no parameter meaning for the description to carry; baseline for a parameterless tool is 4.

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

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

States a concrete verb ('Read') and enumerates the resource contents (Worker model, reasoning, access and supervision settings), which is specific enough to distinguish it from write siblings like worker_profile_set. It does not explicitly contrast itself with the adjacent read sibling session_mode_get, 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?

The description gives no when/when-not guidance, prerequisites, or alternatives. It never clarifies how it relates to session_mode_get or worker_status, which also read session state.

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 only annotation is readOnlyHint=false, confirming a write, and the description adds session-scoped persistence — a small but real increment. Beyond that it says nothing about validation failures, whether changes apply to an already-running worker, required combinations of provider/model, or the effect of the optional lease/extend fields, which is a notable gap for an 8-parameter mutation tool.

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

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

A single well-formed sentence with the verb and scope front-loaded and no filler. It is appropriately terse, though the brevity is partly a symptom of under-specification rather than deliberate economy.

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 with 8 parameters, 0% schema coverage, no output schema, and only a single annotation, the description is far too thin. Nothing explains the semantics of the unrequired fields or the consequence of calling this before versus after worker_start.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It names only four of eight fields (provider, model, reasoning, access) and adds no constraints, units, defaults, or value formats; leaseMs, maxTotalMs, autoExtend, and autoVerify are entirely undocumented anywhere.

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

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

Specific verb ('Save') plus a concrete resource ('Worker provider/model/reasoning/access settings') and a scope qualifier ('for the current session'). It does not explicitly name the counterpart worker_profile_get or any other sibling, so sibling routing is left to the name alone.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternative (e.g., worker_profile_get, worker_start, session_mode_set) is referenced. 'Human-selected' hints the values come from a UI flow, but the description never states prerequisites or timing relative to spawning a worker.

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

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

Annotations only declare readOnlyHint=false, so the description must carry the rest. It adds the meaningful requirement that the requestId be the exact pending one and that the response match what the request expects, plus an implied reject path with reason. It omits permissions, whether responding is irreversible, and what happens to the worker afterwards.

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

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

Two tight sentences with the action front-loaded and the prerequisite immediately after. No filler, though the second sentence bundles two constraints that could have been crisper.

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 five-parameter mutation tool with a nested object parameter and no output schema, the description covers the essentials of the call but leaves taskId/reason semantics and the expected response shape to be inferred. Adequate but not complete.

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

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

Schema coverage is 0% across 5 parameters, so the description has to compensate. It explains requestId (the exact pending value) and response (the request-specific object), but says nothing about taskId, reject, or reason semantics, leaving three parameters entirely undocumented.

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

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

Names a specific action on a specific resource ('answer or reject a pending official Codex server request') and ties it to a named sibling, worker_status, which is where such requests surface. It is clearly distinguishable from steering, waiting, or cancelling a worker.

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?

States the triggering condition ('surfaced by worker_status') and a key usage constraint ('Pass the exact pending requestId'), which tells the agent when this tool applies. It does not say what to do when no request is pending or contrast with alternatives, so it stops short of a 5.

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

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

Annotations give readOnlyHint=false, so the mutating nature is already declared. The description adds real context by stating the worker is 'operator-configured' and that provider/model/access/renewal are deliberately not arguments. It does not disclose auth requirements, side effects of starting (resource consumption, session state), or what happens if a worker is already running.

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

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

Two tightly written sentences with the core action front-loaded and no filler. The second sentence is slightly dense but earns its place by preventing misuse of non-arguments.

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

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

For a state-mutating lifecycle tool with no output schema and 0% schema description coverage, the description is thin: it neither explains the parameters nor what starting returns or guarantees. An agent knows roughly why to call it but not how to populate the required 'task' 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% for both parameters, and the description compensates only by telling the agent what is NOT an argument. Neither 'task' (the required payload) nor 'cwd' is explained, leaving the most important parameter undocumented.

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

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

States a specific verb+resource and scope: 'Start the operator-configured Worker for this session.' This separates it from sibling lifecycle tools like worker_steer/worker_cancel/worker_wait. It does not, however, explicitly name which sibling to use instead or contrast its lifecycle position.

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 action (start a worker), and the description usefully rules out passing provider/model/renewal config, telling the agent these are owned by the human Worker panel. There is no explicit 'use this when/when not' or reference to alternatives such as worker_steer for an already-running worker.

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 destructiveHint=false, so the safety profile is covered externally. The description adds value by disclosing what the read surfaces (heartbeat/progress evidence, lease, pending Codex interaction, verifier, result), but says nothing about permissions, staleness, or freshness of the returned status.

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

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

One dense, front-loaded sentence with no wasted words, and the enumeration of returned fields is a good use of limited space given there is no output schema. Slight length in the field list but every item is informative.

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

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

For a one-parameter read tool with no output schema, spelling out the returned contents is the right instinct and largely covers the response side. It is still incomplete on the input side (taskId provenance) and on routing versus sibling status tools.

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

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

The single taskId parameter has 0% schema description coverage, so the schema does not explain its format or where it comes from. The description does not compensate at all - it never mentions taskId, how to obtain it, or any identifier syntax, leaving the required parameter undocumented.

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

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

States a specific verb+resource ('Read a Worker task') and enumerates the contents of that read (phase, plan, latest action, heartbeat, lease, pending Codex interaction, verifier, result). It does not explicitly differentiate itself from siblings like worker_panel or delegation_status, so it stops short of a 5.

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

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

There is no when-to-use guidance, no named alternative, and no exclusions. An agent cannot tell from this text whether it should call worker_status, worker_panel, or delegation_status to inspect worker state; only the required taskId hints that this is single-task inspection.

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

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

Annotations only declare readOnlyHint=false, so the description must carry the rest and does not: it never says whether steering is queued or synchronous, whether it interrupts an in-flight turn, or what the error state is for an inactive worker. 'Official Codex turn/steer' hints at the underlying mechanism but describes no observable behavior.

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

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

A single front-loaded sentence with no filler, and the key constraint ('active Worker') appears early. It is efficient, though the 'official Codex turn/steer' clause is jargon that consumes space without adding actionable meaning.

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

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

For a two-parameter mutation tool with no output schema and minimal annotations, the description should explain the identifier, the direction payload, and the outcome of a successful or failed steer. None of these are covered, leaving the agent unable to predict the call's effects.

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 both parameters are merely constrained by length, so the description is the only source of meaning. It gestures at 'direction' as the steering payload but never explains what taskId identifies or how direction is consumed (free text? instruction? structured?).

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 ('Give an active Worker a precise direction change') and names the underlying mechanism (Codex turn/steer). It is clearly distinct from sibling reads like worker_status, though it doesn't explicitly differentiate itself from the closest sibling, worker_respond.

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 qualifier 'active Worker' implies a precondition, so the agent can infer that the worker must already be running. However, there is no explicit when-to-use guidance, no statement of what happens if the worker is not active, and no routing to worker_respond, worker_extend, or worker_start as alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description usefully adds that the wait is bounded/time-limited, but it does not say what is returned or what happens when the window elapses without the task finishing.

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

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

A single front-loaded sentence with no filler; the termination condition is stated economically rather than 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 tool with two undocumented parameters, no output schema, and no param descriptions, the definition is too thin: neither the waitMs units/limits nor the post-timeout return state are explained, so an agent cannot fully reason about its 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 carries the full burden. It alludes to a task and a 'bounded wait window' but never documents that waitMs is milliseconds, its 0-170000 range, or the behavior/default when waitMs is omitted, leaving the timeout semantics ambiguous.

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 (wait) and resource (Worker task) plus the termination condition (task finishes or wait window elapses). It is clear what the tool does, but it never names the obvious alternative (worker_status) to differentiate a blocking wait from a poll.

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?

'Until the bounded wait window elapses' implies this is a blocking call as opposed to an immediate status poll, so the usage context is inferable. However, no explicit when-to-use versus worker_status/worker_panel or any prerequisite is stated.

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