CPG-Radio

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

The description discloses idempotency, a meaningful behavioral trait, but with no annotations it carries the full burden. It omits other behavioral aspects like side effects, authentication needs, or what the acknowledgement actually does, leaving significant gaps.

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, terse sentence with no filler. It is front-loaded with the key trait (idempotent) and the action. However, the extreme brevity edges toward under-specification, so it is concise but not overly structured.

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

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

With only 2 parameters, no output schema, no annotations, and a large sibling set, the description is too sparse to let an agent determine proper usage. It lacks any context about the required-delivery mechanism or when the acknowledgement is needed.

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 50% (binding_token is described, message_id is not). The tool description adds no parameter explanation, so it fails to compensate for the undocumented message_id and adds no value beyond the schema.

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

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

The description states a clear action ('Record an idempotent required-delivery acknowledgement'), specifying a verb and resource. The qualifier 'required-delivery' gives it specificity beyond generic ack tools, but it does not explicitly differentiate from siblings like ack_messages.

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 guidance is given on when to use this tool versus alternatives such as ack_messages or ack_thread. The description lacks any context about delivery requirements, prerequisites, or conditions that would select this tool.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It reveals the key forward-only trait, that lower values are ignored, and the replay safety property: a replayed ack cannot re-deliver processed messages. This is meaningful behavioral context beyond the schema, though it does not mention response shape or potential errors.

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 two tight sentences with no filler. The primary action is front-loaded, and the important forward-only behavior is stated immediately after. Every sentence contributes useful 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 simple two-parameter ack tool with no output schema, the description covers the essential behavior and edge-case semantics. It omits return value details, but the core usage and replay behavior are sufficiently described for an agent to invoke it correctly.

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

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

Schema coverage is 50%; binding_token is described in the schema, but ack_seq is not. The description adds meaning to ack_seq by framing it as the cursor position, and the forward-only note clarifies its semantics. It does not elaborate on binding_token beyond the schema, so the description only partially compensates for the low schema coverage.

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

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

The description uses a specific verb and resource: 'Advance the calling agent's cursor to ack_seq.' This clearly identifies what the tool does and distinguishes it from sibling ack tools like ack_thread and ack_delivery, which target different resources. The forward-only note reinforces its unique role.

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

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

The description states the core operation and the forward-only constraint, implying it should be used after messages are processed. However, it does not explicitly say when to use this tool versus poll_messages or other ack-related siblings, nor does it mention any exclusions or alternative tools.

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

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

With no annotations, the description carries the behavioral burden. It discloses one meaningful trait—the operation will not hide other threads—but does not explain what happens to messages in the current thread, idempotency, ordering, or side effects. Some behavioral context, but clear gaps.

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 tightly worded sentence with no filler; the constraint 'without hiding other threads' earns its place. It is concise, though the brevity comes at the cost of omitted behavioral and parameter details.

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 3-parameter tool with no output schema and no annotations, this description is incomplete: an agent cannot determine when to use it, what ack_seq means, or what result to expect. It provides only the most basic operation and a single constraint.

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 only 33%, but the description adds no parameter-level detail. 'ack_seq' and 'thread_id' are left to be inferred from the tool's name and the phrase 'cursor', and binding_token is documented only in the schema. The description does not clarify whether ack_seq is inclusive, exclusive, required to be monotonically increasing, or what effect it has.

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 action ('Advance') on a specific resource ('per-thread subscription cursor') and includes a distinguishing qualifier ('without hiding other threads'). It is clear enough to separate from sibling ack_messages/ack_delivery, though it doesn't name 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?

The phrase 'per-thread subscription cursor' implies the tool is for advancing a cursor for one thread's subscription, but there is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives. Usage context is implied rather than stated.

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

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

No annotations are provided, so the description is the primary source of behavioral information. It discloses that the operation is atomic and version-checked, but it does not explain what happens on version mismatch, whether arrival blocks, or what side effects occur.

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 entire description is a single dense sentence with no filler. 'Atomically' is front-loaded and every remaining word adds 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 concurrency-sensitive tool with no annotations and no output schema, this description is too incomplete. It lacks failure semantics, return behavior, relationship to create_barrier, and guidance on how to obtain the expected version.

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

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

With only 33% schema description coverage, the description partially compensates by explaining that expected_version is an observed version and connecting the tool to a barrier resource. However, binding_token is not mentioned at all, leaving its purpose under-specified.

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

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

The description clearly specifies the verb ('arrive'), the resource ('barrier'), and a key condition ('using its observed version'). It is distinct from sibling create_barrier, though the term 'arrive' is domain jargon that may not be immediately obvious.

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 explicit guidance on when to use this tool versus alternatives such as create_barrier or wait_for_signal. It implies the need to have observed a version, but does not state prerequisites or exclusions.

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

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

With no annotations, the description carries the burden, and it does add meaningful behavioral context: the operation is idempotent and restricted to specific token relationships. However, it does not disclose whether cancellation is terminal, what side effects occur, or what errors or results to expect, leaving coverage partial.

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

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

Three short sentences, each earning its place: one identifies the operation, one states idempotency, and one specifies the authorization scope. There is no filler or redundancy.

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

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

A 5-parameter tool with no output schema and no annotations requires more context than this. The token-authorization note helps, but the description omits required parameter semantics, return behavior, cancellation effects, and error conditions, making reliable invocation uncertain.

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 only 20%, so the description must compensate. It clarifies spawn_token as the root authorization and child_token as an ancestor-linked token, but the required worker_id and the reason parameter remain undocumented in both schema and prose.

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 ('Cancel') and resource ('a spawned worker'), so an agent can clearly tell what the tool does. It does not explicitly distinguish it from sibling lifecycle tools such as complete_worker, but the core 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?

The description gives no guidance on when to use cancel_worker versus alternatives like complete_worker, release_task, or other worker-management tools. The idempotency note and authorization condition are useful invocation constraints, but they do not address usage 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?

With no annotations, the description must convey behavior beyond the schema. It only states the action without disclosing side effects (e.g., blocking, failure on contention), requirements (e.g., binding_token, expected_generation), or the meaning of lease_seconds. The description does not explain the return value or error scenarios, making behavior opaque.

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 that front-loads the verb and key distinguishing features. It is appropriately compact. However, given the tool's complexity (6 parameters, no output schema), the brevity is borderline; still, the structure itself is well-formed.

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

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

The tool has six parameters and no output schema, yet the description omits the purpose of most parameters, the expected return (e.g., a lease token), and the relationship to sibling lease/renew/release tools. Although sibling tool names hint at a lifecycle, the description does not tie the pieces together, leaving the definition incomplete for an agent.

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

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

Schema description coverage is only 17% (one of six parameters has a description). The description only clarifies 'mode' (shared/exclusive) but does not explain lease_seconds, expected_generation, binding_token, or resource_key. It does not compensate for the low schema coverage, leaving most parameters semantically unclear.

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 the specific verb 'Claim' with the resource type 'named resource lease' and the key dimension 'shared or exclusive'. This clearly distinguishes it from siblings like claim_task (tasks vs resources) and renew_resource/release_resource (lifecycle actions). The purpose is unambiguous.

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

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

The description gives no explicit guidance on when to use claim_resource versus alternatives. It does not mention that this is the initial acquisition step in a lease lifecycle, nor does it advise using renew_resource for extensions or release_resource for cleanup. The lack of when/when-not conditions leaves the agent to infer usage context.

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

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

With no annotations provided, the description carries the full disclosure burden. It conveys atomicity, the conditional success outcomes, and the handling of a stale lease. This goes beyond a simple 'claims' statement and gives the agent actionable behavioral details, though it does not mention error messages or side effects like lease duration behavior.

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

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

Three tightly written sentences; every phrase packs information. The core action, success conditions, and parameter guidance are front-loaded with no redundancy or 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 small suite of 4 parameters and no return schema, the description covers the essential behavior and the key failure race. It does omit prerequisites (e.g., identity binding) and the response payload, but the tool's complexity is low, so these gaps are minor.

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 75%, so the schema already describes binding_token, lease_seconds, and lease_generation. The description adds value to lease_generation by explaining the race condition ('a stale one loses the race'), but it does not clarify task_id or the other parameters further. This is a modest complement to the schema.

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

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

Description states a specific action 'atomically take the lease on a TASK' and defines success conditions, making it distinct from claim_resource (resource vs. task), renew_lease, and release_task. The ambiguity is resolved directly by naming 'TASK' and the ownership semantics.

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 when to use the tool (when a task is unowned or lease expired) but does not explicitly contrast it with sibling tools like renew_lease or release_task. It provides clear usage context for the success conditions, yet lacks explicit 'instead of X' guidance.

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

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

With no annotations, the description carries the burden and does disclose an important authorization requirement and a mutating state change. It does not reveal side effects on subscribers or messages, reversibility, or failure behavior, leaving transparency partial.

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 core action and the key authorization constraint appear 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 simple mutation with no annotations or output schema, it covers purpose and authorization but omits postconditions, return/error behavior, and interactions with related thread tools. It is minimally viable 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?

binding_token is already well documented in the schema, and thread_id is evident from the word 'thread'. The description adds no parameter-specific format or context details, but the required parameter remains understandable.

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?

Directly states the action ('Close') and the resource ('a thread'), and adds the authorization scope. This clearly distinguishes it from lifecycle siblings like create_thread, poll_thread, and ack_thread.

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 authority constraint ('under opener or campaign-coordinator authority') gives useful context for who may call it, and the verb implies the lifecycle moment. However, it does not explicitly name alternatives or state when not to use it, so usage must be inferred.

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 behavioral burden. It usefully discloses idempotency and the caller-scope restriction, but it does not describe side effects, identity requirements, error behavior, or what closing actually entails beyond the obvious mutation.

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, efficient sentence. Every word earns its place, and the idempotency caveat is neatly parenthesized without disrupting readability.

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

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

For a simple two-parameter tool, the description plus schema is basically callable, but it lacks important context about shared-connection identity and does not state effects, errors, or return behavior. The relevant siblings like plan_session and join_session make the identity question non-trivial.

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 only 50%, with watch_id lacking a description, and the tool description adds no parameter-level meaning. It does not explain how watch_id is obtained or when binding_token is needed, so it fails to compensate for the schema gap.

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

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

The description uses a specific verb ('Close') and a clear resource ('the caller's own watch registration'), making the operation unambiguous. It also adds distinguishing scope ('caller's own') and behavior ('idempotent'), which helps separate it from sibling tools like register_watch.

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, and no alternatives or exclusions are mentioned. 'Caller's own' conveys scope but not the conditions under which an agent should choose this tool over siblings like register_watch.

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 present, so the description carries the full burden. It communicates that the tool commits a digest rather than revealing results, but it does not disclose whether the commitment is durable, irreversible, tied to an identity, or what side effects or response an agent should expect.

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 that immediately names the action and object. The timing clause adds the only essential context without 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 tool with 5 parameters, no output schema, and no annotations, the description is too sparse. It leaves unclear how campaign_id and workflow_id are used, what sharing_policy means, whether binding_token is required in practice, and what the tool returns after a successful commit.

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 only 20%, so the description needs to compensate, but it only adds meaning for the commitment parameter by describing it as a SHA-256 digest. It says nothing about campaign_id, workflow_id, binding_token, or sharing_policy; values like 'blinded' and 'embargoed' remain unexplained.

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

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

The description uses a specific verb ('Commit') and a specific resource ('SHA-256 digest') and clearly places it in time ('before independent workers reveal results'). This distinguishes it from reveal_result and other result-recording tools even though no sibling is named.

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 a clear temporal usage context: call this before independent workers reveal results. It does not explicitly name reveal_result as the paired alternative or list when not to use it, so it stops short of full exclusion guidance.

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

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

With no annotations, the description carries the full disclosure burden. It clearly discloses the major side effects: recording a result, releasing the task, closing the worker, and posting a handoff, and it qualifies the operation as atomic. It does not cover idempotency or lease-failure semantics, but it is unusually explicit about the tool's mutating and terminal 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?

One dense, front-loaded sentence communicates the atomic operation and its four effects without filler. Every word earns its place.

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

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

This tool has 10 parameters, 5 required, 2 enums, no output schema, and no annotations. A single sentence does not provide enough context for an agent to construct a correct invocation, especially around lease_generation, idempotency_key, binding_token, and how result_kind/result_status interact with the assignment lifecycle.

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 only 10%, so the description must compensate, but it does not explain the key parameters: idempotency_key, lease_generation, result_kind, result_status, binding_token, or thread_id. It gives only high-level context around 'task' and 'result' rather than adding concrete semantic detail to the large parameter surface.

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 compound action: atomically record a result, release the task, close the worker, and post a handoff. This clearly identifies complete_assignment as the all-in-one finalization tool and distinguishes it from one-off siblings like release_task, complete_worker, and record_structured_result.

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 about when to use this tool versus alternatives such as release_task, commit_result, or complete_worker. Since many siblings perform overlapping partial operations, an agent is left to infer that complete_assignment is the atomic composite, with no explicit when-to-use or when-not-to-use signal.

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 so well. It discloses identity binding, no-overwrite semantics for terminal status, refusal of live spawn-managed workers, and the reaper failure behavior. These are meaningful behavioral constraints beyond the raw 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?

Three sentences, each earning its place: definition, usage trigger with consequence, and safety constraints. Information is front-loaded and there is no redundant wording.

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?

Despite having no output schema or annotations, the description is complete enough for correct invocation. It covers when to call, prerequisites (own worker), edge cases (existing terminal status, live spawn-managed worker), and the failure mode if not called. Nothing critical is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds general context about terminal status and identity but does not add significant parameter-level meaning beyond what the schema already documents for note, status, worker_id, and binding_token.

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 ('Close'), identifies the exact resource ('the calling agent's own WORKER node'), and states the outcome ('with a terminal status'). It clearly differentiates from siblings like worker_heartbeat or cancel_worker by focusing on terminal completion of the caller's own 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?

It explicitly says when to call it: when delegated work is finished, and provides a strong consequence of not calling it ('the reaper stamps the worker failed'). It does not explicitly name alternatives or exclusion conditions, but the identity and live-worker refusals imply when not to use it.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose that this is a retrieval operation ('over the CPG graph', 'Returns ranked node dicts') and that a complete node ID short-circuits retrieval. It discloses no side effects, but for a read-only query tool this is largely sufficient. Not remarkable, but solid.

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

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

Three crisp sentences. Each earns its place: the first establishes the core mechanism, the second covers usage modes, and the third specifies the special-case behavior. No fluff, no repetition.

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

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

For a tool with 7 parameters AIDS and no output schema, the description covers the essential usage modes fundamental to correct invocation: what it retrieves over, what kinds of queries it accepts, that filters exist, and what the return shape is. It does not detail ranking semantics or result structure, but the mention of 'ranked node dicts' plus the parameter descriptions is sufficient for an agent to make a reasonable call.

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 71%, with several params described. The description adds real value: 'Hybrid FTS + embedding retrieval' explains what question does, 'node_type/domain filters' maps to node_types/domain params, and 'complete 32-hex node id is resolved directly' clarifies an alternative question behavior. This goes beyond what the schema alone tells an 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, compound verb phrase: 'Hybrid FTS + embedding retrieval over the CPG graph.' It then enumerates concrete use modes (structured lookups, open-ended recall, direct node-ID resolution). This is far beyond a tautology; however, it does not explicitly contrast with sibling tools like get_nodes, so it stops short of a perfect score.

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

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

The description gives explicit guidance on when to use the tool ('Use for structured lookups' or 'open-ended recall') and calls out the special case for complete node IDs. It does not mention exclusions or explicitly route to an alternative, but the actionable use cases are clear enough.

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 disclosure burden. It transparently states the ephemeral nature, the promotion mechanism that persists to an OBSERVATION node, and the requirement to pair obs_type with promotion. It does not address return behavior, but the core persistence semantics, side effects, and conditionality are disclosed.

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

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

Three sentences total, with the core role ('ephemeral reasoning scratchpad') front-loaded, followed by the promotion condition and the routing rule. Every sentence contributes a distinct piece of information with zero filler.

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

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

The description gives agents the essential operational context: ephemeral scope, promotion when needed, and explicit alternative routing. The only notable omission is what the tool returns or what an OBSERVATION node means downstream, but given the 100% schema coverage and the strong usage routing, the agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaningful parameter semantics by clarifying that promote_to_=observation with obs_type is the persistence condition, and qualifying which content qualifies (directly perceived data) versus content that belongs in record_belief. This goes beyond what the schema states about the parameters.

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

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

The description opens with 'Ephemeral reasoning scratchpad', stating a specific role and resource immediately. It further distinguishes the tool from record_belief by explicitly stating that predictions and hypotheses go through record_belief, not here.

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 explicit conditions for persisting: 'Use promote_to=\'observation\' with obs_type to persist' and when to do so ('when the thought captures directly perceived data (tool output, file read, etc)'). It also gives direct when-not instructions by routing predictions and hypotheses to record_belief, leaving no ambiguity about the alternative.

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 for behavioral disclosure, but it only states that something is created. It does not mention side effects, whether creation requires authorization, whether it blocks, what happens to configured participants, or what the return value is.

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

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

The description is a single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity comes at the cost of useful behavioral and parameter detail.

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 seven parameters, no output schema, and no annotations, an 11-word description is materially incomplete: an agent cannot infer the required call shape, return value, or lifecycle placement. It is not a pure tautology, so it earns slightly above the floor.

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 description weakly maps to 'quorum' and 'phase', but it adds no meaning for campaign_id, name, deadline_at, participants, or binding_token. Since schema description coverage is only 14%, the description does not compensate for the mostly undocumented parameters.

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

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

The description uses a specific verb-resource pair ('Create a quorum barrier') and scopes it to 'an explicit campaign phase,' which is enough for an agent to distinguish it from nearby siblings like arrive_barrier. It does not explicitly name alternatives, so it stops just short of full differentiation.

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

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

There is no guidance on when to create a barrier versus use related tools such as arrive_barrier or plan_session, nor any mention of prerequisites or sequencing. The phrase 'for an explicit campaign phase' only implies a context; it does not say when-not to use the tool.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says the campaign is 'durable' and that an owner membership is created. It does not explain side effects, persistence semantics, token requirements, sharing policy consequences, or what happens to the caller after creation. This is too thin for a mutating tool with no annotation safety signals.

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 sentence and not bloated, but it is so terse that it sacrifices useful content. It is front-loaded with the core action, yet the wording is cryptic ('owner membership capability') and does not earn its place as a complete orientation. This is under-specification rather than effective conciseness.

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

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

Given four parameters, no output schema, no annotations, and a low schema description coverage, the description is far too incomplete. It does not explain how to use the parameters, what the return value is, what ownership means, or how this relates to the many campaign/thread/member sibling tools. An agent would struggle to invoke this correctly without additional external knowledge.

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 only 25%, so the description should compensate by explaining non-obvious parameters like binding_token and default_sharing_policy, but it does not mention any parameters at all. The schema itself documents only binding_token, leaving name, description, and default_sharing_policy semantics largely unexplained. The description adds no parameter-level value.

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 action ('Create') and a concrete resource ('durable coordination campaign'), and adds that it creates 'owner membership capability.' This is more than a tautology and gives an agent a basic idea of what the tool does. However, the phrase 'owner membership capability' is imprecise, and the description doesn't explicitly differentiate this from sibling creation tools like create_thread or start_workflow.

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 about when to use this tool versus join_campaign, invite_member, or other campaign-related tools. The description does not state what scenarios call for creating a campaign, nor does it mention any exclusions or prerequisites. The agent must infer usage solely from the tool name and context.

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

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

With no annotations, the description carries the full behavioral burden. It reveals that a thread is a named channel other agents can post to, but it does not explain whether duplicate topics are allowed, what opening an existing thread does, what side effects occur, what permissions apply, or what the response contains.

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

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

The description is front-loaded, unambiguous, and contains no filler. Both sentences earn their place, though the brevity leaves important operational details uncovered.

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 10 parameters, three enums, no annotations, and no output schema, the description is far from complete. It provides a concept and one usage rule but not enough information for an agent to correctly set access_mode, visibility, sharing_policy, or understand identity requirements like binding_token.

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 only 10%, so the description must compensate, but it mentions no parameters at all. The agent is left to infer the meaning of visibility, access_mode, sharing_policy, task_ids, participants, and other fields from the raw schema.

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

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

The description states a specific verb and resource: 'Open a THREAD node: a named channel other agents in this session can post to.' It also differentiates from message-level tools via 'not one per message,' so an agent can distinguish create_thread from send_message and thread-interaction siblings.

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

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

'Use one thread per topic or handoff, not one per message' gives explicit context and a clear exclusion for when not to create a thread. It does not name a specific alternative tool, but the guidance is concrete enough to route an agent's 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?

With no annotations, the description carries the behavioral disclosure burden, and it does disclose meaningful behavior: project scoping, deduplication by normalized text, and separation from FACT/BELIEF governance. It does not mention duplicate-handling failure modes or whether the operation is idempotent, but the most important behavioral traits are present.

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 states the primary action first, then packs scope and governance details efficiently.

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

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

For a six-parameter tool with no annotations, the description covers scope and governance but leaves several call-critical aspects to the schema, such as identity requirements and evidence_refs quarantine behavior. The presence of an output schema reduces the need to describe return values.

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 67%, so most parameters already have descriptions. The tool description adds only 'short practical' context for text and does not clarify the ambiguous kind enum values or binding_token semantics beyond what the schema states.

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

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

The description names the resource ('short practical TIP'), the action ('Drop'), and its distinguishing traits: project-scoped, deduplicated by normalized text, and separate from FACT/BELIEF governance. This clearly differentiates it from sibling tools like record_fact and record_belief.

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 contextual guidance by noting TIPs are separate from FACT/BELIEF governance, implying this tool is for practical tips rather than facts or beliefs. However, it never explicitly states when to prefer drop_tip over related siblings like tips, tip_useful, or moderate_tip, nor gives exclusions.

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

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

With no annotations, the description carries the full burden and does add real behavior: it returns the complete payload rather than a truncated match, and it discloses session scoping defaults ('Scoped to your session by default; session_scope='project' reads across the project'). It stops short of explicitly confirming it is read-only and says nothing about errors or rate limits, but 'Fetch' plus the scoping detail cover the key expectations.

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

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

Four short sentences, each carrying distinct information: what it fetches, the contrast with summaries, the when-to-use, and scoping behavior. Front-loaded with the action and resource, with no filler or repetition of schema fields.

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

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

For a simple read-by-id tool with no output schema, the description gives enough to call it successfully: ids are needed, results are full payloads, and scope behavior is explained. It could be slightly more complete by noting how to obtain/create node ids beyond the posted-results example, but the schema and sibling names fill most 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 coverage is 67%, with node_ids and binding_token already described; the description adds value by explaining that node_ids fetch 'whole' nodes with full payload and by giving session_scope its meaning ('current' vs 'project' scope). It does not add anything about binding_token, but the schema description for that parameter is already sufficient.

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

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

Opens with a specific verb+resource ('Fetch whole nodes by id') and immediately differentiates itself from the sibling cpg_query ('by-id counterpart to cpg_query's ranked search'). The 'not a truncated match' contrast reinforces that this is the detail retrieval tool, not the search 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?

Explicitly states when to use it: 'Use when you hold specific ids' and 'need the recorded detail, not a summary', with a concrete example (result ids a crew posted to a thread). It names cpg_query as the alternative for ranked search, so an agent can route between the two.

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 clearly states the tool never executes commands from the trace, describes the nodes it creates, and discloses the default JSONL filtering behavior that skips Opus/Sonnet rows. This is strong, safety-relevant transparency for an importer.

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 two dense sentences with no filler. It front-loads the core purpose, then adds use cases, side effects, and default behavior, each earning its place.

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

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

The description covers purpose, safety, and default filtering well, but it omits return value behavior and leaves key parameter semantics unexplained. With no output schema, the agent is left unsure what the importer returns on success, which matters for follow-up actions.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters, but it does not. It indirectly clarifies include_non_fable through the default filtering note, but trace_path, workflow_name, and max_events receive no semantic explanation beyond their names and schema 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 opens with a precise verb and resource: 'Read-only importer for Claude/Fable JSONL traces or workflow result JSON.' It further specifies what the tool creates (WORKFLOW, WORKER nodes, trace events, STRUCTURED_RESULT nodes), making it clearly distinguishable from sibling write/record tools like record_execution or start_workflow.

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 explicit usage context: 'Use when analyzing prior Fable sessions or preserving an external multi-agent workflow in CPG.' It does not name alternatives or state when-not-to-use, but the use cases are concrete enough to guide selection among the listed 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 are absent, so the description carries the full burden of behavioral disclosure. It conveys that the membership is revocable and role-scoped, but says nothing about required preconditions (e.g., existing campaign, identity binding token), side effects (e.g., creation of a record, notification), or error conditions. The binding_token field is not described in the main description, only in the schema.

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

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

A single focused sentence with no filler or repetition. Every word contributes: 'revocable' and 'role-scoped' are meaningful constraints, and the verb is precise.

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

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

The tool has 6 parameters, no output schema, and no annotations, yet the description addresses none of the operational details an agent must know to call it correctly. There is no mention of what the response is, what the parameters require, or what side effects result. The one-liner is insufficient for a tool of this complexity.

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 only 17% (only binding_token is described). The phrase 'role-scoped' gives partial meaning to the role parameter, but other parameters — campaign_id, agent_id, expires_at, capabilities, and binding_token — have no semantic explanation in the description. The description does not compensate for the low schema coverage.

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

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

The description states a specific verb ('Issue') and resource ('campaign membership capability'), with constraint qualifiers 'revocable' and 'role-scoped' that help differentiate it from revoke_member or join_campaign. However, it does not explicitly name a sibling alternative, and 'capability' is slightly abstract, leaving a small gap.

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 guidance on when to use invite_member versus alternatives such as join_campaign or create_campaign. The qualifier 'revocable' implies a counterpart, but there is no explicit mention of when an agent should choose this tool over others, no prerequisites, and no exclusion criteria.

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

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

No annotations are provided, so the description carries the full burden of disclosing effects. 'Authenticate this connection' suggests a state-changing operation but does not explain whether membership persists, what side effects occur, or what failures are possible.

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, focused sentence with no filler. The action and the key input mechanism are front-loaded, making it easy to parse.

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

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

For an authentication/joining operation with no annotations and no output schema, the description is too sparse. It omits how membership tokens are obtained, whether binding_token is required, and how this differs from join_session, though the schema partially documents binding_token.

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 only 33%, and the tool description does not compensate. It mentions 'membership token' but does not explain campaign_id or clarify the relationship between binding_token and membership_token, leaving the agent to infer parameter semantics from the schema 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 action ('Authenticate') and a clear resource ('this connection into a campaign'), which is informative. However, it does not distinguish join_campaign from the sibling join_session, leaving the differentiator to 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?

The description gives no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like join_session, nor does it state prerequisites such as an existing invitation, campaign membership, or binding_token requirements.

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

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

With zero annotations, the description carries the full burden of behavioral disclosure, and it does add useful content: the bind is to an existing session, the tool does not archive anything, and it is a mandatory precondition for other radio tools. However, it omits equally important idempotency/failure content — what happens if the session id does not exist, whether a second call reinstates or errors, and what identity/authorization guarantees 'declare the calling agent's id' implies. The description earns a mid score by adding some behavioral context but leaves the agent to guess on boundary cases for a stateful binding 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?

Three short, front-loaded sentences each serve a distinct purpose: the core operation, a negative behavioral qualifier, and the usage precondition. The only slight weaknesses are the exactly GNATC — 'Does not archive anything' does meaningful work only if the reader had expected archiving otherwise, and 'radio tool' is internal jargon — so the score stops short of top marks, but almost every word earns its place.

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

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

The output schema removes the need to describe return values, and the description covers the cardinal points: what the tool does and why/needing when to call it. Given the tool's role in a session-lifecycle stateful binding with a spawned-child override path, the description stays incomplete on edge-behavior — repeated joins, what determines an 'active' session, invalid session_id handling, and the child-token role — meaning an agent may need to probe to discover consequences. It suffices for the standard flow but is not fully complete for its complexity.

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 67%, so the structured data already documents agent_id and child_token and the override of session_id/agent_id. The description adds meaning to the otherwise undescribed session_id by invoking 'an existing active session', which distinguishes it from a session that must be created, and ties agent_id to 'the calling agent's id'. It does not mention child_token at all, and the general statement 'declares the calling agent's id' is slightly inaccurate for the child-token path where session_id/agent_id are ignored, so the added semantic value is partial.

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

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

The description uses a specific verb+resource combination — 'bind this connection to an existing active session' — and clarifies the scope by saying 'existing active session', immediately differentiating it from session creation tools like plan_session. It also names the calling agent's identity declaration, which is a precise second behavior. This makes the tool recognizably distinct from most of the 61 sibling tools without needing to open their schemas.

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

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

The description gives an explicit invocation condition: 'Required before any other radio tool when the agent did not itself call plan_session.' It names the alternative (plan_session) as the source of the session, so the when-to-use and the when-not-to-use are both strongly derivable, and the consequence of not using it (subsequent radio tools would misapplied at this session) is implicitly clear.

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

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

With no annotations, the description carries the burden of behavioral disclosure, and it does state 'read-only' and 'No token required.' However, it does not cover edge cases such as the schema-described binding_token need for reliable identity when logical agents share an MCP connection, and it says nothing about pagination, bounds, or output ordering.

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

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

Two short sentences deliver the operation, scope, output fields, and auth note with no redundant text. The important behavioral qualifiers are front-loaded.

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

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

For a simple list tool the description covers the returned fields and session scope, but without an output schema or parameter semantics it leaves basic behavior unclear, such as what an empty call returns and whether workflow_id and spawn_states are filters or outputs.

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 only 33%, so the description must compensate for the undocumented parameters. It does not explain how workflow_id and spawn_states filter the listing, which means an agent cannot correctly infer what these optional inputs do.

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 identifies a specific resource and scope ('spawned workers in this session') and frames the tool as a read-only table rather than repeating the name. Listing the output columns (provider, spawn_state, depth, parentage, uptime) helps distinguish it from write/heartbeat tools.

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

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

The description gives clear context for when the tool is appropriate: inspecting the read-only set of spawned workers in the current session. It does not explicitly name alternative tools or exclusion conditions, so it does not earn 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 provided, the description carries the full burden of behavioral disclosure, and it only reveals that the tool approves or rejects. It does not disclose side effects, whether the action is reversible, permission requirements, idempotency, or what happens to the tip after moderation.

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 or repetition. Every word contributes to identifying the core action and resource.

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 moderation tool with four parameters, no annotations, and no output schema, this description is too sparse. It does not explain how evidence_refs is used, how binding_token factors into identity, what the response indicates, or what state the tip enters after approval or rejection.

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 only 25%, and the description adds little beyond the word 'evidence' to clarify parameters. tip_id and review_state are obvious from names and enum, but evidence_refs and binding_token are left mostly undocumented, so the description does not compensate for the schema gap.

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

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

The description names a specific verb pair (approve/reject), a clear resource (quarantined campaign tip), and a distinguishing qualifier (with evidence). This makes the tool's purpose understandable and reasonably distinguishable from siblings like drop_tip or tip_useful, though it does not explicitly differentiate itself.

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 this is used in a moderation workflow for quarantined tips, but it gives no guidance on when to choose this over alternatives such as drop_tip or resolve_contradiction. It also does not explain prerequisites, such as whether evidence must already be attached or whether a claim/lease on the tip is needed.

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 present, so the description carries the full burden of behavioral disclosure. It does reveal the main side effects—creating nodes, registering a graph, resolving dependencies, converting constraints to facts—so an agent knows it is making a persistent planning state. However, it fails to mention the destructive default of archiving previous session (via the archive_previous parameter, default true), and does not mention permissions, reversibility, or rate limits, which are important for a tool of this complexity.

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, 34 words total, are densely packed with meaningful information. It starts with the primary action, then lists the specific effects, and closes the precise usage guidance. There is no filler, no redundant restatement, and every sentence contributes to the agent's understanding.

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

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

Given the tool's high complexity (12 parameters, many nested object types, low schema coverage), this description is insufficient. It does not explain how to structure or populate the budget, risk, assumption, success_criteria, or verification_plan inputs. Even though an output schema exists, input semantics are not fully covered. The agent cannot infer the intended content of the many nested objects from the description alone.

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

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

Schema description coverage is only 17% (only agent_id and archive_previous have descriptions in the schema). The tool description explains a few core parameters—goal, tasks (through 'registers the full task graph'), constraints ('converts constraints to FACT nodes'), and dependencies ('resolves dependency indices')—but it leaves many other parameters unexplained: risks, budget, assumptions, decision_context, success_criteria, verification_plan. The description does not compensate adequately for the low schema coverage.

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

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

The description starts with a specific verb ('Initialise') and resource ('planning session'), then lists concrete actions it performs: creating a GOAL node, registering the task graph, resolving dependencies, creating impact predictions, and converting constraints to FACT nodes. This clearly conveys what the tool does and differentiates it from a generic 'start' tool, though it does not explicitly compare itself to any sibling (e.g., start_workflow).

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

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

The description gives an explicit usage instruction: 'Call once per session before executing tasks.' This tells the agent exactly when to invoke the tool and what to do before it, providing clear context. However, it does not mention any alternatives or exclusions (e.g., 'use replan instead of this for replanning'), so it stops short of a full 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 behavioral burden. It explicitly discloses read-only behavior and lack of cursor advancement, which is important. It also mentions binding_token for identity. However, it does not cover error handling, pagination behavior beyond max_results, or any side effects, so the disclosure is partial.

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 sentence plus a clarifying clause. It is front-loaded with the core purpose and distinguishes the tool without waste. Every sentence adds value.

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

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

Given an output schema exists and parameter schema coverage is full, the description is sufficient for an agent to understand the operation. It covers the key behavioral constraint (read-only) and points to the sibling for cursor advancement. It does not elaborate on error conditions or advanced use cases, but these are largely covered by the schema and a read-only operation, so it is mostly complete.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter-specific meaning; it only ties after_seq to the 'newer than a sequence number' concept without extra detail. This meets the baseline but does not exceed 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 description states a specific verb ('Read'), resource ('messages'), and scope ('in this session newer than a sequence number'). It explicitly contrasts with ack_messages by noting it does not advance the cursor, distinguishing it from that 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?

It clearly indicates the read-only nature and points to ack_messages for advancing the cursor, giving an explicit alternative. However, it does not state broader usage scenarios (e.g., when to poll vs. subscribe), though the contrast with ack_messages is strong and provides clear context.

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

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

With no annotations, the description must carry behavioral disclosure. 'Poll a thread from its independent subscription cursor' is too thin: it never states whether polling consumes messages, advances the cursor, requires an active subscription, or is safe to call repeatedly. The term 'independent subscription cursor' is unexplained.

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

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

Two short sentences with no filler; the key concept is stated up front. It sacrifices some helpful detail for brevity, but it is reasonably structured.

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

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

For a tool with no annotations and no output schema, the description leaves important operational questions unanswered: what an independent subscription cursor is, how it is obtained, whether polling is destructive, and why binding_token matters. Sibling tools like subscribe_thread/ack_thread further suggest a lifecycle that this description does not situate.

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 only 33%; only binding_token is described. The description adds almost nothing about thread_id (beyond the name) or max_results. It does not clarify that thread_id refers to the polled thread or what max_results limits, so the low coverage is not compensated.

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

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

The description names the specific operation ('Poll') and a distinct resource ('a thread from its independent subscription cursor'). This distinguishes it from generic message polling, though the exact meaning of 'independent subscription cursor' is not explained. It is still more precise than a vague restatement of the tool name.

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 guidance is given about when to use poll_thread versus siblings like poll_messages or subscribe_thread. The phrase 'independent subscription cursor' hints at a use case but never states prerequisites, exclusions, or 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?

With no annotations, the description carries the behavioral burden. It does disclose meaningful behavior: the operation is atomic and combines lease renewal, heartbeat, and progress posting. But it omits failure semantics, lease-generation conflict handling, idempotency behavior, and what happens to the worker or task on invalid input, leaving notable gaps.

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 sentence with no filler. 'Atomically' is front-loaded and immediately signals the most important behavioral constraint, and every phrase adds distinct information about the operation.

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?

This is a moderately complex state-changing tool with 7 parameters, 5 required, no annotations, and no output schema. The description does not explain return behavior, idempotency semantics, the role of binding_token, or how lease_generation failures are handled, so the agent cannot fully predict the tool's 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 only 14%, so the description must compensate for documenting parameters. It only loosely maps concepts like 'lease' and 'progress' without explaining idempotency_key, binding_token, lease_generation, lease_seconds, or body format. An agent has little help beyond field names and constraints.

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

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

The description names specific actions ('renew a task lease, heartbeat the worker, and post progress') and adds the key trait 'atomically', so an agent can tell this is a combined operation rather than a plain progress update. It does not explicitly contrast sibling tools like renew_lease or worker_heartbeat, but the composite scope is clear enough.

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 word 'atomically' implies the tool should be used when lease renewal, heartbeat, and progress posting need to happen together. However, the description never names alternatives or states when this should be preferred over sibling tools like renew_lease, worker_heartbeat, or update_task, so usage guidance is only implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does state one behavior: it does not return restricted message bodies, implying it filters sensitive content. However, it does not disclose other behaviors such as whether it is read-only, whether it requires any specific permissions, what it actually returns (e.g., a summary, a list of issues), or any side effects. This is insufficient for a reporting 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?

The description is extremely concise—one short phrase. It is front-loaded in the sense that the main action is stated first, but it is under-specified. It earns a middle score because it has no fluff, but the brevity comes at the cost of critical 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?

Given the tool has 2 parameters, no output schema, and no annotations, the description must be self-sufficient. It is not: it omits what the tool returns, how the parameters influence the report, and when to use it. An agent would have to make significant guesses about how to invoke it correctly.

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

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

Schema description coverage is only 50% (only binding_token has a description in the schema). The tool description does not mention either parameter at all. It does not explain what campaign_id is used for or how binding_token relates to the health report. Since coverage is low and the description compensates nothing, this is a major gap.

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

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

The description says 'Report coordination health' which is a verb+resource but 'coordination health' is not a well-defined concept. It doesn't specify what aspects of health are reported (e.g., worker status, task progress, connection state). It does add a clarifying contrast ('without returning restricted message bodies') which helps but the core purpose remains vague. It is not a tautology, but it lacks specificity to distinguish from potential sibling tools.

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

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

There is no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, conditions, or exclusions. The description is purely a statement of what it does without any situational context. The agent is left to guess when 'reporting coordination health' is appropriate.

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?

Without annotations, the description carries the behavioral burden. It does disclose CAS semantics and versioning, which are genuine behavioral traits beyond the name. However, it omits side effects, conflict/failure behavior, identity requirements (binding_token), and whether the signal is persisted or broadcast.

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 single sentence is efficient and front-loads the action. It is concise and free of filler. It loses a point because it is so terse that it does not structure any usage or parameter context, but as a conciseness measure it is strong.

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 9-parameter mutation tool with no annotations, no output schema, and very low schema coverage, a one-sentence description is severely incomplete. It provides no return format, error semantics, parameter explanations, or guidance on when CAS applies. An agent cannot reliably invoke this tool correctly from the given definition.

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

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

With only 11% schema description coverage and 9 parameters, the description needed to compensate but only hints at 'typed, versioned' (likely expected_version/value). It does not explain campaign_id, name, value, audience, visibility, ttl_seconds, evidence_refs, or binding_token, leaving the agent without semantic grounding for most parameters.

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

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

The description names a concrete verb and resource: 'Create or compare-and-swap a typed, versioned coordination signal.' This clearly separates it from siblings like wait_for_signal (publish vs. wait) and indicates a write operation. It loses a point because 'compare-and-swap' is left unexplained and no concrete use case is given.

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 about when to use publish_signal versus wait_for_signal, create_barrier, or other coordination tools. The description implies a publish operation but provides no exclusions, prerequisites, or alternatives, so an agent must infer usage entirely from the tool name and sibling list.

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

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

No annotations are provided, so the description carries the burden. It discloses a key side effect: when belief_kind='assumption', it also creates a linked ASSUMPTION control-plane node. It also states the requirement to cite supporting FACT/OBSERVATION ids. It doesn't mention whether the operation is reversible or what the return value is, but the disclosed side effect is significant and useful.

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 with no filler. The first sentence states the purpose and the key requirement; the second adds the conditional side effect. Every word earns its place.

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

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

For a tool with 8 parameters and no output schema, the description covers the essential behavioral context: what counts as a belief, the evidence requirement, and the assumption side effect. It doesn't explain the remaining parameters (domain, risk_id, expiry_condition, verification_target) or return behavior, but the core decision an agent needs—when to call this vs record_fact and what to provide—is present.

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 only 13%, so the description must compensate. It adds meaning by explaining the purpose of supporting_ids (backing evidence) and the special behavior of belief_kind='assumption'. It also clarifies that supporting_ids is required for belief and hypothesis but may be omitted for assumptions, which is not fully clear from the schema alone. It doesn't explain domain, risk_id, expiry_condition, or verification_target, but the core semantics are covered.

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

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

The description clearly states the tool records an uncertain BELIEF (inference, hypothesis, assumption) and distinguishes it from sibling record_fact by emphasizing uncertainty and the need to cite supporting FACT/OBSERVATION ids. It also names the specific belief_kind values and the special behavior for 'assumption'.

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

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

The description gives clear context: use this for uncertain beliefs, must cite supporting FACT/OBSERVATION ids, and notes the special case for assumption. It doesn't explicitly say 'use record_fact for certain facts' or list exclusions, but the contrast with record_fact is implicit and the required supporting_ids guidance is strong.

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 behavioral disclosure burden. It discloses several effects: creating the EXECUTION node, auto-observation, lazy ARTIFACT creation, staleness processing, and storing objective_signals for reflect(). It does not mention side effects, persistence guarantees, failure behavior, or whether the operation is idempotent, so coverage is partial.

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 dense sentence with no filler. It front-loads the core purpose and packs related behaviors efficiently, though the parenthetical jargon may reduce readability for an unfamiliar agent.

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

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

Given the high parameter count, nested objects, absence of annotations, and no output schema, the description is too high-level to fully support correct invocation. It omits practical details about required field semantics, relationships among parameters, return behavior, and expectations for summaries or signals.

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 only 15%, so the description must compensate for the 13 parameters. It adds meaning for actual_impacts and objective_signals, but does not clarify required fields like task_id, input_summary, outcome_summary, success, or the delegated_* fields. This is a significant gap for a complex schema.

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

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

The description uses a specific verb and resource: it 'Creates an EXECUTION node + auto-observation' and logs a 'significant tool call.' This differentiates it from sibling record tools like record_fact and record_belief, though it does not explicitly name 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?

The phrase 'Episodic log of a significant tool call' gives an implied usage context: use this when recording a notable execution event. However, it provides no explicit when-to-use vs alternatives or exclusions, leaving this 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 burden and does useful work: it signals a write operation and explains state-transition behavior—facts start as provisional, are upgraded by evidence, and supersedes_id chains replacements. It does not mention permissions or side effects beyond creation, but the core lifecycle is clearly disclosed.

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

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

Three tight sentences put the primary action first and then add only high-value context: the grounding requirement, the provisional lifecycle, and the supersede behavior. There is no filler or restatement of schema fields.

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

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

For a write tool with 8 parameters and no annotations or output schema, the description covers the critical source and replacement logic but omits the meaning of domain, confidence, symbol_id, and artifact_id, and says nothing about return values. It is sufficient for the common path but not fully 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 only 25%, and the description adds meaning for source_observation_id, source, and supersedes_id by explaining their roles. However, required parameters content and domain, plus confidence, symbol_id, and artifact_id, are left to inference, so the description only partially compensates for the low schema coverage.

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

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

The phrase 'Record a grounded FACT' names a specific verb and object, and the capitalized FACT plus 'grounded' distinguishes it from sibling record_belief. The requirement to cite a source observation or raw source string further pins down what this tool does and what it does not.

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 a clear precondition: source_observation_id must come from a prior cpg_think promote, or a raw source string must be supplied. It also explains the facts lifecycle, but it does not explicitly name record_belief or state when not to record a fact, so it stops short of a full when/when-not contrast.

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?

Discloses only that storing occurs and that the response is an aggregate count by result kind and status. With no annotations, the description carries the full burden, but it does not state validation behavior, whether data is validated against result_schema, idempotency or replacement semantics, or workflow prerequisites.

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

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

Three sentences, front-loaded with the core purpose, followed by a valuable verdict usage pattern and the response shape. No wasted words, and each sentence earns its place.

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

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

Given 14 parameters, nested data, low schema coverage, no annotations, and no output schema, the description leaves important call semantics unspecified. It covers the verdict path well but not the general data/workflow/worker field semantics, so an agent cannot confidently construct a fully correct call from the text alone.

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

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

Schema description coverage is only 14%, so the description must compensate for the undocumented parameters. It meaningfully explains result_kind, status, and verifies_result_id for the verdict case, but leaves data, workflow_id, confidence, metadata, source_trace_path, and source_execution_id semantically 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 action: store schema-bound worker output in a workflow, with explicit use cases (findings, verifier verdicts, coverage notes, final reports). The verdict-specific guidance further clarifies scope. It does not explicitly name sibling tools such as record_fact or record_belief, so differentiation is implicit rather than 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?

Gives explicit use contexts ('Use for findings, verifier verdicts, coverage notes, and final reports') and a concrete verdict recipe with result_kind='verdict', specific statuses, and verifies_result_id. It omits exclusions or named alternatives, but the use-case list plus result_kind enum is enough to guide basic 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?

With no annotations, the description is the only signal about effects, but it only says the server 'computes' ReflectiveSignals and a 'dual-signal SCORE' and 'closes the loop.' It never states whether this mutates state, what side effects occur, or what the response looks like.

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

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

The text is brief and avoids repetition, but it relies heavily on undefined jargon such as 'dual-signal SCORE' and 'v1.4 control-plane nodes'. Structure is reasonable for a description of this length though not maximally clear.

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 14 parameters, no annotations and no output schema, the description omits the required fields (task_id, expected_outcome, actual_outcome), does not specify side effects, and leaves key jargon unexplained. An agent cannot safely call this tool based on the description alone.

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

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

The description highlights deviation_type and objective_signals, but the schema has many fields, including required task_id, expected_outcome, and actual_outcome, plus optional fields like extract_pattern and applied_pattern_ids. With only two of ~14 parameters mentioned and no compensation for undefined fields, an agent lacks guidance for constructing a valid request.

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 identifies the resource ('pedagogical loop', patterns/beliefs/control-plane nodes) and the core action (compute ReflectiveSignals and a dual-signal SCORE), but uses domain jargon without concrete verbs like 'record' or 'update.' It does not clearly distinguish this from sibling tools such as record_structured_result or record_belief.

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

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

The description says to provide deviation_type and optionally objective_signals, but gives no guidance on when to use this tool versus alternatives, no prerequisites, and no expected preconditions. There is no explicit when/when-not to use it.

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

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

No annotations are provided, so the description must carry the burden. It only says 'Record' and gives no side effects, overwrite semantics, identity requirements, or relation to other watch tools; binding_token's role appears only in the schema, not the description.

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

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

A single front-loaded sentence with no filler, easy to parse. It is concise even though it sacrifices detail.

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 5-param tool with no annotations and no output schema, the description is too thin: no target-combination rules, no mention of binding_token, and no indication of postconditions or how to close/replace a watch.

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?

Description names worker id, label, and done-file, adding meaning to those three params, but omits binding_token and note. With schema description coverage at only 20%, note remains entirely unexplained, so the description fails to compensate for the gap.

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

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

Description uses a specific verb ('Record') and identifies the resource ('which job this agent is waiting on') with the three target forms. It is distinguishable from close_watch and wait_for_signal, though it does not explicitly contrast 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?

No guidance on when to register a watch versus alternatives, when to call close_watch, or what prerequisites exist. The schema's 'At least one target is required' is the only constraint and appears outside the description.

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 provided, the description carries the full burden of behavioral disclosure. It mentions that the tool registers a worker, but does not disclose whether it mutates state, whether it is idempotent, what happens if a worker already exists, or any side effects like creating a session or sending messages. This is a significant gap for a registration 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?

The description is two sentences long and front-loads the core purpose. The first sentence states the verb and resource clearly. All sentences are informative without redundancy. Slightly could be improved by structuring the list of fields more succinctly, but it's 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 tool with 11 parameters, 2 required, no output schema, and 18% schema coverage, the description is insufficiently complete. It identifies the core purpose and important fields but omits behavioral implicationsholistically, such as how registration interacts with the workflow lifecycle, what the workflow_id refers to, or what the return value is. It's adequate for a basic understanding but leaves gaps for correct invocation.

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

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

Schema description coverage is only 18%, so the description must compensate for the many undocumented parameters. It does mention key fields (model, agent_id, prompt, dimension, role) and the purpose of binding_token indirectly via the schema description, but it doesn't explain important parameters like coverage_notes, metadata, or status. The description adds some context but not enough to fully bridge the gap.

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

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

The description clearly states the tool registers a delegated worker/agent inside a workflow, with specific roles (finder, verifier, synthesizer, executor) and mentions including model, agent_id, prompt, dimension, and role. This distinguishes it from sibling tools like spawn_workers or complete_worker, though it doesn't explicitly name 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?

The description provides clear guidance to use one worker per finder/verifier/synthesizer/executor, and to include audit information. It doesn't explicitly state when not to use this tool or mention alternatives, but the context of 'delegated worker' within a workflow is clear enough to infer appropriate usage.

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 burden. It does disclose that the operation is generation-checked and scoped to the caller, which is meaningful. However, it doesn't mention what happens on stale generation, idempotency, or side effects of releasing.

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 conveys the core action without filler or tautology.

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 mutates resource state with no annotations and no output schema. Missing information includes failure modes (stale generation), idempotency, whether the caller must be the lease holder, and what a successful release returns.

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 only 33%: lease_id and generation have titles but no descriptions. The description adds 'generation-checked' which hints at generation's role, but it doesn't explain where lease_id/generation come from, how they relate, or what the binding_token does beyond the schema text.

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

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

The description uses a specific verb ('Release') and clearly identifies the object ('resource lease'), and 'generation-checked' adds useful distinguishing nuance. It doesn't explicitly contrast with sibling tools like renew_lease, 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?

No guidance on when to use this versus alternatives (e.g., release_task, renew_lease, cancel/abandon scenarios). The phrase 'release the caller' implies self-release, but no conditions, prerequisites, or exclusions are stated.

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

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

No annotations are present, so the description carries the burden. It does disclose the critical race-condition guard (lease_generation protects against releasing a reaped-and-reassigned task), but doesn't explain side effects, idempotency, failure behavior, or what happens to the task after release.

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 then the single most important caveat. No filler or repeated schema content.

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

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

For a lease-release operation, the description plus schema covers the required identifiers and the safety guard, and status/note semantics are in the schema. It doesn't describe response/return value, but that appears acceptable given the tool's simplicity.

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 covers note, status, and binding_token well; the description adds crucial semantic context for lease_generation, which the schema leaves as a bare integer, by explaining its safety role.

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 ('Give up') plus the target ('a TASK') and the lease relationship. It clearly distinguishes the action from general task updates, though it doesn't explicitly name sibling alternatives.

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

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

Clear context: the caller is releasing its own lease, and the lease_generation requirement prevents releasing a task that was reassigned. It doesn't explicitly steer the agent to alternatives like renew_lease or update_task, but the operation's scope is unambiguous.

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 provided, the description carries the full burden. It discloses a key behavioral trait: the operation fails if the lease was reaped or reassigned, which is valuable. However, it does not disclose whether the extension is idempotent, whether it resets the lease timer from the current time, or what happens to the old lease generation. The failure condition is useful but incomplete for a mutation tool with zero annotation coverage.

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

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

The description is two sentences with no wasted words. The core action is front-loaded, and the failure condition is a useful addition. It is appropriately sized for the tool's complexity.

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

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

The tool has 4 parameters, 2 required, no output schema, and no annotations. The description explains the basic operation and one failure mode, but it does not cover the concurrency semantics of lease_generation, the clamping behavior of lease_seconds (though the schema covers that), or what the response contains. For a lease-extension tool, the missing concurrency context is a notable gap, but the description is not severely incomplete.

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 50%, so the schema documents binding_token and lease_seconds but not task_id or lease_generation. The description adds meaning by explaining that the lease is on a TASK and that lease_generation relates to reaping/reassignment, but it does not explicitly explain that lease_generation is the current generation required for optimistic concurrency, nor does it clarify the role of task_id beyond identifying the task. It partially compensates for the schema gap but leaves the two undocumented required parameters under-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 states a specific verb ('Extend') and resource ('the caller's lease on a TASK'), which clearly identifies the operation. It does not explicitly differentiate from sibling tools like renew_resource or worker_heartbeat, but the resource and mechanism are distinct enough that the core purpose is clear.

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

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

The description implies usage context: it is for extending a lease the caller already owns, and it names failure conditions ('Fails if the lease was reaped or reassigned'). However, it does not explicitly state when to prefer this over alternatives like renew_resource or worker_heartbeat, nor does it mention prerequisites like joining a session or claiming the task.

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 provided, the description carries the full burden of behavioral disclosure. It mentions that the lease must be held by the caller, but gives no information about idempotency, failure modes, side effects, or authorization requirements. The description is too sparse to help an agent understand the operational behavior of the 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?

The description is a single sentence with no filler, achieving maximum conciseness. It is appropriately sized for a simple operation and the key action is front-loaded. However, the extreme brevity results in under-specification, which slightly detracts from structural quality.

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

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

Given no annotations, no output schema, and only 25% parameter schema coverage, the description is grossly incomplete. It does not explain the required parameters, preconditions, success criteria, or any side effects. An agent cannot reliably invoke this tool correctly based on the provided information alone.

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

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

The schema description coverage is only 25% (only 'binding_token' has a description). The tool description does not mention any parameter, nor does it clarify the meaning or relationships between 'lease_id', 'generation', 'lease_seconds', and 'binding_token'. It fails to compensate for the low schema coverage, leaving the agent to guess at parameter semantics.

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

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

The description clearly states the action (renew) and the target (a resource lease held by the caller). It includes a relevant constraint (held by the caller) that adds specificity. However, it does not distinguish itself from the sibling tool 'renew_lease', which likely serves a similar purpose, so it lacks clear differentiation.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., having claimed the resource first) or the relationship to 'claim_resource' and 'release_resource' tools. The agent is left to infer usage 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?

With no annotations present, the description carries the full burden, and it delivers meaningful behavioral context: cancelled tasks are preserved in history, plan_version is incremented, and no nodes or edges are deleted. It does not cover reversibility or return behavior, but it clearly establishes the destructive scope.

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 two tight sentences, front-loaded with the tool's purpose, and every sentence conveys distinct information. No filler or redundancy.

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

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

Given no annotations and no output schema, the description is too thin to fully support correct invocation: it omits the required reason semantics, task dependency fields, and any guidance on when a formal replanning event is appropriate. The behavioral safety notes are helpful but do not make the tool 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?

Schema description coverage is 0%, so the description needed to compensate, but it never names reason, drop_task_ids, or new_tasks. It gives some conceptual meaning via 'cancels specified tasks' and 'optionally adds new tasks', but leaves the required reason parameter entirely 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 clearly defines the operation: a formal replanning event that cancels specified tasks and optionally adds new tasks at an incremented plan_version. It is specific and distinct from generic task editing, though it does not explicitly name or differentiate 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?

No guidance is given about when to invoke replan versus alternatives such as update_task or plan_session. The phrase 'formal replanning event' implies a use case, but there is no explicit when/when-not guidance or prerequisite information.

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 of behavioral disclosure, but it only says the tool 'applies' a resolution. It does not disclose whether the conflict is removed, updated, marked as resolved, requires permissions, or 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?

The description is only two sentences and front-loads the main purpose. The second sentence mostly repeats values already visible in the schema enum, so it adds limited new information, but overall the structure remains tight and scannable.

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

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It does not explain what 'a' and 'b' refer to, what happens after resolution, or what the return value indicates, leaving an agent to guess at the behavior and 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%, so the description must compensate, but it only restates the enum values without defining what a_supersedes_b, b_supersedes_a, both_provisional, or dismissed mean. It adds minimal context for contradiction_id by calling it a 'queued FACT conflict from the contradictions table' but leaves notes and the meaning of the resolution options unexplained.

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

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

States a specific verb ('resolve') and a specific resource ('queued FACT conflict from the contradictions table'). The description makes the tool's domain and scope clear, distinguishing it from fact-recording and other workflow tools.

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

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

The intended context is implied by 'queued FACT conflict' and the enumerated resolution types, but there is no explicit statement of when to use this tool versus any alternative. No competing resolution tool is mentioned, and no exclusion conditions are provided.

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

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

The description conveys the primary behavioral effect—marking something as resolved—and the same-thread constraint. However, with no annotations, it carries the full burden and does not disclose side effects, permission requirements, idempotency, or validation 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?

One focused sentence with no filler. The action, target, and constraint are all front-loaded, and every word earns its place.

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

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

With no annotations, no output schema, and low schema description coverage, the description remains too sparse to fully support confident invocation. It omits usage direction, side effects, and specific parameter interplay, leaving meaningful gaps for the agent.

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

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

The description helps map message_id to the 'question/request' and resolution_message_id to the 'message in the same thread,' adding meaning beyond the titles. Binding_token already has a supportive schema description, so overall parameter meaning is adequate but not fully explicit.

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 ('mark resolved') applied to a specific resource ('a question or request') and adds the same-thread constraint. It clearly distinguishes this from siblings like resolve_contradiction and close_thread.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as resolve_contradiction, close_thread, or update_task. The same-thread phrase hints at a prerequisite, but the agent is left to infer the full decision context.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It reveals that the action records a result, implying a side effect, but does not mention irreversibility, one-time use, nonce validation, or what happens if the data does not match the commitment.

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 compact sentence with no redundant content and places the primary action first. It is efficient, though it could be even stronger with structured guidance on the commit-reveal flow.

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

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

For a tool with 5 parameters, no annotations, and no output schema, the description is under-specified. It omits return behavior, failure modes, and prerequisite commitment state, so an agent cannot fully predict invocation consequences.

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 only 20%, and the description adds no parameter-specific detail beyond implying that 'data' must match the commitment. The nonce and commitment_id semantics are left entirely to the schema, so the description does not compensate for the low coverage.

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

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

The description states a specific verb ('Reveal') and resource ('data matching a prior commitment') plus a secondary action ('record the result'). It clearly differentiates from siblings like commit_result by referring to a prior commitment, though it does not name an alternative explicitly.

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

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

The phrase 'prior commitment' implies the tool should be used after a commitment has been made, which gives a clear contextual cue. However, it does not state when to avoid this tool or mention alternatives such as commit_result, leaving usage boundaries 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without explaining side effects, required permissions, reversibility, or what happens to the member's existing tokens or capabilities. This is a mutating operation but lacks the transparency needed for safe invocation.

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 one-sentence description is concise and front-loaded with the verb and resource, but it is so minimal that it borders on under-specification rather than disciplined brevity. It earns its place but leaves the reader wanting structural detail that close to the definition could have provided.

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

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

The tool has one unexplained required parameter and no output schema, yet the description omits critical context such as return values, side effects, required permissions, or how a membership is identified. In its current form it is not complete enough for an agent to invoke confidently without external knowledge.

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 only 50%; the required membership_id has no description in the schema, and the tool description does not meaningfully clarify it beyond restating that it relates to a campaign membership. The binding_token is already described in the schema, so the description adds no additional parameter-level value.

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 ('Revoke') and resource ('campaign membership capability'), and it clearly differentiates itself from sibling tools like invite_member and join_campaign by indicating the inverse/removal operation. It could be more concrete about whether the member is fully removed or only loses a capability, but the intent is broadly discoverable.

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 guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or the relationship between revoke_member and invitation/join flows, leaving the agent to infer usage entirely from the tool name and one-line description.

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 does state the main side effect (a message is posted to a thread as the calling agent) and two hard constraints (size cap, server-only kind). However, it does not mention whether the send is durable, how subscribers/visibility are affected, error conditions, permission requirements, or whether sending is idempotent.

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

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

The description is compact: two sentences that state the core action immediately and surface the most critical constraints. There is no filler or repetition.

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

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

With 16 parameters, no annotations, and no output schema or error semantics, a two-sentence description is not sufficient for an agent to confidently use all capabilities. The cap and kind restriction are useful, but key behaviors around enums like authority, trust_class, and visibility remain 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?

Given only ~2 of 16 parameters are meaningfully documented by the schema, the description adds semantic value only for body size routing and kind='system'. Fields like authority, trust_class, visibility, deadline_at, requires_ack, and refs are left largely unexplained in the description, so the agent must guess at their effect.

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 precise action ('Post a MESSAGE to a THREAD'), identifies the agent as the caller, and clearly distinguishes this from sibling tools like create_thread or record_structured_result. The intent is immediately unambiguous.

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

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

The description gives an explicit routing rule: messages over 16 KiB should go to record_structured_result with a refs pointer, and kind='system' is server-only. It does not contrast with other sibling tools or state when to prefer one kind/authority over another, but the key alternative is covered.

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 present, the description carries the full behavioral burden. It discloses the asynchronous execution model, side effect of creating WORKER nodes, and the fact that caps/unknown providers surface as 'refused' rather than errors. This is strong, though it does not cover every edge case such as idempotency or retry behavior.

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

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

Three tight sentences front-load the core action and then layer critical constraints. Every sentence contributes essential information: what happens, how it happens asynchronously, and what token/error behaviors to expect.

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

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

Given no output schema and no annotations, the description plus the detailed input schema gives an agent enough to invoke the tool correctly. It explains the async result routing and token requirements, though it remains silent on the immediate return shape and how to later consume the recorded STRUCTURED_RESULTs.

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 description adds meaning around token exclusivity, which is useful because the schema does not mark the tokens as mutually exclusive. However, it does not explain the workers array structure, workflow_id role, or binding_token semantics beyond what the schema already provides, and schema coverage is moderate at 67%.

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 target ('Fan out to configured local providers') and further clarifies it creates WORKER nodes in spawn_state='requested'. This clearly distinguishes it from sibling tools like register_worker or list_spawned by focusing on the asynchronous fan-out action.

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 clear context: this tool spawns workers asynchronously, and it states the token prerequisite ('Requires exactly one of spawn_token or child_token'). It does not explicitly name alternative tools or when-not-to-use conditions, but the behavior is specific enough that an agent can infer when to select it.

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

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

With no annotations, the description must carry the behavioral burden. It does state 'Read-only,' which is a useful safety signal, and it reveals that gpu.lock state is compared with lease claimants. However, it omits details like server-host file reads, permission requirements, output shape, and failure behavior; the schema's top-level note supplies some of this 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?

The description is one compact sentence plus 'Read-only,' with no filler. The four report categories are front-loaded, and every phrase contributes to the agent's understanding.

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 required parameters, the description plus the schema's defaults and top-level explanation are mostly sufficient for a zero-argument call. It is not fully complete because there is no output schema and no guidance on how scope or staleness thresholds change the result, but the combination is adequate for this tool's complexity.

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 only 20%, and the tool description does not compensate by explaining scope, worker_stale_s, gpu_lock_dir, gpu_task_ids, or binding_token. The input schema carries the real parameter meaning, especially in its top-level description, so the tool description itself adds little value beyond hinting that gpu.lock and leases are involved.

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 the verb 'List' and names four concrete output categories: stale running workers, leases whose claimant is gone, a mismatched gpu.lock, and watchers of finished jobs. It also says 'Read-only,' which separates it from mutation-oriented sibling tools. The purpose is unmistakable and not a tautology of the tool name.

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

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

The description explains what the report contains but gives no guidance on when to choose stale_report over alternatives such as protocol_health or the worker/watch listing tools. There are no conditions, exclusions, or explicit use cases, so the agent must infer when this tool is the right choice.

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 creating side effect and the follow-up protocol (register workers, store results), which is meaningful. However, it omits other behavioral traits an agent might need: what the call returns (a workflow id to pass to register_worker?), whether creation is idempotent, what happens on name collision, and whether it runs asynchronously.

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