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 reveals that this is a tombstone delete: the key disappears from reads/lists but the deletion record is retained in the append-only JSONL. This is useful context, though it does not mention permissions or reverse operations.

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 core action ('Tombstone-delete a key') and packs in the key behavioral detail. Every word earns its place, with no 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?

For a delete tool, the description adequately explains the deletion semantics and the append-only record, covering the main behavioral context. Since there is no output schema, some return-value detail could be added, but the description is fairly complete 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?

The schema already provides descriptions for scope, author, and workspace (75% coverage), leaving only 'key' undocumented. The description does not add further parameter semantics beyond naming 'a key', so it stays at the baseline for high 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 'tombstone-delete' and identifies the resource 'key', clearly distinguishing it from sibling read/write/list tools. It also explains the observable effect: the key disappears from read/list while the deletion record remains.

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

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

Usage is implied by the tool name and description, but there is no explicit guidance on when to use this tool versus alternatives such as moa_board_write or moa_board_wait. No exclusions or prerequisites 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?

With no annotations, the description carries the full burden. It accurately discloses the output format and the absence of values, which is critical. The term 'browse' implies a read-only operation, but it does not explicitly state that the operation is non-destructive or has no side effects.

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

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

A single, front-loaded sentence communicates the tool's purpose and key behavioral detail ('no values') without waste. It is appropriately sized for the tool's simplicity.

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 list tool, the description covers the core behavior and return fields, which is crucial given no output schema exists. It lacks details on pagination or limits, but the simplicity of the tool makes this acceptable.

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 already provides 100% coverage for both parameters with clear descriptions. The tool description adds no additional parameter context, so the baseline of 3 is appropriate.

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 lists blackboard keys with metadata (key, author, ts, tags, bytes) and explicitly excludes values. This specific verb and resource distinguish it from moa_board_read, which likely retrieves values.

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 'lightweight browse' implies a quick way to see keys without fetching values, but no explicit guidance is given on when to use this tool versus moa_board_read or other board tools. No when-not-to-use conditions are mentioned.

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 full burden. It discloses live read semantics, the absence of deleted keys, the filtering logic, and result ordering/cap. This provides substantial behavioral transparency for a read operation, though it doesn't describe the entry shape or error conditions.

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

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

The description is three crisp sentences with no wasted words. It front-loads the primary action, then uses a logical structure to explain filtering modes and output ordering. 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?

Given the 5-parameter schema and lack of output schema, the description covers core behavior, filtering modes, and limit semantics. It does not specify the structure of returned entries or behavior when both key and tag are provided, but overall it is reasonably complete for a read tool.

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

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

Schema description coverage is 60%, but the description adds essential meaning to the undocumented 'key' and 'tag' parameters by explaining how they filter results. It also reiterates the limit behavior, providing value beyond 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 clearly identifies the tool as reading live entries from the blackboard, with a specific verb and resource. It distinguishes itself from sibling tools like moa_board_write, moa_board_delete, and moa_board_list by describing its read/filter behavior and noting that deleted keys never appear.

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 explains the three usage modes (with key, with tag, with neither) and the ordering/limit behavior, giving strong context on when to use each mode. It does not explicitly mention alternatives or exclusions, but the use cases are clearly 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, the description carries the full burden and does well: it discloses the polling behavior, return contract (ready, timeout, closed), default 25-minute safety cap, the MOAMCP_WAIT_CAP_MS environment variable, timeoutMs override, and the archived-scope case. This is comprehensive for a wait 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?

Two dense sentences front-load the core purpose and then compactly detail return statuses, timeout behavior, and tuning. No filler words or repetition of 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?

No output schema exists, so the description supplies the return statuses and their conditions. It covers timeout, archived scope, and configuration variables, providing enough context for an agent to invoke and interpret the result correctly.

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

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

Schema coverage is 80%. The description adds value by clarifying that the key must have a value to wake, and it supplements timeoutMs with the environment variable and default cap context that the schema does not include. The 'since' semantics are already well described in 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 the tool performs long-polling until a key has a value, or until the entry is strictly newer than a given since timestamp, and it lists the distinct return statuses. This clearly separates it from sibling board read/write/list/delete tools, which are immediate operations.

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 makes the use case explicit: block until a board entry exists or updates. It mentions the timeout cap and tuning options, but it does not name alternative tools (e.g., moa_board_read for immediate reads) or explicitly state when not to use 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?

Since no annotations are provided, the description carries the full burden. It discloses last-write-wins per key, the 96KB max value size, and recommends putting large content in files. However, it does not mention return values or error behavior, which is a gap for a write 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?

The description is two sentences, front-loaded with the primary action, and every clause earns its place. It is compact yet covers action, semantics, constraints, and usage guidance without waste.

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

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

Given 6 parameters, no annotations, and no output schema, the description covers the core purpose, usage context, and key behavioral traits. It lacks info on return values, but for a write tool with strong guidance and schema coverage, this is a minor 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 coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining 'last-write-wins per key' and advising to 'put large content in files and reference them', which provides practical guidance for the value parameter. Other parameters are sufficiently documented in 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 clearly states the tool's function: 'Write an entry to the shared blackboard' with the added 'last-write-wins per key' semantics. It distinguishes itself from sibling board tools (read, delete, list) by specifying the write operation and its overwriting behavior.

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?

Explicit guidance is provided: 'Use the blackboard for contracts/decisions/status/pointers across agents and sessions; one-shot instructions belong in dispatch prompts instead.' This clearly states when to use the tool and when not to, naming an alternative 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 burden and discloses key behavioral traits: the exact files written, the logsDir default and override, task closure, and waiter wake-up behavior including board waiters receiving {status:'closed'}. It does not mention error handling or idempotency, but the core side effects are thoroughly covered.

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

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

The description is one long sentence but is dense with necessary information: file list, default and override for logsDir, task closure, and waiter behavior. It avoids fluff, though splitting into two sentences would improve 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 single-parameter tool with no output schema, the description covers all major aspects: archive file writes, directory resolution, task closure, and waiter notifications. It omits error cases and idempotency, but these are less critical for a simple completion tool.

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

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

Schema coverage is 100% and task_id is described as 'MOA task id'. The tool description adds the detail that task_id is embedded in the output path template, which is a slight enhancement, but it does not significantly deepen understanding 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 uses specific verbs and resources: 'Write the archive', 'close the task', 'wake remaining waiters'. It clearly defines the tool's role as finalizing a task by archiving files and notifying waiters, distinguishing it from siblings like moa_submit_turn or moa_status.

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 the completion step for a task, but it does not explicitly state when to use it (e.g., after all turns are submitted) or mention alternatives. It provides no explicit 'when not to use' or comparisons to sibling tools, leaving the decision 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 fully discloses key behaviors: content is unchanged, the handoff is hidden from the inbox, only pending handoffs are valid, invalid transitions error, and handoffs are never part of recall/indexing. This provides strong transparency about side effects and constraints.

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, front-loaded with the primary action, and every sentence adds meaningful behavioral context without wasted words.

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

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

For a simple archive operation, the description covers the essential context: state transition legality, visibility, and indexing behavior. No output schema exists, but the tool's return value is not critical given the clear side-effect description. It could mention what the API response contains, but overall it is sufficiently 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 100% and parameter descriptions are already detailed (id format, actor meaning, workspace scope). The tool description adds no additional parameter-specific information, so the baseline of 3 applies.

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

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

The description clearly states the tool's action: 'Archive a pending handoff (terminal state) without changing its content' and notes it becomes 'hidden from the default inbox view afterwards.' This specific verb+resource combination distinguishes it from sibling tools like consume or read, which have different effects.

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: it applies to pending handoffs and enforces the legal transition 'pending → consumed | archived,' implying it should not be used for already-consumed or archived handoffs. However, it does not explicitly name alternative tools, so it lacks full when-to-use-vs-alternatives 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 takes on the full burden and discloses key behavioral traits: terminal state, consumedAt recording, legal transitions with error behavior, and non-participation in recall/indexing. It doesn't address reversibility explicitly, but 'terminal' strongly implies irreversibility.

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, no filler, front-loaded with the main action and followed by necessary constraints. Every clause contributes.

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 state-transition tool with no output schema, it provides essential context: target state, valid transitions, error conditions, and indexing exclusion. It doesn't describe return values, but that's a minor gap 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?

All parameters are already documented in the schema (100% coverage), so the description adds no extra parameter-level detail. Per baseline, schema covers the semantics; no compensation needed.

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 the action clearly: 'Mark a pending handoff consumed' with specific effects (terminal state, records consumedAt). Also distinguishes from sibling handoff tools by specifying legal state transitions and the no recall/indexing behavior.

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 when-to-use constraints: only pending handoffs can be consumed, and 'anything else errors'. However, it doesn't name sibling tools like moa_handoff_archive as explicit alternatives, so slightly short of perfect 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?

No annotations are present, so the description carries full responsibility. It discloses return fields (id/title/summary/state/fromProject), no context, newest-first ordering, hidden archived rows by default, exact matching semantics, empty result for misspelled addresses, and that handoffs never participate in recall/indexing. This is thorough 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?

Four dense sentences, front-loaded with the main purpose. Each sentence provides meaningful detail (metadata, defaults, v2 filtering, indexing). The density is appropriate for the tool's complexity, though a slight bullet structure could improve scannability.

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

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

With no output schema, the description defines the return shape by listing metadata fields and explicitly stating no context is included. It covers default filtering, exact state/agent matching, and error behavior. While it doesn't mention limit pagination, the schema handles that, making the description sufficient.

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 agent, workspace, and limit, but the description adds critical semantics absent from schema: state's default filter behavior (archived hidden), the v2 agent address behavior with empty-inbox error handling, and workspace scope clarification ('never infer a workspace from the MCP process cwd'). These additions go beyond the 75% 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 opens with a specific verb and resource: 'List handoffs addressed to the current project'. It clearly distinguishes from sibling tools like send, read, consume, and archive by focusing on listing. It also includes ordering and metadata scope, leaving no ambiguity about what the tool does.

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

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

Provides explicit filtering guidance: archived rows hidden by default, pass state to filter exactly, and pass agent for toAgent filtering. It warns about misspelled agent addresses returning an empty inbox. It doesn't explicitly name alternative tools for 'when not to use', but the sibling names make this 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 provided, the description carries the full burden of behavioral disclosure. It discloses the null return for unknown IDs and the fact that handoffs never participate in recall/indexing. While it does not explicitly state that reading has no side effects, the verb 'Read' and the distinction from consume/archive make this reasonably clear.

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, front-loaded with the action and scope. Each sentence adds unique value: the first describes what is read, and the second explains null behavior and the non-indexing property. There is no wasted text.

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 tool with two parameters and no output schema, the description covers the essential behaviors: reading a complete handoff, returning null for an unknown ID, and exclusion from recall/indexing. It could further detail the return structure, but the description is adequate 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 coverage is 100%, so the baseline is 3. The description reinforces that 'workspace' is the inbox scope but adds no new parameter-level meaning beyond what the schema already provides.

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's action (read) and resource (one complete handoff from the current project's inbox), including the context payload. This explicitly distinguishes it from sibling handoff tools like send, inbox, consume, and archive, which have different purposes.

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 scope ('current project's inbox') and notes that returns null for unknown IDs, helping the agent know when this tool is appropriate. It does not explicitly name alternatives or exclusions, but the read vs consume/archive distinction is implied by the tool name and 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, the description fully discloses behavioral details: storage path ('handoff/<id>'), fromProject derivation, agent-level tagging and filtering, the silent-misspelling compromise, and the pull-on-demand consumption model. This goes far beyond basic expectations and helps the agent understand side effects and limitations.

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 relatively long but front-loaded with the primary purpose. Every sentence contributes necessary information (storage, addressing, limitations, non-indexing). It could be more terse, but given the complexity of the handoff semantics, the length is justified and well-organized.

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 annotations or output schema, the description is remarkably complete. It covers the write path, agent addressing, failure mode (misspelled addresses), and non-indexing behavior. The only minor gap is lack of any mention of return value or acknowledgment, but that is not critical for 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 coverage is 100%, so baseline is 3. The description adds meaning for parameters like toAgent/fromAgent (v2 addressing, opaque shape-checked, no registry) and context (96KB cap), plus the 'user-global' option for toProject. It doesn't extensively elaborate on workspace, but the schema already defines it; overall it adds real semantic 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 clearly states the tool's purpose: 'Send a directed handoff ... into the TARGET project's inbox.' It identifies the specific verb (send), resource (handoff), and target (toProject or user-global), distinguishing it from sibling tools like moa_handoff_inbox, read, consume, and archive.

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 context for when to use this tool (directed handoff vs. other messaging or persistence tools) and explicitly notes exclusions: 'Handoffs never participate in recall/indexing and never merge projects.' It doesn't name alternative tools, but the behavioral constraints effectively guide when to choose this over board_write or recall-based 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?

No annotations provided. Description indicates it creates state and returns a specific structure, but does not disclose side effects, idempotency, or auth requirements.

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

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

Two sentences, each valuable. First defines purpose, second details return and usage. No wasted words.

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

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

Given no output schema and nested objects, description sufficiently covers initialization purpose and follow-up usage. Could mention validation or prerequisites.

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 both parameters with descriptions. The description adds value by explaining the return's agents structure and how to use binding_slot, which is not in 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?

Clearly states the verb 'Initialize' and resource 'task state', specifying the inline preset config. Distinguishes from sibling tools which are subsequent debate steps.

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?

Implied as the first step in the workflow, but no explicit when-to-use, when-not-to-use, or alternatives mentioned.

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 full behavioral burden. It discloses read-only status, defines scope (every registered workspace and registry project), and warns about the MOAMCP_HOME environment variable requirement with the 'silently breaks' failure mode. This is strong but stops short of describing the return data format.

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 plus a warning. The first sentence states purpose, the second gives usage guidance, and the warning adds essential operational context. Every clause earns its place; no wasted words.

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

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

For a zero-parameter, no-output-schema tool, the description covers purpose, usage, and a critical environmental failure mode. It is sufficient to select and invoke correctly. Minor omission: no explicit description of return fields, but 'look up a target projectId' implies the output contains project IDs.

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 zero parameters and the schema is empty, so schema coverage is vacuously 100%. Baseline for 0 params is 4. The description adds semantic value by linking the discovered projectId to the workspace path used by handoff tools, enriching the meaning of the tool's output even though it has no input 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 'Read-only aggregate for cross-harness project discovery: every registered workspace and registry project in this MOAMCP_HOME' – a specific verb (aggregate/list) and resource (workspace/registry projects). It clearly distinguishes from sibling handoff tools by positioning itself as the lookup step before a handoff.

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 'Use it to look up a target projectId before sending a handoff', providing a clear when-to-use instruction. It also clarifies that 'workspace = the absolute project path you pass to handoff tools', which orients the agent to how the results feed into sibling 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 provided, the description must fully disclose behavioral traits. It reveals the initial state and reference results passing, but omits critical facts such as side effects, idempotency, error handling, or what happens if the tool is called multiple times. The description lacks depth for a mutation tool.

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

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

The description is a single, well-structured sentence with no wasted words. It front-loads the key information about the state machine initialization and reference results. It perfectly balances brevity with informativeness.

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 no output schema, the description does not explain what the tool returns or how to interpret the result. It also does not mention any side effects or interaction with other debate tools. For a tool that likely produces an output (e.g., a debate ID or status), this is a significant 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?

The schema already describes both parameters (100% coverage). The description adds context for reference_results by stating they are 'passed through to agents as context,' which clarifies their role beyond the schema's generic description. This adds meaningful value for an agent selecting 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 clearly states that the tool seeds the debate state machine with specific initial values (turn:1, round:1, speaker: first agent) and reference results. The verb 'seed' and explicit state machine details make the purpose unambiguous and distinguish it from siblings like moa_init or moa_submit_turn.

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 that this tool is used after preparing reference results and before agents start debating, but it does not provide explicit guidance on when to use it versus alternatives like moa_init. There is no mention of prerequisites, exclusions, or sequence relative to sibling 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?

No annotations are provided, so the description carries the full burden. It discloses the returned information (port, mode, tasks, process info) which is sufficient for a read-only status tool. Side effects are not mentioned but are likely absent.

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: the first briefly states what it does, the second provides a specific usage. No wasted words, 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?

The tool is simple (no params, no output schema). The description explains the return value and a key use case. It could mention that it's a snapshot, but overall it's complete enough for an agent to invoke correctly.

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

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

There are no parameters, so schema coverage is 100%. The description adds context about what the output contains, which is helpful. Baseline for zero parameters is 4, and this meets 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 clearly states the tool retrieves current Bus status including port, mode, active tasks, and process info. It distinguishes itself from sibling tools (moa_init, moa_start_debate, etc.) which are action-oriented, not status-oriented.

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 explicitly says 'Use this to discover the Bus port for the debate card URL,' giving a specific use case. It does not mention when not to use or alternatives, but the sibling tools are all different actions, so usage is 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 full burden. It transparently explains the data sources, output ordering, default cap, and the possible 'source' values ('local', 'remote', 'local-empty'), emphasizing that the state is 'always explicit, never silently stale'. This is strong transparency, though it doesn't mention potential errors or side effects.

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

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

The description is dense but well-structured, front-loaded with the core purpose. Each clause adds value (data sources, ordering, cap, source values). It is longer than the high example but still efficient and free of fluff.

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

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

With no output schema, the description explains the return value reasonably well: aggregate counts, per-agent snapshots ordered by lastSeen, and the cap. It also covers the edge case of 'local-empty'. It could be more explicit about the exact fields in per-agent snapshots, but overall it provides enough context for an agent to understand what to expect.

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 100%, so the baseline is 3. The description adds meaningful nuance by specifying the default limit (100) and that sessionId is used for filtering, which goes beyond the schema's basic field 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 clearly states the tool's purpose: returning live agent/session status with a specific source ('folded from the CLI homes' session trees... plus the owning Bus's /status snapshot'). It distinguishes itself from siblings like moa_status and moa_tower_status by focusing on agents/sessions and providing detailed output 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 provides clear context on when to use the tool (to retrieve live agent/session status) and gives usage instructions ('pass limit or sessionId to filter'). However, it does not explicitly mention alternatives or when not to use it, so it lacks 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 fully bears the burden. It discloses turn order validation, next-speaker advancement, signoff mechanism, dissent behavior, and early-close conditions. No contradictions or omissions.

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 sentences, front-loaded with the main purpose. Every sentence adds essential information. No redundancy or unnecessary 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?

Despite no output schema, the description fully covers behavior, error cases, and completion conditions. It explains both normal and signoff workflows completely, enabling correct tool 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 coverage is 100%, baseline 3. The description adds extra context: explains content as debate contribution or signoff statement, signoff's effect on early-close, and the role of task_id/agent_id. This goes beyond the 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 clearly states the tool submits the agent's turn content, validates turn order, and advances the speaker. It distinguishes itself from sibling tools like moa_wait_turn and moa_complete by describing its specific role in the debate flow.

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 (to submit turn content) and what happens if used out of turn (error). Explains the signoff option and its implications, implying when not to use signoff (normal submission as dissent). Provides clear context for selection.

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

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

With no annotations, the description carries the burden. It discloses a key behavior: the operation does not alter other content, and the actor parameter identifies the updater in BoardEntry.author. However, it does not mention reversibility, permissions, or side effects, leaving some behavioral 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 sentence with two clauses, front-loaded with the primary action and constraint. Every word earns its place, making it highly concise and well-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?

The tool is simple with 3 parameters and no output schema, and the description covers the core purpose and actor semantics. However, it lacks details about return values, errors, or what 'archive' entails besides preserving content, making it adequate but not comprehensive.

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 workspace is described). The description adds meaning to the actor parameter by explaining its role in identifying the updater, but the id parameter is left to inference. It partially compensates 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 uses a specific verb ('Archive') and resource ('project Tip'), and the qualifier 'without changing its other content' clearly distinguishes it from the sibling tool moa_tip_update, which presumably modifies content.

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 tool is for archiving only, contrasting with updating content, but does not explicitly state when to prefer it over alternatives or provide exclusions. It gives enough context for an agent to infer the use case but lacks explicit 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?

There are no annotations, so the description must fully disclose behavior. It only notes that the workspace must be explicitly selected, but does not describe side effects, required permissions, validation behavior, or what happens on creation. The 'create' action implies mutation but no further details are given.

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 words and is front-loaded with the key action and scope. Every word earns its place, making it highly concise and well-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?

This create tool has 14 parameters, no annotations, and no output schema, yet the description provides only a minimal purpose statement. It does not explain what constitutes a Tip, required fields, workflow implications, or relationship to other tip operations, making it inadequate for the 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 7%; only the workspace parameter has a description. The tool description does not explain the required 'title' and 'summary' fields or any of the 11 optional parameters. It merely reiterates the workspace selection behavior already in the schema, failing to add meaning beyond 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 uses a specific verb+resource ('Create' a 'Tip') and adds scope qualifiers ('project-level', 'explicitly selected workspace'), which clearly distinguishes it from sibling tip tools like read, list, update, archive. This makes the tool's purpose 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?

No guidance is provided about when to use this tool vs alternatives such as moa_tip_update or moa_tip_archive. The description only states the action and scope, leaving the agent to infer usage from sibling names.

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 critical behavior: archived rows are hidden by default (implying an opt-in override). It also clarifies that results are 'lightweight summaries', setting expectations about payload size. It does not mention permissions or rate limits, but for a read/list operation this is acceptable.

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, front-loaded with the primary action and resource. Every word adds value: 'lightweight', 'summaries', 'status/module/tag filters', and 'archived rows are hidden by default' all convey essential information without redundancy. This is model 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 the tool's moderate complexity (7 parameters) and absence of an output schema, the description covers the core purpose and a key default behavior. It could be more complete by specifying what fields a 'summary' contains or mentioning pagination, but the description is adequate for an agent to understand the tool's role within the context of sibling tools.

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

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

Schema description coverage is only 14%, so the description must compensate. It explains the purpose of 'status', 'module', and 'tag' filters, and the 'archived hidden by default' phrase gives meaning to 'includeArchived'. However, it does not clarify the distinction between 'tag' and 'tags', or the 'limit' parameter. Some parameters remain ambiguous despite the description.

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

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

The description uses a specific verb ('List') and clearly identifies the resource ('lightweight project Tip summaries') with filter dimensions (status/module/tag). It distinguishes itself from sibling tools like moa_tip_read by emphasizing 'summaries' and listing filters, and it adds a key behavioral differentiator: archived rows hidden by default.

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 implies when to use this tool (when listing tip summaries by filters). It does not explicitly name alternatives or exclusions, but the context of sibling tools (e.g., moa_tip_read for individual tips) is enough to infer the tool's niche. It lacks explicit 'when not to use' guidance, so it doesn't reach 5.

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

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

The description is minimal but indicates that the tool reads a complete tip and includes context when present. Without annotations, it does not explicitly confirm non-destructive behavior or mention error conditions, but 'Read' implies a safe 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?

Single sentence, 11 words, front-loaded with the verb. Every word earns its place with no redundant 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 read tool with two parameters and no output schema, the description is minimal but conveys the core behavior of returning a complete tip with optional context. However, it lacks details about return shape, error behavior, or prerequisites.

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% (workspace has a description, id does not). The tool description adds no parameter-specific meaning, leaving the 'id' parameter semantics fully undefined beyond its type.

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

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

The description uses a specific verb ('Read') and resource ('one complete project Tip') and distinguishes from sibling tools like moa_tip_list by emphasizing completeness and optional context. It is clear what this tool does.

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

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

There is no explicit guidance on when to use this tool versus alternatives like moa_tip_list or moa_tip_update. The usage is implied by the verb and resource, but no exclusions or alternative references are given.

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

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

With no annotations provided, the description carries the full burden. It discloses two crucial behaviors: atomicity and partial update semantics (omitted fields remain, nullable fields clear when null). This goes beyond a generic 'update' and helps the agent avoid data loss. However, it omits return values, error handling, and permission requirements, leaving some 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 sentence, front-loaded with the verb, and contains no redundant words. It effectively communicates the core behavior in a concise, well-structured manner.

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 15 parameters, no output schema, and no annotations, this description is too brief. It fails to mention return values, error behavior, required vs optional fields, or the meaning of the many parameters. The partial-update rule is helpful, but the overall context is insufficient for an agent to invoke the tool confidently without additional schema inspection.

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 7%, so the description should compensate for undocumented parameters. It provides a general rule about omitted/nullable fields that applies to all parameters, which adds meaning beyond the schema. Yet it does not explain the purpose or semantics of individual parameters like tags, status, or documentRefs, which is a significant gap for a 15-parameter tool.

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

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

The description clearly states the verb ('Update') and resource ('a Tip'), which satisfies the basic purpose. However, it does not explicitly distinguish from sibling tools like moa_tip_archive or moa_tip_create, so it lacks explicit sibling differentiation.

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

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

The description implies the intended use case: updating an existing tip with partial update semantics. It does not explicitly state when to use this tool instead of alternatives or mention exclusions. The atomic/partial-update rule gives contextual guidance but no direct comparison to 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?

With no annotations, the description carries full burden and acquits itself well. It discloses repo validation, board writes, roster registration, idempotency error behavior, directory layout (no .tower/, sibling worktrees), and delegator access restrictions. These are significant contextual behaviors beyond a simple 'boot' statement.

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 each sentence contributes unique information: lifecycle, constraints, directory layout, delegation. It is front-loaded with the core purpose and follows with supporting details. Slightly long but no 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?

For a complex tool with 7 parameters and no output schema, the description covers validation, side effects, lifecycle, directory layout, and parameter restrictions. It doesn't mention return values or success behavior, but that is not required given no output schema. A brief mention of prerequisites like moa_init might improve completeness.

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 100%, so baseline is 3. The description adds meaningful nuance for tower_agent_id (must be a spawned subagent, 'main' rejected) and delegator_agent_id (only moa_tower_send). It also clarifies workspace/repo_root validation. However, it does not mention ci_command or mode, leaving schema descriptions to carry those.

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 verb 'Boot' and resource 'tower workspace for a git repository', then enumerates specific actions: validates repo, writes state docs, registers roster entry. This distinguishes it from sibling tools like moa_tower_plan or moa_tower_merge.

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 provides explicit when-to-use context: 'boot first, then let the orchestrator drive plan/spawn/merge itself'. It also gives when-not: repeated boot errors, 'main' is rejected, and mentions teardown clears the namespace for re-boot. This effectively guides tool selection and sequencing.

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 richly discloses async behavior (immediate return with run_id/started_at/status), the source-of-truth record format, serialization and cancellation semantics (closing session cannot cancel), dirty-worktree interception, log truncation, and merge-gate requirements. With no annotations provided, the description fully carries the burden and exceeds 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?

Though long, every sentence adds unique, non-redundant information. The description is front-loaded with the core purpose and then systematically covers async behavior, dirty handling, log limits, and merge implications. No filler or repetition exists.

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 no output schema and no annotations, the description fully covers the immediate return value, the eventual record structure (commit, exitCode, dirty, logRef, ranAt, runId), how to await it, and the merge gate. It gives the agent everything needed to invoke and react to 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 coverage is 100%, so baseline is 3. The description adds useful param context beyond the schema, such as the branch being a 'mission branch' and the resulting 'ci/<branchSlug>' record, and confirms workspace is required on every tower tool. This enhances understanding of how parameters are used.

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: 'Run the configured CI command (boot ci_command) in the mission branch's worktree (tower-only).' It clearly differentiates from sibling tools like moa_tower_wait and moa_tower_merge by focusing on the CI execution action and its tower-only scope.

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?

Explicit guidance is provided: 'await it with moa_tower_wait(wait={kind:"ci", branch}) before merging' names the alternative tool and sequence. It also specifies the prerequisite ('When a ci_command is configured') and a behavioral constraint (dirty worktree triggers an error), giving clear when-to-use and when-not-to-use signals.

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. It adds useful behavioral context: the finding is stored under a random UUID key and routed by the tower. However, it does not disclose side effects, permissions, or what the response contains beyond the storage key.

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, front-loaded with the verb and resource. Every clause adds value: the categories, the audience, the usage rule, and the storage behavior.

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 no output schema and no annotations, so the description should ideally explain the return value or postconditions. It explains the storage mechanism and routing, but not what the caller receives or any prerequisites. Given the richness of the schema, it's adequate 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?

The schema provides 100% coverage for all nine parameters with detailed descriptions, so the baseline is 3. The description adds no parameter-specific information beyond what the schema already documents.

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 ('File a structured finding') and lists the four categories (bug | improve | vuln | idea). It distinguishes this tool from siblings by emphasizing that workers use it for notable items outside their mission scope, rather than for direct fixes.

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 states when to use it: for anything notable outside the worker's mission scope, and when not: instead of fixing it directly. It doesn't name sibling alternatives, but the context is clear enough for agents to differentiate.

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 transparency burden. It adds useful behavior beyond the name: 'newest first' and the scope 'messages addressed to you or broadcast; the tower sees everything.' However, it does not disclose whether reading affects message state, pagination behavior beyond the limit parameter, or error conditions, leaving notable gaps for a no-annotation 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?

One compact sentence with a parenthetical qualifier. The verb and object are front-loaded, and every word adds meaning; 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?

For a simple read tool, the description covers purpose, scope, and ordering, and the schema documents the limit parameter. However, with no output schema and no annotations, the description does not explain the returned message format or how this tool relates to sibling inbox/handoff tools, making it only minimally 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%, and the input schema already documents each parameter in detail, including the default limit. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the action (Read), the resource (caller's inbox), the message scope (messages addressed to you or broadcast), and the ordering (newest first). This distinguishes it from sibling tools like moa_handoff_inbox by specifying inbox messages rather than handoffs.

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 this tool—when you want to see messages addressed to you or broadcasts—but provides no explicit guidance on when not to use it or which alternatives (e.g., moa_handoff_inbox, moa_wait_turn) might be more appropriate. There is no mention of 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 provided, the description carries the full burden and excels: it discloses the exact sequence of blocking checks, the CI-skip condition, the final 'git merge --no-ff' action, conflict reporting, and the activity-log side effect. This gives the agent a clear model of what actually happens when invoked.

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 front-loaded with a one-sentence purpose, followed by a logical, ordered list of gates using arrows. Every clause conveys a necessary condition or behavior, and there is no redundant or filler text—appropriate for a complex tool.

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

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

Without an output schema, the description covers most necessary context: the full gate pipeline, edge cases (CI only when configured), and the conflict report outcome. However, it does not explicitly describe the success return value beyond 'conflicts report' or the exact shape of merge results, leaving minor ambiguity.

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%, with each parameter already explained in the input schema. The tool description adds minimal parameter-specific meaning beyond reinforcing that 'branch' is a mission branch and that 'workspace' anchors the tower namespace, so the baseline score of 3 is appropriate.

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 immediately states the specific action 'Merge a mission branch into the base (tower-only)', which clearly identifies the operation and distinguishes it from other tower tools. It further elaborates the scope and purpose by listing the gate conditions, making the tool's function 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 provides extensive when-to-use guidance by enumerating the hard gates in fixed order (mission membership, dependencies merged, clean review, CI green, etc.), telling the agent the prerequisites before calling. It does not explicitly name alternative tools or when not to use this tool, so it falls just short of perfect 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 burden and does an excellent job. It reveals major side effects: patches go through the store, workers only patch their own mission, ownership and scope changes are tower-only, scope changes re-run the disjoint check and are logged, a blocker sets status to blocked, and task_done marks the first open task containing that text done. This is far beyond the schema and gives the agent a clear understanding of consequences.

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

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

The description is a single, fairly long sentence but well-structured: it front-loads the main purpose, clarifies the id argument, and then lists behavioral rules. Every clause adds useful information; there is no padding. It could be split into sentences for readability, but overall it is appropriately sized for a complex tool with 9 parameters.

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 the main read vs patch distinction, return value for reads, and key behavioral rules. Since there is no output schema, mentioning that reads return a rendered mission view is helpful. It does not describe error cases or exactly how patches are triggered, but the schema fills in the parameters. Overall, it is sufficiently complete for an agent to invoke the tool confidently.

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

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

Schema coverage is 100% with detailed descriptions for every parameter, so the baseline is 3. The description does add a little extra context (e.g., task_done behavior, scope change side effects), but these are also partly in the schema. It does not significantly improve semantic understanding beyond what the schema already provides.

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 reads or patches a mission, addressed by id. It is specific about the resource and action, and distinguishes from the many sibling tools by focusing on mission read/update operations. However, it does not explicitly name alternative tools, so it doesn't fully differentiate from similar mission-related tools like moa_tower_plan or moa_tower_progress.

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 with an id to view, or with patch parameters to modify. It also explains important constraints like workers only patching their own mission and tower-only ownership/scope changes. It does not explicitly mention alternatives or when not to use it, but the context is strong enough for an agent to decide.

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 several behavioral traits: mission id/branch/worktree creation, pairwise disjoint build scopes, dependency validation against known ids, and survey missions being read-only with no scope reservation. It could add more on return format and reversibility, but covers key 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?

Three sentences, front-loaded with the main action. Every clause earns its place: id-prefix rationale, disjoint scope constraint, survey nuance, and the required combo. No wasted words 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?

Given the nested input schema and no output schema, the description explains what the tool does (creates missions with ids/branches/worktrees) and imposes necessary constraints. It stops short of describing the return value, which would be helpful, but overall provides sufficient context 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 descriptions already cover all top-level parameters (context reports 67% coverage). The description adds meaning beyond the schema: the required combo, per-mission requirements (title + non-empty scope), optional fields, disjoint scope constraint, and the id-prefix collision avoidance rationale.

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 'Split a tower goal into missions (tower-only)' – a specific verb and resource. It clearly distinguishes from siblings by detailing that each mission gets an id (M<n>), a branch (feat/M<n>-<slug>), and a worktree slot (wt-<n>).

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 splitting a tower goal into missions) and provides the 'Required combo' for invocation. It does not explicitly state alternatives or when not to use it, but the tower-only scoping and sibling context make the primary use case 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 full burden and excels: it discloses LWW storage under progress/<missionId>, accumulation behavior, the 80KB headroom ceiling, and the ownership restriction. This goes well beyond a generic write tool description and fully explains the tool's operational characteristics.

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 sentences, front-loaded with the primary purpose, and every sentence contributes meaningful information (ownership, storage, frequency). 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?

For a write tool with no output schema and no annotations, the description covers all essential aspects: what it does, who can use it, how data is stored, size limits, and recommended frequency. It feels complete and leaves no obvious 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 100%, so the schema already documents all four parameters. The description adds contextual color (automatic timestamping/attribution, anchoring to workspace) but does not provide deeper parameter-level semantics beyond what the schema offers, hence the baseline score of 3.

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 ('Post a progress note to a mission') with a specific resource and scope, and distinguishes from sibling tools by specifying ownership restrictions (row-11 ownership, mission's owning worker or tower only). This is a precise verb+resource definition.

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 context for when to use the tool (posting progress notes) and explicit constraints (ownership restrictions, sparse note frequency under cron discipline B4). However, it does not explicitly name alternative tools or describe when-not-to-use scenarios, 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 provided, the description carries full burden and delivers. It discloses the three-step validation logic, the degradation behavior ('Missing fold data degrades to verified:false (never blocked)'), the failed_count mechanic ('3 consecutive → blocked'), and the exact rebuild of the guard mirror file including its JSON structure. This addresses both failure modes and state changes.

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 paragraph but front-loaded with the core purpose and then expanding into validation and guard mirror details. Every sentence adds crucial information (validation steps, failure modes, re-run behavior, required combo). It is longer than typical but the complexity of the tool justifies the length — it is still efficiently packed with no filler.

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

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

For a tool with 8 parameters, no output schema, and no annotations, this description is remarkably complete. It covers the exact invocation context (post-spawn), required vs optional parameters, validation logic, error handling, re-run idempotency, and even the structure of the guard mirror file. The agent has enough information to use the tool correctly without additional lookup.

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

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

The input schema covers all 8 parameters with descriptions, so the baseline is 3. The description adds value by clarifying the semantic relationship between parameters — designating name and agent_id as the required combo and labeling the others as optional backfills, while explaining that agent_id is the value returned by the Agent tool. This helps the agent correctly map runtime values to 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 begins with 'Two-stage spawn completion (tower-only): fills the real engine agent id into the pending roster entry created by moa_tower_spawn' — a specific verb+resource+process that clearly differentiates it from sibling tools like moa_tower_spawn. It also outlines the B2 identity cross-validation steps and guard mirror rebuild, leaving no ambiguity about what the tool does.

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

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

The description explicitly states when to use it: after moa_tower_spawn, with the required combo '{name, agent_id}' — the roster name plus the engine agent id from your Agent tool. It also notes that mission_id/review_target/worktree/branch are optional backfills, and that re-running is allowed, providing clear operational 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 burden of behavioral disclosure. It reveals key behaviors: the store assigns the round and stamps the branch tip, the tool resolves the tip via git rev-parse (never trusting self-reported commits), the gate only consumes clean rounds, and the merge field has no gate effect. This is exceptional transparency beyond the basic action, covering side effects and gate mechanics.

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 information-dense: four sentences covering purpose, tip resolution, gate logic, and merge advisory. Every sentence contributes meaningful information without fluff. It is front-loaded with the primary action and immediately clarifies restrictions and critical behavioral 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?

Given the tool's complexity (8 parameters, no output schema), the description covers the core semantics: how rounds are assigned, tip resolution, and gate behavior. It does not explicitly describe the return value or post-submission steps, but in the absence of an output schema this is not strictly required. The description is complete enough for an agent to understand the tool's role and constraints.

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 has 100% description coverage for all parameters, so the baseline is 3. The description adds value by explicitly clarifying the 'merge' parameter's advisory nature and its lack of gate effect, which is not fully conveyed in the schema. It also reinforces the 'status' parameter's role in the gate, but most parameter details are already well-documented in 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 clearly states the action: 'Submit a review verdict for an assigned branch', with a specific resource and scope ('reviewers and the tower only'). It distinguishes itself from sibling tower tools by explaining the merge gate logic and advisory merge field, making it unique among the tower 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 implies when to use this tool: as a reviewer or tower when submitting a review verdict. It provides context about the gate and the merge field's advisory nature, but does not explicitly mention alternatives or when not to use it. The sibling tools like moa_tower_finding or moa_tower_merge are implicitly different, but no direct comparison is made.

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 discloses meaningful behavioral rules: self-send is forbidden, body has a 96KB ceiling, and it returns the message board key. It doesn't cover failure modes or permissions, but the most important constraints are clearly stated.

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 exactly two sentences, starts with the action, and includes only the most essential details. 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?

The description sufficiently conveys the tool's purpose, constraints, and return value, which is adequate for a message-sending tool without an output schema. It would benefit from an explicit note on when to prefer this over the handoff or board write tools, but the core usage context 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?

The schema already describes all parameters with 100% coverage, so the baseline is 3. The description adds value by highlighting the self-send restriction (a cross-parameter constraint between 'to' and 'caller_agent_id') and by recommending message splitting, which goes 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 clearly states the tool delivers inbox messages and specifies the three recipient types (roster agent, tower, 'all' broadcast). It also mentions key constraints like self-send prohibition and the 96KB body cap, distinguishing it from board and handoff 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 implies usage for sending inbox messages and gives practical advice to split large content, but it does not explicitly state when to use this tool over sibling tools like moa_handoff_send or moa_board_write.

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 fully discloses side effects: creates sibling worktree, marks mission active, registers PENDING roster entry, phases of execution, and foreground requirement. It explains the two-stage process and what phase 1 vs phase 2 does, offering rich 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?

The description is long but each sentence carries necessary detail about the two-stage process, worktree placement, and argument rules. It is structured and front-loaded, though slightly dense with multiple clauses that could be split for 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 complex spawn tool with no output schema, the description covers the full lifecycle: worktree creation, enrollment, launching, phase restrictions, and argument requirements. It leaves little ambiguity about how the tool behaves and what the caller should expect.

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?

Even though schema coverage is 100%, the description adds critical conditional semantics: worker spawn requires mission_id while reviewer spawn requires review_target, and clarifies that reviewers take a branch instead of a mission. This goes beyond the schema's generic property 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 clearly states the tool creates a physical git worktree, marks the mission active, registers roster entry, and launches the agent. The verb 'spawn' plus detailed resource outcomes distinguishes it from siblings like moa_tower_boot or moa_tower_register.

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 explicit argument combos (worker vs reviewer), required parameters for each kind, and explicit warnings like 'never run_in_background=true'. Also tells when to use moa_tower_register to complete enrollment, giving clear procedural 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 must carry the full behavioral burden. It does so by disclosing a significant side-effect: 'Reading status also re-verifies every roster entry against the status fold (lazy re-verify, B2-9) and persists the verdicts.' This alerts the agent that even a read operation can cause writes, which is critical for a status 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 dense but well-structured: a clear opening label, a list of dashboard sections, then the side-effect warning. Every listed item adds information relevant to a status dashboard, so the length is justified and front-loaded with the core purpose.

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

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

There is no output schema, so the description carries the responsibility of explaining return content. It lists all major sections (mission table, roster with specific columns, review-gate state, CI summary, inbox count, activity log) and the read side-effect. It is complete enough for an agent to understand what to expect, though it stops short of describing exact formats or edge 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 coverage is 100% and both parameters (workspace, caller_agent_id) already have detailed descriptions in the schema. The main description adds only indirect context (e.g., 'the caller's inbox count' implies caller_agent_id), which does not exceed the baseline value provided by 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 clearly identifies this as a 'shared tower dashboard' and enumerates the specific resources it covers (mission table, roster, review-gate state, CI summary, inbox count, activity log). This is a specific read/resource combination and distinguishes it from sibling tools like moa_tower_ci or moa_status_agents by the breadth of content.

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

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

No explicit guidance is given for when to use this tool versus alternatives. The word 'dashboard' implies an overview use case, but there is no statement like 'use this for overall status, use moa_tower_ci for CI details' or any 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 provided, the description fully discloses behavior: dirty worktrees are kept unless force, junctions are unlinked to avoid touching targets, partial teardown sets torn_down:false, tower stays booted, nothing is deleted on partial teardown, and the append-only board JSONL persists as audit trail. This exceeds typical 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?

The description is long but every clause carries essential edge-case information. It front-loads the primary action ('Tear the tower down') and then details conditional behavior. While dense, it does not waste words, though it could be slightly more condensed.

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 tool with no output schema and no annotations, the description covers all key aspects: what is deleted, what is preserved, partial failure behavior, and side effects. It even explains the 'why' behind the junction handling. This is exceptionally 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 100%, so baseline is 3. The description adds meaningful semantics, especially for 'force' (dirty worktrees are kept unless force) and implies the role of 'workspace' as the tower anchor. This enriches the schema's 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 clearly states the tool tears down the tower by removing mission worktrees, deleting the guard mirror file, and clearing the live tower namespace. It explicitly distinguishes from sibling tools by specifying 'tower-only' and detailing the teardown process unique to this operation.

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

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

The description provides clear context: it is used to tear down a tower for a fresh boot, and notes that partial teardown requires fixing worktrees and re-running. It does not explicitly name alternatives, but the context makes it obvious when to use this tool versus other tower management 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 fully discloses behavior: it describes the long-poll blocking nature, the default 25min safety cap with clamping, per-kind payload returns, conditions for satisfaction (e.g., ci must match current tip), and special cases like empty deps being vacuously satisfied. It also states caller eligibility, leaving no behavioral surprises.

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?

Although long, the description is tightly packed with essential information and structured with semicolons and per-kind lists. It front-loads the core contract and then details each wait kind, with no filler; every sentence contributes to understanding the tool.

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

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

Given the tool's complexity (four wait kinds, nested wait object, no output schema), the description is exhaustive: it covers timing, payloads, error conditions (missing dep doc, closed task scope), caller restrictions, and references sibling tools for clarity. It leaves no meaningful gap for an agent selecting or invoking the tool.

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

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

The schema already includes descriptions for all 4 parameters, but the description adds substantial meaning by explaining how each wait.kind interprets its parameters (e.g., mission waits on status change, deps waits on all merged) and what the resulting payload contains. It clarifies timeoutMs clamping and workspace anchoring, going far beyond the schema field 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 clearly identifies the tool as a long-poll wait primitive for the tower domain, with specific verbs 'block until condition holds, then return' and differentiates it from sibling tools by referencing moa_board_wait / moa_wait_turn. It enumerates four distinct wait kinds with precise semantics, making 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?

It explicitly models itself on moa_board_wait / moa_wait_turn, signaling which domain it covers, and provides detailed when-to-use context for each wait kind (e.g., deps is the dependency-driven parallel-dispatch primitive). It also specifies an exclusion: delegators are rejected and may only use moa_tower_send, giving clear guidance on when not to use 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?

The description discloses the long-polling behavior and possible return types (turn data, debate complete, timeout with retry). It mentions a safety cap (timeout). However, it lacks details on error conditions, cancellation behavior, or side effects. Given no annotations, it provides adequate but not comprehensive transparency.

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, consisting of two sentences that convey the core behavior and return types. Every word adds value, with 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?

For a long-polling tool with multiple return types and no output schema, the description covers the main outcomes. However, it lacks context about prerequisites, error handling, or how to interpret the returned fields. It is adequate 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 description coverage is 100% with brief descriptions for both required parameters. The description does not add extra context beyond the schema, such as where to obtain task_id or agent_id, or what 'preset agents' means. Baseline of 3 applies.

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

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

The description clearly states that the tool long-polls until the agent's turn, specifying the resource (agent's turn) and action (wait). It is distinguishable from sibling tools which are about initialization, starting, submitting, completing, or status. However, it could be more explicit about distinguishing itself from moa_status.

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, such as moa_status. It does not mention prerequisites like needing to have started a debate or that this should be called after moa_start_debate.

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