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

With no annotations, the description carries the full burden of disclosure. It usefully flags that the copy strategy is destructive and CLI-only, but for a mutation tool it omits critical behavior: what happens to the worktree after applying, how merge conflicts surface, and whether the operation is reversible.

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 core action and followed by the one constraint that matters. The reStructuredText double-backtick markup is slightly noisy but not wasteful, and nothing is repeated.

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

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

An output schema exists, so return values need not be described. Still, for a no-annotation mutation tool with an entirely undocumented parameter schema, the description should say more about side effects and failure modes before an agent commits to applying a patch.

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

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

Schema coverage is 0%, so the description must compensate. It does add real meaning for 'strategy' by revealing the two accepted values and excluding copy, but 'task_id' is left completely undefined in both schema and description, and the difference between patch and merge is never explained.

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 and resource: apply isolated worktree changes back into the primary workspace. That distinguishes it from siblings like dispatch_task and cancel_task without needing to name them. It stops short of a 5 because it never explicitly contrasts itself with any sibling tool.

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

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

It constrains the strategy argument by stating only patch and merge are available over MCP, which tells the agent what not to pass. However, it never states the precondition for calling it (for example, that a task must have completed with worktree changes) or what to use instead when the conditions aren't met.

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 zero annotations, the description carries the full burden, and it does disclose one valuable effect: the worktree is retained for inspection, implying it is not deleted. It says nothing about whether cancellation is reversible, whether partial work is discarded, what permissions or auth are needed, or whether the call waits for termination.

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

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

Two short sentences, zero filler, with the effective scope front-loaded and the side effect second. Nothing could be removed 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?

An output schema exists, so the description needn't explain return values, and the core action plus the retained-worktree behavior is covered. The remaining gap is that this is an unannotated state-mutating tool whose parameters, idempotency, and permission requirements go unexplained.

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

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

Schema description coverage is 0% and the single parameter task_id is never mentioned in the description, so the agent gets no meaning beyond the bare property name and string type. Since the schema does no work here, the description should have identified what identifier is expected and where to obtain it.

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 plus resource ("Cancel a running or waiting ticket") and even narrows the applicable states, so the action is unambiguous. It loses a point for calling the resource a "ticket" when the tool and sibling names use "task", and for not distinguishing itself from nearby siblings like get_task_status or dispatch_task.

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

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

The phrase "running or waiting" implicitly tells the agent which task states are eligible for cancellation, which is real usage guidance. However, there is no statement of when not to cancel, whether a stopped/completed task can be passed, or which sibling to use instead for inspecting status before cancelling.

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 no annotations, the description carries the full burden and discloses almost nothing: whether discovery hits remote providers, how long it takes, whether it mutates cached state, or what happens on failure is unstated. The word 'waterfall' hints at a fallback chain but the layers and their consequences are never explained.

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 no filler and the scope constraint placed up front. It is efficient, though efficiency here reflects under-specification rather than tight writing.

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

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

An output schema exists, so return values need not be described, but with zero parameter documentation, no annotations, and an opaque 'three-layer waterfall' concept, this one-liner leaves an agent unable to predict cost, latency, side effects, or the role of force_refresh.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify that the harness parameter is optional ('one or all harnesses'), covering roughly one of two parameters, but force_refresh is never mentioned — including its default of true, which means every call refreshes unless the agent knows to override it.

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 verb-plus-resource ('model discovery' for 'harnesses') is identifiable, and the scope ('one or all harnesses') is stated. However, 'three-layer model discovery waterfall' is unexplained jargon, so an agent cannot tell what actually happens or what the result represents, and no sibling (list_harnesses, get_model_market) is distinguished.

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 call this versus list_harnesses, get_model_market, or preview_routing, which plausibly overlap in the model/harness domain. Nothing says when a discovery run is warranted or what condition should prompt a refresh.

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 no annotations, the description carries the full load, and it does disclose one genuinely valuable behavior: quota exhaustion spawns a new Assignment on another harness and resumes in the same worktree. It is silent on other significant traits an agent needs, notably whether dispatch is asynchronous (returning a task id), that a worktree is created and uncommitted changes may be synced, and any cost or timeout implications across the 29-parameter surface.

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 the essential constraint (only objective required) is front-loaded immediately after the purpose statement. The stray line breaks are cosmetic; no sentence is wasted, though the space devoted to four parameters rather than the riskiest ones is a mild misallocation.

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 output schema excuse applies to return values, but for a 29-parameter dispatch tool with zero annotation and zero schema description coverage, the description is far too thin. It omits the lifecycle model (async vs blocking), workspace creation side effects, and the meaning of the majority of arguments, so an agent must guess on most of the call surface.

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 is bare and explanation must come from<|place_holder_mm_span_0442|> text. The description covers only objective, target_harness, model, and task_kind out of 29 parameters. Opaque fields such as checkpoint, trace_chain, call_depth, min_intelligence, routing_mode, on_quota_exhausted, and auto_record_context receive no semantics, leaving most of the parameter surface undefined for the agent.

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

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

The description opens with a specific verb+resource, 'Dispatch a ticket,' which makes the core action unambiguous. It does not differentiate this tool from siblings such as parallel_dispatch or preview_routing, and the word 'ticket' is inconsistent with the tool/resource name 'task', but an agent can still tell broadly what the tool 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?

It gives fill-in guidance for defaults ('Leave target_harness at "auto" and model unset', 'pass task_kind when it is known') and states that only objective is required, which is useful. However, there is no when-to-use-this-vs-alternatives guidance at all, so the agent must infer that dispatch_task is the single-task path and parallel_dispatch the multi-task path.

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?

No annotations are supplied, so the description carries the full burden, and it does meaningful work: 'Read-only: detection never writes' explicitly declares the safety profile, and the enumerated state vocabulary ('integrated', 'detected_not_integrated', 'stale', 'not_detected', 'ignored') tells the agent what the operation can conclude. It does not say whether detection triggers a fresh probe or returns cached state, which is exactly what 'stale' implies an agent might want to know.

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

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

Two sentences, front-loaded with the purpose, then the state vocabulary. No filler. Minor deduction for the leftover RST literal markup (double backticks) and the escaped quoting artifacts, which add noise without meaning.

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

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

An output schema exists, so the description need not explain return values, and with zero parameters there is little surface area to cover. What remains missing is the operational follow-through — what a given state implies the agent should do next — but the definition is otherwise sufficient to call the tool correctly.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to disambiguate beyond the implicit scope of 'each installed harness', which the schema cannot express.

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

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

The description opens with a specific verb and resource: 'Report whether each installed harness can reach Mesh as a controller.' That is concrete enough that an agent can distinguish it from list_harnesses (which enumerates harnesses) and install_integration (which mutates). It stops short of naming a sibling explicitly, so it lands at 4 rather than 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?

Usage is implied rather than stated: an agent infers this is the diagnostic to run when it needs to know whether a harness is wired up. There is no explicit 'use this when X, use install_integration when Y', and no statement of prerequisites or what to do with a 'stale' or 'not_detected' result. The routing to sibling tools 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?

With no annotations, the description carries the full load and does disclose the most important behavioral trait: it reads cache only, never refreshes, and performs no network request. It also explains what `intelligence_source` means (Artificial Analysis, user override, or local heuristic), which is genuine value. It stops short of describing ordering, truncation, or what happens when the cache is empty.

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

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

Three short sentences, front-loaded with the resource description followed by the two behavioral facts. Some markdown formatting noise (backticks, hard wrapping) but no filler content; every clause 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?

An output schema exists, so return values need not be explained, and the staleness/network behavior is well covered. The gap is on the input side: for a searchable listing tool with an undocumented `query` and `limit`, an agent lacks enough to call it confidently, and there is no mention of what the cache does not contain.

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 two parameters (`limit`, `query`) are undocumented in both schema and description. The description never explains what `query` matches (model name? provider? fuzzy or exact?) or how `limit` interacts with results, leaving the agent to guess at the primary filtering controls.

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

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

States a specific verb and resource set: reading cached model prices, context windows, and intelligence scores. It is clear enough to distinguish from siblings like discover_harness_models or preview_routing, though it never explicitly names an alternative or explains how it differs from live model discovery.

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 'cached' framing and the explicit statement that the tool never refreshes and never makes a network request, which tells an agent this is a stale-data read. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternative for getting fresh prices, so the agent must infer the routing decision.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation by saying 'Read', but does not explain scope, permissions, whether instruction files are included by default, or how the cross-harness memory is aggregated.

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

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

The definition is a single front-loaded sentence with no filler. Its brevity is efficient, though it borders on under-specification rather than being genuinely concise.

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

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

The output schema exists, so return values need not be explained in the description. However, with no annotations and no parameter descriptions, the description is too thin to fully prepare an agent to call this tool correctly, especially regarding the category filter and default instruction 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 needs to compensate for undocumented parameters. It only vaguely hints at include_instructions via 'instruction files' and says nothing about the category parameter, its valid values, or the effect of defaults.

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

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

The description uses a specific verb ('Read') and identifies the resources: project memory blackboard and instruction files. It is understandable, though the term 'cross-harness project memory blackboard' is jargon and it does not explicitly distinguish itself from the sibling tool update_project_context.

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

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

There is no guidance on when to use this tool, when not to use it, or which sibling alternatives it competes with. An agent must infer that this is the read counterpart to update_project_context from the name alone.

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

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

No annotations are supplied, so the description carries the full load, and it does disclose the critical trait: probe_now is not a passive read — it triggers recovery probes and resumes waiting tickets. That is exactly the side-effect an agent needs to know before flipping a boolean. It stops short of saying whether that action can fail, is idempotent, or requires permissions.

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 resource list front-loaded and the parameter effect immediately after. The stray double-backtick markup around probe_now is minor packaging noise rather than a comprehension problem.

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-optional-parameter read tool with an output schema, this covers what is returned and the one behavioral wrinkle of the parameter. The only meaningful gap is the lack of explicit routing guidance versus the closely named sibling report_quota_status.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter, and it does: probe_now is explained as triggering recovery probes plus resuming waiting tickets. The default of false is visible in the schema, but the description doesn't note that omitting the flag leaves the queue untouched.

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 concrete verb ("Show") and names both resources it surfaces: quota circuits and the waiting_for_quota queue. That is clear enough to distinguish it from a status-writing sibling like report_quota_status, though the description never makes that contrast explicit.

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

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

Usage is only implied: an agent can infer this is the diagnostic view for quota circuits and stuck tickets, and that probe_now is the nudge to unstick them. There is no explicit statement of when to call this versus report_quota_status or get_integration_status, and no warning about when probe_now should be avoided.

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?

No annotations are supplied, so the description carries the full behavioral burden. It never states that this is a non-mutating read, what happens for an unknown or already-completed task_id, whether the assignment history is bounded or paginated, 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?

One short, front-loaded sentence with no filler; the returned payload is stated first. It is arguably under-specified rather than verbose, but nothing in it is wasted.

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

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

An output schema exists, so the description needn't enumerate return fields, and for a single-parameter read tool the scope is roughly adequate. Still missing is the task_id meaning and any indication of error or empty-result behavior, which matters for a status lookup that could silently return nothing.

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 has 0% schema description coverage, so the description must explain task_id but says nothing about it — not whether it is the dispatcher's task ID, whether it accepts a ticket key, or what format is expected. The reference to 'ticket status' actually muddies the parameter's meaning.

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 ('Return') and a concrete payload ('ticket status plus every assignment and failover hop'), which tells an agent this is a status/history read rather than a resource read like read_task_resource. However, it calls the entity a 'ticket' while the tool and its parameter are named 'task', introducing a terminology mismatch that weakens precision.

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 choose this over the many sibling read tools (read_task_resource, get_quota_status, get_integration_status) or over dispatching/cancelling. The agent must infer usage purely from the name and the one-line payload summary.

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 no annotations at all, the description carries the full burden and does well: it declares the operation is a write, names the refusal conditions (read-only mode, worker context, stale plan hash), and states the post-condition that the harness must restart before tools appear. It does not address reversibility of the install or what a partial failure leaves behind, which keeps 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?

Four short sentences: purpose first, then safety/refusal behavior, then the operational post-condition. No redundant restatement of the tool name and no filler.

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

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

For a write tool with zero annotation coverage, the description covers the critical risks (authorization mode, worker refusal, plan staleness, restart requirement), and return values are covered by the existing output schema. The one real hole is `approve_level`, undocumented in both the schema and the description.

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 contributes no meaning. The description clarifies `harness` (the target that must restart) and `plan_id` (must match a freshly computed plan), but says nothing about `approve_level`, a parameter with a non-obvious default of "dispatch" whose accepted values an agent cannot guess.

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

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

The description gives a specific verb and resource ("Install one harness") plus a precondition ("after the user approved the reviewed plan"), which implicitly contrasts with the sibling plan_integration. It stops short of naming the sibling tool or stating that only one harness per call is installed, so differentiation is inferred rather than spelled out.

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

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

It states the triggering condition clearly (user approval of the reviewed plan) and lists three when-not conditions: worker contexts, HARNESS_MESH_READ_ONLY=1, and a plan_id that no longer matches a freshly computed plan. It never explicitly points at plan_integration as the required preceding step, leaving the workflow link 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?

No annotations are supplied, so the description carries the full behavioral burden. It signals that results are local, yet the presence of a refresh_models flag implies an outbound discovery/authorisation call whose cost, permissions, or side effects are never disclosed. Nothing is said about whether the quota/tier data is cached or live.

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 resource is stated first. It is arguably over-dense in that four distinct data categories are crammed into one clause, 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?

An output schema exists, so return-value shape needn't be restated, and the description correctly avoids it. What is missing is the refresh_models behavior and any routing hint against the many overlapping siblings — meaningful but bounded gaps.

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

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

Schema description coverage is 0%, so the lone boolean refresh_models has no documented meaning anywhere. The description mentions "discovered authorised models" but never connects discovery to the flag, leaving the agent unable to judge when to set it or what changes if it does.

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

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

The description uses a specific verb ("List") with a named resource ("harnesses") and enumerates the payload contents: discovered authorised models, tier bindings, and quota state. An agent knows what comes back. It stops short of differentiating from siblings such as discover_harness_models or get_quota_status, which overlap on the listed contents.

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?

"Locally available" implies a cheap offline inventory versus the discovery-oriented sibling, but this is inference rather than stated guidance. There is no when-to-use, when-not-to-use, or named alternative (e.g. discover_harness_models, get_quota_status), so an agent has to guess which of the overlapping tools to call.

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

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

With no annotations at all, the description carries the full burden of behavioral disclosure and falls short. It hints at an index ("indexed") but does not say whether results are ranked, whether an empty query lists everything, how many results come back, or whether the operation is read-only in any sense beyond the verb.

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 with no filler, and the resource scope is front-loaded. Its terseness is efficient rather than padded, though it borders on being too short to be actionable.

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 presence of an output schema excuses not documenting return values, but the definition still omits when to call it, what the query does, and how the index behaves. For a zero-annotation, zero-schema-coverage search tool, that leaves meaningful gaps.

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

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

The single `query` parameter has 0% schema description coverage (only a string type and an empty-string default), and the description never mentions it. It therefore does not clarify whether an empty default means "list all" or "no results", nor whether matching is substring, keyword, or semantic over the indexed content.

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 ("Search") and concrete resources ("indexed SKILL.md files and MCP/plugin manifests"), which is enough to separate it from the harness/model/task siblings. The one weakness is the mismatch with the tool name "list_skills_and_plugins", so an agent cannot tell from the name alone whether this enumerates or searches.

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 when not to use it, and no named alternative. The description never explains the relationship to discovery siblings such as discover_harness_models or get_integration_status, so the agent must infer the choice from resource vocabulary.

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?

No annotations are provided, so the description carries the full behavioral burden. It mentions concurrency and that task fields mirror dispatch_task, but it does not explain max_concurrency behavior, partial-failure semantics, ordering, rate limits, permissions, or what happens when some dispatches fail.

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, front-loaded with the core action, and contains no filler. The second sentence efficiently routes the reader to dispatch_task for the task schema.

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

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

An output schema exists, so return values need not be explained. However, for a concurrent dispatch tool with no annotations and no schema descriptions, the definition still leaves important operational details unstated, especially max_concurrency semantics and 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 add parameter meaning. It helpfully names task fields such as task_kind, routing_mode, max_price_per_mtok and min_intelligence, and notes target_harness defaults to auto, but it completely omits the max_concurrency parameter and does not clarify task object requirements.

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: 'Dispatch multiple tickets concurrently.' It distinguishes the tool from the single-task sibling dispatch_task by emphasizing multiple concurrent tickets, so an agent can tell them apart 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 'multiple tickets concurrently' and by the reference to dispatch_task fields, but there is no explicit guidance on when to use this instead of calling dispatch_task repeatedly, and 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?

With no annotations, the description carries the full burden and does well: it discloses that no write occurs, that a plan_id is produced, and that harness must be an already-enabled configured name — a real precondition an agent would otherwise miss. It omits plan lifetime/expiry, whether the plan is deterministic, and what happens if the config changes between plan and install.

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 core behavior and the no-write guarantee, then the preconditions and consent requirement. Nothing is padded; the only noise is the RST-style double backticks, which are cosmetic.

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

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

An output schema exists, so return-shape explanation is unnecessary, and the description covers the dry-run semantics, harness precondition, and consent workflow. The main remaining gap is the semantic meaning of approve_level values, which matters for a planning tool whose output depends on that choice.

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 largely does: it enumerates the legal approve_level values (read, dispatch, all, none) which the schema leaves as a bare string with only a default. It still does not explain what each level actually authorizes, which is the meaning an agent most needs.

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

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

The first sentence states a specific verb and resource ('Return the exact installation plan and plan_id') plus a crucial scope qualifier ('without writing'). That qualifier cleanly separates it from the sibling install_integration, so an agent can pick correctly 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 gives an explicit workflow: show the plan to the user and obtain consent before calling install_integration. That is clear when-to-use guidance tied to a named alternative. It does not address edge cases such as re-planning after a failed install or whether a plan can be reused, 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?

With no annotations, the description carries the full burden; it does disclose the most important behavioral fact, that nothing is dispatched, which signals a safe read-only preview. It says nothing about whether the preview calls any external provider, the cost/latency of previewing, or any prerequisites, so it is not fully transparent.

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 front-loaded sentence with no filler, and the scope qualifier ('without dispatching') is placed where it will be read. It is efficient, though the terseness leaves no room for any parameter cue.

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

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

An output schema exists, so return values need not be explained here. But a four-parameter tool with zero schema descriptions and three 'auto'-defaulted routing knobs is not adequately covered by a single sentence; the agent cannot tell what the optional parameters do or how they shape the preview.

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 four parameters, and the description never mentions a single one. The meanings of task_kind, difficulty, and target_harness, and what their 'auto' default does, are entirely undocumented in both the schema and the description.

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

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

The description gives a specific verb ('Preview'), resource ('the routing decision'), and input ('for an objective'), and the phrase 'without dispatching it' implicitly marks the difference from dispatch_task. It stops short of naming a sibling explicitly, so the differentiation is inferable rather than stated.

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?

'without dispatching it' implies a dry-run/inspection use case before real dispatch, which is genuine usage context. However, there is no explicit when-to-use or when-not-to-use rule, and no sibling is named (dispatch_task, parallel_dispatch, discover_harness_models) to route the agent elsewhere.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses only one trait, paging to conserve context, and says nothing about read-only safety, whether content is truncated or lossy, what happens at the end of a payload, or what error conditions exist for an invalid resource or task_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?

A single tight sentence with no filler, and the rationale (protecting the context window) is front-loaded alongside the action. It is under-specified rather than verbose, so the only cost is that nothing follows the one sentence.

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

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

For a 4-parameter paginated read tool with zero annotation and zero schema-description coverage, the definition leaves too much implicit: it never mentions task_id, does not explain how limit and offset interact, and gives no hint of how this relates to the sibling tools that produce or inspect tasks. The existing output schema offsets the need to describe return values, but not the missing call semantics.

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 'resource' parameter has no enum, so the description's enumeration of diff/transcript/assignments is genuinely the only documentation of valid values. Beyond that, task_id, limit, and offset are left untouched, with only the phrase 'Page through' hinting at offset/limit semantics and no indication of what units limit uses.

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 ('Page through') and enumerates the payload types it reads (diff/transcript/assignments), which maps onto the 'resource' parameter. It is clear enough to distinguish the operation from sibling task tools like get_task_status or dispatch_task, though 'payload' is vague about where the content comes from.

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 'to protect the controller context window' implicitly states the condition for use: call this when a payload is too large to read at once. However, no alternative is named (e.g., when to use this instead of preview/status tools), and there is no guidance on when a full read is acceptable or on typical paging strategy.

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?

No annotations are provided, so the description carries the full behavioral burden for what is clearly a state mutation. It does not say what a reset actually does (clear cooldown? re-enable traffic?), whether the change is reversible, what 'open' versus 'half_open' mean operationally, or what side effects a manual override has. Only the action vocabulary is disclosed, not the consequences.

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 action list parenthesized at the end. It is efficient, though the brevity reflects under-specification rather than tight editing per se.

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

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

An output schema exists, so return values need not be explained, but everything else is missing: this is a mutation tool with zero annotations and zero schema description coverage, and the description never covers scope (which harness/model is affected) or the effect of the cooldown. For a four-parameter write operation, this is substantially under-described.

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 four parameters, and the schema defines no enums, so the description is the only source of meaning. It supplies the valid action values (reset, open, half_open) but never explains what each does, and leaves 'model', 'harness', and especially 'cooldown_seconds' entirely undefined despite cooldown being the key knob for a circuit 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?

The description names a specific verb and resource (reset/mark a quota circuit) and enumerates three actions, so the mutation intent is visible. However, the tool name 'report_quota_status' suggests a read/report operation, and the sibling 'get_quota_status' is the obvious read counterpart that the description never mentions. An agent must reconcile the misleading name against the description to understand this is a write 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?

'Manually' implies this is the override path versus some automatic circuit behavior, which is a faint usage cue. There is no explicit when-to-use guidance, no statement of when to prefer 'get_quota_status' instead, and no prerequisites such as required permissions or operational state needed before resetting a circuit.

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?

No annotations are provided, so the description carries the full behavioral burden. It says 'write or update' but does not disclose overwrite vs. merge semantics, whether a key collision replaces existing content, permission requirements, or conflict behavior — critical for a mutation tool with five parameters.

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 front-loaded sentence with no filler. It is concise, though its brevity comes at the cost of necessary detail rather than being efficiently informative.

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

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

An output schema exists, so return values needn't be explained. However, for a five-parameter mutation tool with zero annotation coverage and no schema descriptions, the definition omits nearly all the context an agent needs to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, yet it only vaguely gestures at 'key' and 'content'. It adds no meaning for task_id, category (default 'note'), or author_harness (default 'controller'), leaving three of five parameters completely unexplained.

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

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

The description states a specific verb-plus-resource action: 'Write or update' a 'shared project fact or interface contract'. This is clearly a mutation counterpart to the sibling get_project_context, though it doesn't explicitly name that sibling or clarify what a 'key' represents.

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

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

There is no explicit guidance on when to use this tool versus get_project_context, nor when to supply task_id, category, or author_harness. 'Shared project fact' implies project-level scope, but the description leaves all selection criteria to inference.

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