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

With no annotations, the description carries the behavioral disclosure burden. It usefully reveals that cancellation does not undo edits and works during clarification waits, but it does not disclose whether cancellation is reversible, whether completed tasks can be cancelled, or any other state-change side effects.

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

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

The description is extremely concise, front-loads the core action, and each sentence adds value. The second sentence prevents a likely misinterpretation about undoing edits.

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 one-parameter tool with an output schema, the description is mostly complete: it states the action, a special case, and a key non-effect. It falls slightly short only by not addressing cancellation permanence or behavior on already-completed tasks.

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 input schema has a single task_id parameter with no description, and the tool description does not explain its format, origin, or usage. The parameter is self-explanatory by name, but the description adds no explicit parameter-level meaning despite 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 ('Stop a task') and adds a meaningful nuance about stopping while waiting for clarification. This clearly distinguishes it from sibling tools like start, continue, wait, and 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?

The description gives clear context for when to use the tool: to stop any task, including one waiting for clarification. It also notes a relevant limitation ('Does not undo edits'), but it does not explicitly name alternatives or state 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?

With no annotations, the description carries the full burden and does it well: it discloses that polling remains available, that watchdog_token must reflect an actual independent hook wake, that recover never changes task outcomes or reruns work, and that token-file contents are secret. It does not fully spell out state-changing effects like whether an ack consumes the event, leaving a small transparency gap.

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

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

The description is front-loaded with an overview, then delivers one compact clause per action with caveats attached to the relevant operation. Every sentence earns its place, including the final security note about token-file contents. There is no filler.

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

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

The description covers most of the tool's complex behavior and an output schema exists, so return-value documentation is not required. But the 'status' action in the enum is never explained, and 'limit' is undocumented. For a 7-parameter, 5-action tool with no annotations, these are meaningful gaps.

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

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

Schema coverage is 0%, so the description must compensate. It successfully connects probe_token, watchdog_token, event_id, task_id, include_previous, and the action values to their behaviors. However, the 'limit' parameter is never mentioned, and the allowed ack combinations are implied rather than 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 opening sentence names a specific verb and resource: 'Manage optional Claude Code Channels push delivery' and contrasts it with 'ordinary polling.' It is clear and not tautological, but it does not name or distinguish any sibling tool, so it stops 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?

The description gives concrete per-action conditions: probe is for a receipt challenge, ack confirms via probe_token/watchdog_token/event_id, pending lists unacknowledged events, and recover replays event_id or task_id. It does not explicitly name alternative tools or say when not to use this tool, but the action-level context is clear enough to guide an agent.

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

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

With no annotations, the description carries the full burden and discloses highly non-obvious state semantics: history/base policy/mode/cwd persist, old goals/acceptance do not, the product snapshot stays pinned unless explicitly changed, and the question timeout is inherited unless overridden. This is exactly the behavioral context an agent needs before invoking a continuation 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?

Around 60 words, with the primary action and the one critical rule in the first sentence, followed by terse, high-value persistence notes. Every sentence earns its place and nothing is redundant.

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 stateful 9-parameter tool with no annotations, the description covers core continuation semantics (what persists, what resets, snapshot pinning, timeout inheritance) and routes the waiting_input case to tandem_reply. It does not explain the optional execution or review-related fields, but the output schema and nested property descriptions cover return values, leaving only a moderate gap.

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

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

Schema description coverage is reported at 0%, so the description must compensate; it usefully clarifies the prompt/contract mutual exclusion and timeout inheritance. However, it leaves several parameters (execution, review_id, review_stage, project_context_id) without explanatory text, and the input schema itself supplies most of the remaining structured constraints. The contribution is meaningful but 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 opens with a concrete action ('Start a NEW current goal') and the condition 'after completion', which clearly separates it from tandem_start and similar siblings. It also explicitly names tandem_reply for the waiting_input case, so the tool's scope is unmistakable.

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

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

It states when to use the tool ('after completion') and gives an explicit exclusion ('For waiting_input use tandem_reply'). It also imposes the critical selection rule 'supply exactly one of prompt or turn contract.' It does not enumerate every sibling alternative, but the central routing guidance is present.

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 behavior. It discloses that live=true contacts a provider, may incur a charge, defaults to local state, returns a task_id when still running, and that a separate CLI process cannot certify the push receipt. This is strong behavioral disclosure.

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

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

The description is compact and front-loaded, with the main purpose in the first sentence and operational constraints in the next three. Every sentence adds necessary information; there is no filler or repetition of schema 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?

The output schema presumably covers return values, and the description covers the core behavior and safety considerations. However, the missing semantics for three parameters and lack of routing among sibling tools leave the description incomplete for a tool with this many controls.

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

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

Schema description coverage is 0%, so the description must compensate. It explains live and task_id, but wait_seconds, timeout_seconds, and expected_project are left undocumented. An agent cannot fully understand how to set or interpret these parameters from the description 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 starts with 'Diagnose this client session's project, OMP execution, actual model and delivery,' which names a specific action and target. It is clear what the tool does, though it does not explicitly differentiate it from sibling tools like tandem_review or tandem_findings.

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 clearly explains when to use live=true versus the default local check, and instructs the agent to inspect an existing task_id instead of starting another check. It provides useful context but does not name alternative sibling tools or explicit when-not-to-use conditions beyond live checks.

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?

Although annotations are absent, the description reveals important behavioral traits: the transfer_id is a private capability rather than a public link, the operation grants no permissions, and no tasks/history are shared. This is precisely the kind of context an agent needs beyond the bare 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?

The description is compact and front-loaded: the core purpose comes first, followed by usage constraints, privacy implications, and security caveats. Every sentence earns its place with no fluff 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?

Covers purpose, when to use, security, return value semantics, and the follow-up action on the recipient side. The main gap is the lack of explicit parameter documentation; otherwise, an agent would have enough context to invoke the tool safely and understand the result.

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

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

Schema description coverage is 0%, and the description does not explicitly explain the two required parameters. 'context_id' and 'target_project_root' are somewhat inferable from their names and the surrounding text, but the description never states how to obtain context_id, what format target_project_root should take, or how they map to the described behavior.

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

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

The description opens with a specific action ('Explicitly offer') and a clear resource ('this project's selected rules and referenced evidence') directed at 'one recipient.' It also distinguishes itself from tandem_import_context and siblings by describing what it does and does not do.

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

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

Gives an explicit usage condition: 'Use only when the user intends cross-project sharing.' It also clarifies that no tasks/history are shared and that the recipient must separately call tandem_import_context, which prevents misuse and clearly scopes 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 behavioral disclosure burden and does so well. It discloses that history is immutable, validity and resolution are tracked separately, claimed fixes are not automatically verified, and updates require an expected revision. It does not cover every side effect or status transition, but the most important behavioral traps are surfaced.

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

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

The description is three tight sentences with no filler. The key invariant is front-loaded, and the following sentences deliver high-value operational constraints. Every sentence earns its place.

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

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

An output schema exists, so omitting return-value details is acceptable. The description covers the hardest domain rules around versioning and verification, but leaves list/create parameter selection and the roles of review_id and task_id to inference from the schema. For an 11-parameter tool with no annotations, this 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?

Schema description coverage is 0%, so the description must compensate for 11 undocumented parameters. It adds meaning for expected_revision, finding_id, conversation_id, number, evidence, and verification_task_id, but leaves action, change, finding, task_id, review_id, limit, and offset largely unexplained. This partial coverage is insufficient for a schema of this size.

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

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

The description names a specific resource ('version-bound review findings') and a governing behavior ('without rewriting their history'), which makes the tool's purpose reasonably clear and distinguishes it from the other tandem_* siblings. It does not explicitly enumerate the create/update/get/list actions from the schema, but the core purpose is still identifiable.

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 concrete operational guidance for suboperations: update requires current expected_revision, get uses finding_id or conversation_id plus human number, and verify_fixed needs evidence and a completed verification task. However, it does not explicitly say when to prefer this tool over a sibling such as tandem_review or tandem_result, so cross-tool usage guidance remains 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 behavioral burden and does so well. It discloses that the operation creates fresh local IDs, preserves provenance, does not grant approval, is idempotent on retry, and cannot browse a foreign database.

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

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

Four compact sentences with no filler. The purpose is front-loaded, and the remaining sentences each add a distinct, useful constraint or behavioral note.

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 an output schema already present, the description covers all critical invocation details: import scope, provenance handling, revision expectations, idempotency, and the non-approval side effect. An agent has enough information to use it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explicitly explains expected_revision ('Existing product revisions require expected_revision') and implies transfer_id from 'recipient-bound exports' and 'Retrying one transfer.' However, transfer_id is never named or formally defined, leaving a minor ambiguity.

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

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

States a specific verb and resource: 'Explicitly accept a product snapshot offered to this launch project.' The description also distinguishes the tool from browsing or generic import by noting that only recipient-bound exports can be imported and no foreign database is browsed.

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

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

Provides clear context about when the tool is appropriate: importing only recipient-bound exports, requiring expected_revision for existing revisions, and supporting idempotent retries. It does not explicitly name sibling alternatives or say 'use this instead of X,' but the constraints effectively delineate the correct use case.

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 full behavioral burden. It clearly discloses that the tool returns lightweight metadata fields and deliberately omits large bodies. It does not mention ordering, recency semantics, or side effects, but 'List' strongly signals a read-only 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?

A single front-loaded sentence with no filler. Every element—'recent', the listed fields, and 'without large bodies'—contributes directly to the tool's behavior and selection.

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 one-optional-parameter list tool with an output schema, the description is mostly sufficient. However, it lacks explicit usage guidance, does not explain the 'limit' parameter, and relies on the tool name to convey read-only status because no annotations exist. These are real but non-fatal gaps.

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

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

Schema description coverage is 0% and the description never mentions the only parameter, 'limit', so it does not compensate for the missing schema field description. The parameter name and constraints supply some meaning, but the description adds no guidance on how limit affects the returned items.

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

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

States a specific verb ('List') and a precise resource: recent task/conversation IDs, statuses, outcomes, and next actions. The phrase 'without large bodies' clearly scopes it to metadata and distinguishes it from body-oriented siblings like tandem_read_artifact.

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 'without large bodies' implies this is for overviews rather than full content, but it never names an alternative or states explicit when-to-use/when-not-to-use conditions. Siblings such as tandem_read_artifact likely cover the body-heavy case, but that routing is left to inference.

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

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

With no annotations, the description carries the burden and does well: it discloses immutability of published snapshots, the expected_revision requirement, that publishing never changes active tasks, and that workers cannot access this publishing tool. This adds meaningful behavioral context 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?

The description is dense but every sentence earns its place: purpose, action behavior, revision requirement, parameter routing, side-effect guarantee, and permission boundary. The most important information is front-loaded and there is no filler.

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

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

Given the tool's complexity and the presence of an output schema, the description covers the critical invariants and action-specific semantics. Minor omissions are the exact role of the context parameter and the limit parameter, but the schema provides enough defaults and names to make invocation feasible.

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

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

Schema description coverage is 0%, so the description must compensate. It adds semantics for action, expected_revision, context_id, and project_id, and hints at content types through 'rules, examples and settled decisions.' It does not explain limit or the full context object relationship, but the schema names and defaults reduce 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 identifies the tool as coordinator-only product knowledge for source-backed rules, examples, and settled decisions, and names the three actions (publish, get, list). It conveys the resource and its primary operations, though it does not explicitly contrast with siblings like tandem_scope or tandem_publish_artifact.

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

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

It states coordinator-only usage, explains when expected_revision is needed, specifies that get requires an exact context_id, and that list filters by project_id. It also gives cross-tool guidance to pass context_id to tandem_start/continue. It does not name an alternative tool or provide an explicit when-not-to-use instruction, so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and succeeds: it discloses immutability, version-on-republish, a 4MiB UTF8 content limit, and that logical names are not filesystem paths. It also explicitly states 'no file is read or modified,' which prevents a common false assumption about artifact handling.

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

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

The description is three short sentences with the core operation and versioning behavior front-loaded, followed by return guidance and practical constraints. Every sentence earns its place, and there is no redundant or filler 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 publication tool with an output schema, the description covers the essential operational facts: what is published, versioning semantics, how to use the returned artifact_id, content size/encoding limits, and the non-filesystem caveat. The main missing context is clearer guidance on when to use this versus reading or exporting artifacts, but that is a usage guideline gap rather than a completeness failure.

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 meaningful semantics for two parameters: content is limited to 4MiB UTF8, and name is a logical, versioned identifier rather than a filesystem path. However, media_type and conversation_id are left unexplained in both the schema and the description, so the agent must infer their roles from the enum and parameter names alone.

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

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

The description leads with a specific verb and resource: 'Publish immutable shared context,' and immediately clarifies versioning behavior with 'each same-name publication creates a new version.' This clearly distinguishes it as a publication tool from siblings like tandem_read_artifact, tandem_list, or tandem_export_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 usage is implied: you publish a named artifact for a partner, then return artifact_id in a follow-up. However, it does not explicitly say when to prefer this tool over tandem_read_artifact, tandem_export_context, or other siblings, nor does it describe exclusions or alternative conditions.

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

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

With no annotations, the description carries the full behavioral burden. It discloses immutability, Unicode character-based offsets, the limit range, pagination via next_offset, and an important security property that IDs never resolve local files.

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 states purpose and pagination, the second gives parameter semantics and a security caveat. Every sentence earns its place and key constraints 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?

An output schema exists, so return-value documentation is not required. The description covers purpose, pagination behavior, parameter semantics, and security. The only noticeable gap is a lack of explicit guidance on when to prefer this over other read/list siblings.

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

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

Schema description coverage is 0%, so the description must explain parameters. It clarifies artifact_id as a coordinator/OMP-shared immutable artifact ID, limit as 1..50000, and offset as Unicode character count, though it leaves defaults 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?

States a specific verb and resource: 'Read an immutable artifact version shared by the coordinator and OMP'. This distinguishes it from sibling writing/publishing tools like tandem_publish_artifact and from broader listing tools, so an agent can understand what it targets.

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 context is clear: this tool reads immutable artifact versions and paginates with next_offset. It does not explicitly name alternatives or when-not-to-use conditions, but the shared-by-coordinator-and-OMP framing plus the 'never resolve arbitrary local files' caveat provides practical 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 provided, the description correctly carries the behavioral burden. It explicitly discloses that duplicate reads do not authorize repeated effects, stranded claims are never automatically released, claims grant no filesystem/external permissions, and external effects need their own idempotency/transaction boundary. This is substantial behavioral content, though it leaves definitions like 'terminal result' implicit.

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 terse and well-packaged: every sentence adds a distinct rule about claiming, completing, or safety boundaries, and the core for the central purpose is front-loaded. No filler or repetition is present.

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 an output schema, the description covers the lifecycle and several important corner cases. Yet it is cryptic about what a receipt represents in practice, does not define the reported status action, and relies heavily on domain-specific vocabulary without orienting an unfamiliar agent.

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

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

Schema description coverage is 0%, so the description should compensate. It does: 'claim' and 'complete' map to the action enum and 'token' is explained as the outcome of a claim. However, it never mentions the task_id parameter or describes the 'status' action, leaving part of the parameter surface under-documented.

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 indicates the tool coordinates result processing via claim, status, and complete, and says it is separate from reading/acknowledging events. However, the verb 'gate' is vague and the description never states plainly what the tool is or differentiates it from siblings like tandem_result or tandem_review.

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 useful procedural guidance: claim before applying a terminal result, complete with the token after handling, and do not rely on duplicate claims. Still, it never explicitly says when to prefer this tool over alternatives or when not to use it, so the usage guidance is largely 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 and does disclose key stateful behavior: idempotency for identical duplicates, rejection of conflicting second answers, and failure on stale IDs. It does not detail unrelated side effects, but the output schema covers return 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?

Two terse sentences put the core purpose first and then capture edge-case behavior with no filler or repeated schema details. Every sentence earns its place.

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

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

For a simple 3-string tool with an output schema, the description covers the critical invocation context: pending clarifications, stale failures, and duplicate behavior. Minor gaps—how IDs are obtained and where this fits among the sibling tools—are not essential to making a correct 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 description coverage is 0%, but the description adds contextual meaning: IDs must refer to a pending clarification and can go stale, and the 'answer' is the exact clarification response. It never names the parameters explicitly or describes formats, so it only partially compensates for the lack of schema descriptions.

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

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

The description opens with a specific action ('Answer exactly the pending clarification') and identifies the resource: a clarification associated with a task and question. 'Resuming the same worker' adds useful context that separates it from generic start/list tools, though no sibling alternative is explicitly 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?

It clearly indicates the tool is for replying to a pending clarification and notes edge cases where it should not be used ('Expired/stale IDs fail'; a different second answer is rejected). It does not explicitly enumerate alternatives among the tandem_* siblings, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does so well: it warns that 'completed is turn completion, not proof of success', distinguishes 'answer holds the requested text; summary only describes the work', and explains truncation handling. This adds meaningful behavioral context beyond 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?

Three or four compact sentences, front-loaded with the tool's purpose, then precise warnings and routing instructions. No filler or repeated schema boilerplate; each sentence adds new 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 an output schema exists and the safety-relevant behavior is disclosed, the description covers the essential call semantics, truncation path, and details switch. It is only slightly incomplete because task_id provenance is not described and the exact relationship to sibling tools is left implicit.

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

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

Schema description coverage is 0%, so the description must compensate. It adds semantics for details ('details=true includes the full answer/report/contract/diagnostics') and wait_seconds (0..25), but it never explains task_id, the only required parameter, leaving a meaningful 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 opens with a specific action and resource: 'Get the actual answer, work outcome and next_action.' It also distinguishes the tool from siblings by stating questions return immediately and by routing artifact reads to answer_artifact_id, so an agent can tell it apart from tandem_read_artifact and tandem_wait.

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 on when to use the tool ('Questions return immediately', retrieve answer/outcome) and an explicit condition for routing: 'When answer_truncated, read answer_artifact_id.' It does not name sibling tools directly or discuss when tandem_continue/tandem_wait would be preferable, so it is not fully exhaustive.

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 that bundles are immutable, that capture records requirements/checks/boundaries without executing tests, that author rationale is withheld until explicitly revealed, and that reads page from the captured bundle rather than the live working directory. It does not cover permissions, rate limits, or what state create persists.

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

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

The core capability is front-loaded in the first sentence and the remaining sentences are information-dense with little filler. The run-on line-wrapped prose mixing source semantics, capture behavior, and assess scope is less scannable than short labeled lines would be.

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 multi-action, 8-parameter tool with an output schema present, the description covers the operationally important unknowns: source semantics, immutability, non-execution of tests, rationale withholding, and the snapshot-vs-live distinction. Return-value detail is legitimately delegated to the output schema.

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 reported at 0% across 8 parameters, so the description must compensate and only partly does: it explains request.source and review_id but says nothing about path, limit, offset, section, or the check/criteria shapes. It also refers to paging by 'next_offset', a name that does not exist among the input parameters, which risks confusion.

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 opening sentence gives a specific verb set (capture, read, compare) and a well-defined resource (an immutable review bundle), and the action enum semantics (create/read/assess) are spelled out later. It does not, however, differentiate itself from the clearly related sibling tandem_review_run, so an agent must infer the boundary.

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

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

It gives real conditional guidance: request.source selects base-to-worktree by default vs base-to-staged index, staged captures exclude unstaged/untracked content, and review_id can be bound to a think task for snapshot-only review. What is missing is any explicit when-not or named alternative (e.g. tandem_review_run), so the routing is only partly resolved.

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 and does so well: read-only, never edits files or runs supplied test commands, runs an independent review and at most one comparison, default budget, code-assembled outputs, and claims are not automatically accepted. This is unusually rich behavioral disclosure.

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

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

Front-loads the core purpose and then organizes action-specific guidance under start and status/reply/cancel. The text is dense but mostly earns its place; a few clauses are opaque but not wasteful enough to damage clarity.

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

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

For a complex 10-parameter orchestrator with an output schema, the description covers the workflow, budget behavior, context capture rules, and claim handling. It does not fully document every parameter or distinguish sibling tools, but it gives enough to invoke the tool correctly in most cases.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate. It explains action, request_key, request/ReviewRequest, run_id, question_id, and budget_seconds, but leaves answer, compare, execution, wait_seconds, and most nested request fields unexplained, so coverage is only partial.

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

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

States a specific verb and resource: 'Run one read-only review scenario.' The action enum is explained, but the description never explicitly distinguishes this multiplexer from siblings such as tandem_start, tandem_review, tandem_reply, or tandem_cancel, so an agent must infer the boundary.

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

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

Provides clear action-level guidance: start needs a ReviewRequest and stable request_key; status/reply/cancel use the returned run_id; replies need the current question_id; never start again to wait. It does not name alternative tools or state when not to use this tool, but the action usage is well 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, the description carries the burden of disclosing behavior, and it does so well: it states the boundary is immutable, clarifies that data isolation is not an OS sandbox, and warns that execution_profiles reflects defaults rather than effective overrides. It does not explicitly say 'read-only', but 'inspect' plus 'immutable' conveys it.

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

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

The description is compact and front-loaded with the core purpose, followed by three dense clarifications that each prevent a common misinterpretation. No wasted words; every sentence earns its place.

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

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

For a zero-parameter introspection tool with an output schema, the description covers the essential semantics: what scope is, how folder boundaries work, what execution_profiles represents, and what it does not mean (effective settings, OS sandbox). This is sufficient for an agent to invoke it appropriately and interpret results without further context.

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

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

The tool has no parameters, so the baseline is 4. The description adds useful conceptual context about what 'scope' includes—project boundary, launch folders, and profile defaults—which helps the agent interpret any returned fields even without parameter details.

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

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

The first sentence states a specific action and object: 'Inspect the immutable project boundary and available computation profile defaults.' This clearly frames the tool as an inspection utility. It doesn't name sibling tools for contrast, but the term 'scope' plus the 'immutable' boundary and 'defaults' caveats make the purpose 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 direct 'use this when' guidance or reference to alternatives. It does add context about what the tool reports (launch-folder isolation, client-granted directories, defaults vs effective settings), which helps an agent understand relevance, but the agent must infer when to call it relative to siblings like tandem_start or tandem_continue.

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. It discloses immediate return, non-sandboxed work mode, and a permission constraint. However, it omits error handling, side effects, or what happens on invalid input (e.g., both prompt and contract given). This is adequate but not thorough.

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 paragraphs, front-loaded with the core purpose. The mode explanation is efficient and the 'NOT sandboxed' note is critical. No redundancy, though structure could be improved with headers.

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 10 parameters and no annotations, the description is incomplete. It fails to explain the execution sub-object, review parameters, project_context_id beyond a single note, and the overall flow. The output schema covers return values, but parameter semantics are under-specified 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 0%, so the description must compensate. It adds meaning to the mode parameter and clarifies the exclusivity of prompt/contract. It does not explain cwd, execution, review_id, review_stage, timeout_seconds, or question_timeout_seconds (beyond a note). Partial compensation, but significant gaps remain.

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 'Start a task' and the key constraint 'exactly one of prompt or structured contract'. It clearly distinguishes the tool's entry-point role from siblings like tandem_continue and tandem_review, and mentions immediate return.

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

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

Provides context on follow-up behavior ('each follow-up has a new goal and criteria'), explains mode semantics (think/analyze/work), and notes a coordination rule (only the coordinator sets question timeout). It does not explicitly exclude use cases for siblings, but the guidance is clear enough for typical 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 provided, the description carries the full burden of behavioral disclosure, and it does well. It explicitly states that the tool does not acknowledge terminal events, does not rerun work, and should only await events with a live independent watchdogikuha. It also explains that it returns ready IDs/questions, not full answers, which is critical for correct agent behavior. The only minor gap is not detailing side effects on the wait set state beyond removal, but the key behaviors are transparent.

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

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

The description is succinct and well-structured. The core purpose is front-loaded in the first sentence, and subsequent statements efficiently cover key behavior without redundancy. Every sentence adds value, and the language is direct and actionable.

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

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

Given the tool's moderate complexity (2 parameters, no nested objects, but with an output schema), the description is largely complete. It covers the behavioral nuances, references the output schema for return values, and provides clear usage guidance. It could be improved by explicitly clarifying the param semantics as noted, but the description is sufficient for an agent to call the tool correctly.

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

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

Schema description coverage is 0%, meaning the schema's parameter descriptions are empty, so the description must compensate. The description mentions 'task_ids' implicitly through 'selected task' and 'ready IDs', and 'wait_seconds' through the time constraint ('not 25s per task'). However, it doesn't explicitly explain the meaning of task_ids (e.g., what format they should be in) or wait_seconds (e.g., the 25-second max and default 20). For a tool with 2 parameters, the description adds some meaning but not enough to fully compensate for the 0% 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 clearly states the tool waits for any selected task to finish or ask a question, with a specific verb ('wait'), resource ('selected task'), and scope ('ANY...not 25s per task'). It distinguishes itself from sibling tools by positioning the wait behavior and clarifying that it does not return full answers or acknowledge terminal events, which is unique among the 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?

The description provides clear guidance on when to use this tool: to wait for tasks or questions, and instructs to use tandem_result for reading terminal results, tandem_reply for questions, and to remove resolved tasks from later wait sets. However, it doesn't explicitly state when not to use this tool or name alternative siblings for different wait scenarios, so it just misses a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses the plan invariant (one final integration step depending transitively on all others), the operation_id retry-vs-new-request semantics, the need to re-read the card for the current revision before mutating, and that autonomous grants/reconciliation are out-of-band CLI actions. It stops short of stating what happens on a stale revision or permission failures.

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

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

Purpose is front-loaded in the first sentence, followed by short, information-dense sentences grouped by concern (create, later mutations, idempotency, exclusions). No filler, though the telegraphic style occasionally makes the action-to-parameter mapping hard to follow.

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

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

The tool is highly complex (18 actions, nested plan object), and an output schema exists so return values need not be described. The description covers the creation contract, mutation preconditions, and idempotency, but omits the ordered propose/agree/claim/submit/accept lifecycle and stale-revision conflict behavior, which an agent would need for non-create 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 50%, so the description must compensate: it covers action, expected_revision, operation_id, plan, and work_id (create path) meaningfully. But many parameters (condition, blocker_id, submission_id, resolution, commit, note, evidence) are left entirely to the schema, and the description does not explain which of the 18 actions require which of them.

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 ('Maintain') and resource ('one durable shared task and its role-bound checklist'), which tells an agent this is the lifecycle manager rather than a read-only or artifact tool. It does not explicitly distinguish itself from siblings like tandem_review or tandem_wait, so it stops short of a 5.

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

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

Gives clear when-rules: use action="create" with expected_revision=0 and omit work_id; for later mutations fetch the card first and use its current revision; list/get/history need no operation_id. It even cautions that 'waiting observes committed changes, not permission to start an agent.' However, it never says when to reach for tandem_work versus the other tandem_* siblings.

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