Bicameral

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 that the tool routes each step to the user or editor model, runs baseline verification, and returns routing. It also explains the pin=true behavior and the editor_model='self' option. It doesn't mention side effects like whether a run is persisted or whether it modifies state, but it covers the key behavioral traits.

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 and front-loads the core purpose. It packs useful routing and pin behavior into a compact form. It could be slightly more structured, but it earns its place without 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?

The tool has 10 parameters, no annotations, and an output schema. The description explains the high-level flow but leaves many parameters unexplained (task_kind, gates, commit, learning, verify_command, summary). An agent would need to infer their meaning from names alone. The output schema exists, so return values are covered, but the parameter semantics gap makes this incomplete for a complex tool.

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

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

Schema description coverage is 0%, so the description must compensate. It explains editor_model and pin semantics, but the other 8 parameters (task, workspace, task_kind, summary, steps, gates, commit, learning, verify_command) are not described in the tool description. The schema itself has descriptions for nested StepInput properties, but top-level parameters lack descriptions. The description adds some meaning but doesn't fully compensate for the 0% coverage.

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

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

The description states a specific verb ('Register your plan and start a run') and resource, and clearly distinguishes this tool from siblings by explaining it is the entry point that routes steps and runs baseline verification. It also names the editor_model='self' option, which differentiates it from other bicameral 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 explains when to use this tool: to register a plan and start a run, and it gives a clear alternative behavior (editor_model='self' to do every step yourself). It doesn't explicitly name sibling tools as alternatives or state when not to use it, but the context is clear enough for an agent to select it as the initial run 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?

No annotations are present, so the description carries the full disclosure burden. It transparently enumerates the three actions the tool performs, which is meaningful behavioral context. It does not state whether the operation is read-only or whether verification/opinion results are persisted, a notable gap 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?

A single sentence that front-loads the trigger and then lists the workflow in a compact, scannable form. There is no filler or repetition of schema titles. It earns a high score for efficiency.

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 an output schema, so the return value need not be spelled out, and the description conveys the main workflow. But it omits parameter semantics and any prerequisites/error conditions (e.g., whether a snapshot must exist), and the many bicameral siblings create ambiguity that is not resolved. Overall adequate but not complete.

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

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

Schema description coverage is 0% and the description never maps run_id or step_id to roles beyond an implicit 'step'. With no parameter documentation, an agent must infer that step_id is the edited step and run_id identifies the run, which is risky. The description mentions 'a step' but does not compensate for the schema's empty parameter descriptions.

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

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

The description opens with a concrete trigger and names three specific operations (diff, run verification, second opinion), so an agent knows what invoking it accomplishes. It does not explicitly contrast with overlapping siblings such as bicameral_review_diff or bicameral_critique, so it misses the sibling differentiation that would earn a 5.

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

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

The trigger 'After editing a step yourself' is an explicit usage context and distinguishes this from tools used at other workflow phases. However, it gives no exclusions or mention of alternate sibling tools, so it falls short of a full 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implicitly discloses non-mutating behavior ('before anything is edited') and implies the critique output guides revisions. However, it doesn't describe the output format, whether the critique is blocking, or any other side effects. For a tool with zero annotation coverage, more explicit behavioral context would be valuable.

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

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

Two sentences with zero waste. The purpose is front-loaded, the critique criteria are enumerated compactly, and the routing instruction ('Same arguments as bicameral_begin', 'then call bicameral_begin') closes the loop. 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 output schema exists and the nested StepInput is well-documented in the schema, the description is reasonably complete for a critique tool. The top-level parameters are undocumented in the schema, but the 'same arguments as bicameral_begin' pointer mitigates this. An explicit note on what the critique response contains would push this to a 5.

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

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

Schema description coverage is 0% for the top-level parameters (task, workspace, editor_model, task_kind, summary, steps, verify_command have no descriptions), but the nested StepInput type has rich per-property descriptions in the schema itself. The description compensates somewhat by stating 'Same arguments as bicameral_begin', routing the agent to another tool for parameter details. This is adequate but not exemplary.

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 ('Ask the editor model to critique'), a specific resource ('your draft plan'), and enumerates exactly what the critique covers (under-specified steps, wrong files, missing steps, unverifiable acceptance criteria). It distinguishes itself from sibling tools by positioning as a pre-edit review and naming bicameral_begin as the follow-up, so an agent can tell them apart without opening any schemas.

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

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

The description gives clear timing context ('before anything is edited') and a post-call action ('Revise where it is right, then call bicameral_begin'). It references 'Same arguments as bicameral_begin' for routing. It doesn't explicitly state when to skip the critique and go straight to execution, which would strengthen the 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 carries the full burden. It discloses important behavioral traits: delegated steps return 'a diff plus verification output' while routed steps return 'instructions to edit yourself.' This goes beyond a typical vague one-liner. It still omits details about state changes, permissions, or reversibility, but the disclosure is meaningful.

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

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

Three sentences, each serving a distinct purpose: a clear summary, a breakdown of the two execution modes, and a retry note. There is no fluff, no repetition of schema fields, and the most critical information is front-loaded. This is an efficient, well-structured description.

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

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

For a tool with no annotations and a multi-step workflow context, the description explains the execution outcomes and retry feedback well. However, it leaves gaps around how to determine run_id/step_id, what distinguishes delegated from routed steps, and how this tool relates to the sibling tools. The output schema covers return values, but parameter provenance and selection logic are missing.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It only addresses feedback by noting it is passed on retries, and it does not explain run_id or step_id at all. The names are somewhat self-explanatory, but the description provides almost no parameter-level guidance for an agent.

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

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

The description opens with a specific verb and resource: 'Execute one step.' It clarifies the tool's core function and distinguishes between delegated and routed steps, which helps differentiate it from review/status siblings. However, it does not explicitly name any sibling tools or contrast them, so it falls just shy of a 5.

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

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

The description implies this tool is for executing a single step in the bicameral workflow, and it gives one direct usage tip: 'Pass feedback on retries.' It does not state when to use this tool versus alternatives like bicameral_review or bicameral_critique, nor does it provide exclusion conditions. This is adequate but not fully explicit.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It does so by enumerating side effects: final verification, outcome logging, lesson storage, and scoring, plus returning a summary. It could add detail about irreversibility or state changes, but the terminal nature is clearly conveyed.

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

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

The description is a single front-loaded sentence with no filler. Every phrase adds meaning: the action, the component steps, and the return value. It is an efficient, well-structured definition.

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 captures the core operations and return value, which is reasonable given an output schema exists. However, without annotations and with weak parameter semantics, it leaves uncertainty about how to supply success and lessons and what happens to the run after closing. 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 0%, so the description must compensate, but it does not explain how run_id, success, or lessons map to their expected values. 'Lesson storage' and 'outcome logging' loosely hint at lessons and success, but the agent gets little concrete guidance on the parameters.

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

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

The description starts with 'Close the run,' which names a specific verb and resource, and then lists the concrete operations involved: final verification, outcome logging, lesson storage, and scoring. It clearly distinguishes this terminal tool from lifecycle siblings like bicameral_begin, bicameral_execute, and bicameral_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 opening phrase 'Close the run' establishes a clear terminal context: use this when the run is complete and needs final verification, logging, lesson storage, and scoring. It gives clear usage context but does not explicitly name alternatives or state when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It describes what data it returns (lessons, edits, track record) and the source file, but it does not explicitly state whether it is read-only, whether it has side effects, or any error behavior. The read-only nature is implied by 'recall' but not stated, and there is no mention of pagination or output format, which an output schema might cover but is not referenced in the description.

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

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

The description is a single sentence that front-loads the core content (what it recalls) and ends with a clear usage directive. Every word earns its place; there is 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 tool has a low complexity and an output schema exists, which likely covers return format. However, the description omits any explanation of the 'workspace' parameter and does not provide details on the structure or volume of the recalled data. It also lacks explicit behavioral notes (e.g., read-only). Given the presence of an output schema, the description is partially complete but still leaves gaps in parameter semantics and behavioral disclosure.

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

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

Schema description coverage is 0%, so the description must compensate. It only vaguely references 'a task' but does not explain the required 'task' parameter or the optional 'workspace' parameter. The description fails to clarify what 'workspace' means or how it affects the recall, leaving the agent without sufficient guidance for invoking the tool with correct parameter values.

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 recalls lessons, similar accepted edits, and routing track record, plus lessons from a specific file. The verb 'recall' and the resource (lessons/edits/track record) make the purpose unambiguous, and it is distinct from siblings like bicameral_status or bicameral_review_diff, which have different functions.

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

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

It explicitly says 'Call before planning,' which gives a clear temporal directive. However, it does not mention when not to use it or alternatives, so it lacks the 'when-not/alternatives' component needed for a 5.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explicitly reveals that rejection rolls files back and feedback is passed to the next attempt, providing important side-effect information. It does not describe acceptance behavior or permission requirements, but the key destructive behavior is transparent.

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

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

The description is two sentences, front-loaded with the main purpose and immediate side effect. Every clause adds meaning without 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 tool has an output schema and simple parameters, but the description omits exact verdict values, which are critical for correct invocation. It also does not explain how run_id and step_id relate to the workflow, although their names are self-explanatory.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that verdict means accept or reject and feedback goes to the next attempt, but it does not specify exact accepted verdict string values or formats for run_id and step_id beyond their names.

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

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

The description clearly states the tool accepts or rejects an applied edit for a step, which is a specific verb and resource. It distinguishes itself from siblings like bicameral_review_diff (viewing a diff) and bicameral_critique (providing critique) by naming the decision action.

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

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

The description implies usage after an edit is applied by mentioning rejection rolls files back and feedback goes to the next attempt. However, it does not explicitly name alternatives or state when not to use this tool versus bicameral_review_diff or bicameral_critique.

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

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

With no annotations provided, the description carries the full disclosure burden. It clearly states this is review-only, makes no plan, and makes no edits, so the safety profile is transparent. The added guarantee that every file:line finding is verified against lines the diff touches is valuable behavioral detail.

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

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

Two sentences front-load the key mode, then the operation, then the use condition. Every clause earns its place and there is no redundant restating of the name or schema.

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

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

The output schema covers return details, and the description covers purpose, safety, and verification. However, given 0% schema parameter coverage and four parameters, the missing semantics for workspace, model, and context make the definition not fully complete 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?

The schema has no property descriptions (0% coverage), so the description must compensate. It clarifies that base defaults to HEAD and is a git ref, but says nothing about the required workspace and model parameters or the optional context value, leaving the agent to guess valid inputs.

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

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

The description names the precise action (reviews the working tree diff against a git ref), the scope (diff vs. base), and the deliverable (file:line findings verified to be in the diff). It stops short of a 5 because it never explicitly distinguishes itself from the sibling bicameral_review, relying on the '-diff' name and wording.

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 tool explicitly tells the agent when to invoke it ('Use when the user asks for a review or a second opinion on a change') and rules out planning/editing behavior. It does not name alternative tools for planning or editing, so it lacks the explicit exclusion routing needed for 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?

No annotations are present, so the description carries the full disclosure burden. It only lists content categories and does not state that the tool is read-only, mention data freshness, side effects, or access requirements. It is not contradictory, but it is behaviorally thin.

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 compact, six-word list with no filler or redundant phrasing. It is appropriately front-loaded, though its telegraphic style sacrifices some explanatory context.

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

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

For a parameterless reporting tool with an output schema present, the description gives enough orientation by listing the main content areas. It does not need to explain return values in detail, though adding a note about when to use it would 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?

The tool has zero parameters and the schema description coverage is effectively 100%, so the schema already exhaustively documents the input surface. The baseline of 4 applies, and the description does not need to add parameter details.

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

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

The description clearly enumerates the tool's content: success rates, routing table, eval results, and top lessons. Although it lacks an explicit verb like 'get' or 'return', the noun phrase unambiguously identifies this as a stats/reporting tool and goes beyond simply restating the tool name.

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

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

The description provides no guidance on when to use bicameral_stats versus siblings like bicameral_status or bicameral_recall. An agent must infer usage from the tool name and content list, with no exclusions or alternative routing.

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

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

With no annotations, the description carries the behavioral burden. It adds useful ordering context ('Call first') and implies a read-only, current-state snapshot, but it does not explicitly disclose safety, side effects, or consequences of calling, leaving some inference to the agent.

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 compact and every word adds information: what is reported and the recommended call order. 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?

Given the tool has no parameters and an output schema exists, the description need not explain return values. It conveys the essential categories and the 'call first' guidance, though 'history' could be slightly more specific.

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 100% schema description coverage, so the description does not need to clarify parameters. The baseline of 4 applies because there is nothing parameter-related for the description to add.

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

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

The description clearly indicates this tool reports current environmental state: backends, sign-in status, available editor models, and history. It is understandable for a status tool, but it lacks an explicit verb and does not differentiate itself from sibling tools like bicameral_check or bicameral_stats.

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 instructs the agent to 'Call first', which gives clear usage context as an initial discovery step. However, it does not state when not to use it or name alternatives, so it stops short of full usage guidance.

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