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. 'Predict' combined with 'BEFORE dispatching' strongly implies a non-mutating, side-effect-free calculation, which is useful signal for an agent weighing safety. But it does not explicitly state that the tool does not dispatch or modify state, nor what inputs drive the estimate — whether it is a pure function of the three parameters or incorporates current conversation context.

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

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

A single 11-word sentence that front-loads the verb and purpose. 'BEFORE dispatching' earns its place by adding workflow positioning that differentiates the tool from its siblings, and there is zero 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 low-complexity tool with three scalar parameters, the description covers core purpose and timing — enough for an agent to decide WHEN to call it. But with no annotations and no output schema, the burden is higher: the 'token cost' framing versus per-million-token price inputs leaves the output ambiguous (estimated tokens, estimated dollars, or both), and the return value is never described.

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

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

Schema description coverage is 0%, so the description must compensate, and it partly does: 'fan-out' maps to k_tasks and 'token cost' maps to the two price parameters. However, it never defines units (mtok = million tokens), states what k_tasks counts, or explains how the parameters combine to produce the estimate. The self-descriptive parameter names carry much of the remaining interpretive weight.

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 ('Predict') and resource ('token cost of an Algernon fan-out'), and the 'BEFORE dispatching' marker distinguishes it from operational siblings like dispatch_with_dependencies. An agent can tell this is a planning-stage estimation tool without opening the schema. The only minor weakness is reliance on the undefined domain term 'Algernon fan-out', but the core purpose is unambiguous.

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

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

'BEFORE dispatching' gives explicit temporal context, telling the agent to run this during planning rather than execution, which clearly separates it from dispatch_with_dependencies and orchestrate_and_record. However, it names no alternatives and gives no when-not-to-use conditions or exclusions. Clear context, but the guidance stops short of explicit routing logic.

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 only mentions dependency-ordered waves and fan-out/fan-in, but says nothing about side effects, return behavior, error handling, permissions, or what 'dispatch' actually entails. This is a meaningful transparency gap.

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

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

The description is a single tight sentence with the core operation front-loaded. It loses a point because 'Algernon' is unexplained jargon, making the sentence not fully self-contained for an unfamiliar agent.

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

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

The tool has only one parameter and no nested objects, so complexity is low. But with no output schema and no annotations, the description should explain what the tool returns, whether it waits for completion, and how it differs from dispatch-adjacent sibling tools; it does none of this.

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%, since the schema already explains tasks_json as a JSON array of {id, prompt, depends_on: [ids]}. The description adds no additional parameter-level meaning, 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 uses a specific verb ('Run') and clearly identifies the resource ('tasks in dependency-ordered waves via Algernon') with a distinctive fan-out/fan-in mechanism. It does not explicitly differentiate from sibling tools such as orchestrate_and_record or govern, so it stops short of a 5.

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

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

The phrase 'dependency-ordered waves' and 'fan-out/fan-in' imply this tool is for tasks that have dependencies and should be executed in waves. However, it gives no explicit when-to-use or when-not-to-use guidance and does not mention alternatives among the listed siblings.

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

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

With no annotations provided, the description carries the full burden, and it does well by disclosing that the tool is rule-based, zero-LLM, and fail-closed. This tells the agent the operation is deterministic and safe to rely on, though it stops short of explaining what the response looks like or what fail-closed yields in practice.

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

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

The description is only two sentences and every word earns its place. It is front-loaded with the core purpose, followed by a compact behavioral qualifier, with no filler or redundant restatement of the tool name.

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 three parameters, no schema descriptions, no output schema, and no annotations, the description is not complete enough for an agent to confidently construct calls. It gives a strong conceptual model but omits parameter usage, return format, and what fail-closed means operationally.

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 mention any parameter by name. The action and rules parameters are weakly inferable from 'before acting' and 'rule-based,' but the flags parameter is entirely unexplained, leaving a significant semantic gap.

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

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

The description clearly states the tool's purpose: ask the two-chamber gate for permission before acting. It names a specific resource (gate), a specific verb (ask), and the timing (before acting), and it distinguishes this from all siblings by framing it as a pre-action authorization check rather than an execution, estimation, or recall tool.

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

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

The phrase 'before acting' provides a clear trigger condition for when to use this tool. It does not explicitly name alternatives or exclusions, but the context of a pre-action gate is sufficiently distinct from the 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, the description carries the behavioral disclosure burden. It does reveal that the tool is governance-gated and auto-logs to both chains, which is useful. However, it never states whether it mutates state, what permissions are required, what happens on failure, or what 'both chains' actually are.

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 brief, but brevity is achieved through undefined jargon ('Two-chamber-govern-gated', 'Algernon') rather than clear, front-loaded information. It is under-specified rather than efficiently concise, especially for a tool with four parameters and significant orchestration 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?

Given the tool's complexity, four unannotated parameters, no output schema, and no annotation support, this description is far from complete. It omits parameter explanations, usage context, return behavior, side effects beyond logging, and relationships to the sibling tools, leaving an agent without enough information to invoke it correctly.

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

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

Schema description coverage is 0%, and the description adds no meaning for any of the four parameters. The agent cannot infer what 'k' represents, what values 'flags' can take, or how 'actor' relates to the goal, leaving the input schema largely unexplained.

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

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

The description names a compound operation ('plan+dispatch') and a clear side effect ('auto-logged to both chains'), so it is more than a tautology. However, the key terms 'Two-chamber-govern-gated' and 'Algernon' are opaque, and the description does not differentiate it from siblings like dispatch_with_dependencies or recall_and_replan.

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 statement of when to use this tool versus alternatives. The phrase 'govern-gated' hints at a governance condition, but it does not explain when an agent should select this tool over dispatch_with_dependencies or recall_and_replan, nor does it give any exclusions or prerequisites.

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 that the tool reads from both chains, merges them, and orders newest first, which is useful behavioral context. With no annotations provided, the description carries the burden, and it does not mention side effects, return format, or edge cases, but 'read' suggests a non-destructive 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 a single sentence with the verb and core behavior front-loaded. It contains no wasted words, though it leaves key terms like 'BOTH chains' undefined, which slightly reduces clarity.

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

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

The definition omits parameter semantics, return behavior, and what 'chains' refers to, and there is no output schema to compensate. Given its role as a context-retrieval tool with optional parameters, the description is too sparse to fully support correct invocation.

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

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

Schema description coverage is 0%, and the description provides no explanation of the 'actor' or 'limit' parameters. Since there are two parameters and neither is clarified, the description fails to compensate for the missing schema documentation.

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 and merges prior context from both chains and orders it newest first. It names a specific verb and resource, but does not explicitly distinguish it from sibling tools like recall_and_replan or remember.

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 'so the AI need not re-derive it' implies the tool should be used when prior context is needed to avoid recomputing it. However, there is no explicit when-to-use guidance, no exclusions, and no comparison to alternatives such as recall_and_replan.

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 states that prior state is recalled and fed into a new plan, but it does not disclose whether this modifies or replaces anything, whether it is a read-only operation, what side effects occur, or what the output looks like.

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

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

The description is a single sentence with no filler and the primary action comes first, which is efficient. However, it relies on unexplained domain jargon and is so brief that it sacrifices clarity, making it only adequate structure-wise.

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 communicates the basic operation but is far from complete for a tool with two required parameters, no output schema, and no annotations. It lacks parameter mapping, expected inputs, output behavior, and prerequisites, leaving an agent without enough information 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 description coverage is 0%, so the description must explain the two required parameters, query and k. It does not mention either parameter at all. An agent cannot determine what values to pass, especially k, which has no reasonable default meaning from its name or 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, 'Recall', with a clear resource, 'prior state from both chains', and an action, 'feed it into a new Algernon plan'. It is not a tautology and conveys a distinct recall-and-replan purpose, though terms like 'both chains' and 'Algernon plan' are unexplained.

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

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

No guidance is given about when to use this tool versus sibling tools such as recall, remember, govern, or orchestrate_and_record. The intended use is only implied by the description, not stated, and there are no exclusion conditions 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 the full burden. It discloses meaningful traits: writes to BOTH chains concurrently, records are tamper-evident, and unknown actors are rejected. However it says nothing about reversibility, idempotency, rate limits, or failure behavior for a mutation tool that touches two external systems.

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

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

Two sentences, front-loaded with the core purpose followed by the actor constraint. No filler, though the inline backtick phrasing is slightly awkward.

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 dual-chain, tamper-evident write with a nested `data` object and no output schema or annotations, the description covers purpose and the actor precondition but omits the shape/format of `action` and `data` and what the caller gets back. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It only explains `actor` (the birth name from sentarion_birth), a genuinely useful clarification, while `action` and `data` (the nested payload) remain entirely undocumented.

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

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

States a specific verb (Write) and resource (tamper-evident record) and specifies the dual destination (local Humane + hosted ArkHive), which is more than a generic write. It contrasts implicitly with read-side siblings like recall, though it does not name an alternative explicitly.

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

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

Gives a real precondition: actor must be the value sentarion_birth returned, and chains 'refuse an actor it has not born'. This implies the birth tool must run first, but there is no explicit when-to-use vs when-not guidance or named alternative (e.g., orchestrate_and_record).

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

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

With no annotations, the description carries the full burden. It does disclose return values (actor plus each chain's soul_id) and error behavior ('Never crashes: a chamber that cannot answer is reported with a fix'), which is genuinely useful. However, it omits whether the call is idempotent, whether it mutates persistent state, what permissions it needs, or what happens on repeat invocation — significant gaps for an identity-creating 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?

Three tight sentences: purpose first, then return values, then reliability. Little waste, though the parenthetical jargon ('Humane Law 5: born, not configured') and chain branding add words without adding decision-relevant 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?

There is no output schema, no annotations, and zero schema description coverage on two required parameters, including an unexplained required array. For an operation that mints identity across two chains, the description is too thin — it should define the covenant input and the mutation/idempotency semantics.

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

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

Schema description coverage is 0% and neither parameter is explained in the description. The word 'name' appears only to describe the returned actor ('your birth name'), not the required input, and the required `covenant` string array is never mentioned at all — an agent has no idea what to supply.

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 conveys that this is an identity-creation/setup operation that must run before other actions, and it names the two targets (local chamber and hosted ArkHive). However, the framing is heavily metaphorical ('Earn an identity', 'Humane Law 5: born, not configured'), and without opening the schema an agent cannot tell whether this registers, mints, or merely fetches an identity. It does not differentiate itself from siblings such as sentarion_pro, sentarion_quickstart, or sentarion_doctor.

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 'before acting' gives an implied precondition (call this prior to other operations), which is real usage guidance. But there are no explicit alternatives, no when-not-to-call, and no statement of what happens if identity already exists or which of the sibling setup tools (quickstart, pro) to prefer.

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 disclose two important traits: the operation is read-only and it never prints secrets (relevant since it checks an API key). It stops short of saying whether checks hit the network, how long they take, or what happens when a component is unreachable.

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

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

One dense sentence listing the checked components followed by a short safety clause; the purpose is front-loaded and there is no filler. Every clause adds information an agent can act on.

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 and no annotations, so the description must carry the whole load. It does describe the intended output ('say exactly what to fix') and the safety profile, but omits the undocumented timeout_s and gives no sense of result shape or failure reporting for a seven-component check.

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

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

Schema coverage is 0%: the single parameter timeout_s has no description in the schema, and the tool description never mentions it, so an agent gets no guidance on its meaning, unit, or whether it applies per-check or overall. The default of 3 is the only signal available.

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 ('Check') plus an explicit resource ('everything Sentarion needs'), and enumerates the concrete dependencies verified (git, Algernon, chamber, ArkHive, fleet provider, Ollama, API key). This lets an agent separate it from siblings like verify, worktree, or sentarion_quickstart without opening a schema.

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

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

Usage is only implied: the diagnostic framing ('say exactly what to fix') suggests running it when something is broken or before setup, but no explicit when-to-use, ordering relative to sentarion_quickstart/sentarion_birth, or exclusions are stated. Adequate but leaves the routing 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?

No annotations are provided, so the description carries the full behavioral burden. It advertises v2 capabilities such as in-process execution, audit manifests, and background jobs, but does not disclose what happens on invocation: side effects, permissions, payment obligations, data handling, rate limits, or return behavior. The feature list is not a substitute for operational 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 a long, promotional feature dump followed by fragments. It front-loads the product name but buries any actionable purpose at the end, and most claims are difficult for an agent to map to invocation behavior. It is not structured for quick tool selection.

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

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

With no output schema and no annotations, the description should clarify return values and side effects. Instead, it does not explain what the topic enum changes, whether email triggers external communication, or what 'Details + trial key' means operationally. It is too incomplete for confident invocation.

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

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

Schema description coverage is 100%, and both optional parameters are already documented in the schema. The description repeats the trial-key and topic context but adds no syntax, format, or behavioral meaning beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 'Sentarion v2 — the paid upgrade' and then lists features, but it never states a specific action the tool performs. It does not say whether calling it returns a trial key, activates v2, shows details, or checks status. This leaves the tool's purpose vague and largely tautological with the product 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?

There is no explicit guidance on when to use this tool versus its many siblings. 'Free 0.x stays whole' hints at a paid/free distinction, but it does not identify alternatives or conditions for selection. Optional email and topic parameters imply trial-key/interest use cases, but the agent is left to infer them.

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 disclosure burden. It does not say whether 'runnable examples' are returned as text, executed server-side, or have side effects, nor whether the call is safe/read-only. This is a meaningful gap for a zero-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 front-loaded sentence enumerating the capabilities, with no filler. Efficient, though the enumeration is essentially restating the enum options rather than adding 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?

With no output schema, no annotations, and an optional param whose default behavior is unstated, the description does not explain the return shape (text? example objects?) or default selection. For a discoverability/quickstart tool, that leaves key questions unanswered.

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

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

Schema description coverage is 0% and the single 'topic' param has no documentation. The description merely repeats the six enum values verbatim, adding no semantics about what each topic yields or what happens if 'topic' is omitted (it is optional). Marginal value over 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 identifies the resource (canonical runnable examples) and enumerates the capabilities covered, which partly distinguishes it from siblings like recall or worktree. However, there is no clear verb — it is ambiguous whether the tool returns documentation, executes examples, or scaffolds code. An agent cannot confidently tell what it gets back.

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

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

There is no guidance on when to call this versus the many concrete siblings (orchestrate_and_record, dispatch_with_dependencies, recall_and_replan). It never says 'use this first to learn the API' or 'use this instead of X', so routing relies entirely on the agent inferring from the name.

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 that the tool proves unbroken-ness of both chains, implying a verification/read-only behavior. Without annotations, it carries the burden, but it doesn't disclose what happens on failure (e.g., error vs. false return), whether it is purely read-only, or if it triggers any repair/recovery actions. It's adequate but incomplete.

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, direct, and front-loads the action. It wastes no words and conveys the essential scope. Slight minus for being terse but effective.

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 verification tool with no output schema, the description states what it proves but doesn't specify the success/failure return semantics, how the result is presented, or whether it makes any changes. Given the tool's simplicity, this is a minor gap, making it adequately complete but not fully 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?

The tool has zero parameters and the schema is empty. The description doesn't need to explain parameters; baseline 4 for zero params is appropriate. It also accurately reflects the tool's scope.

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 ('Prove') and names the exact resource/scope ('BOTH audit chains (local Humane + hosted ArkHive)'), making it clear this tool verifies chain integrity. It doesn't explicitly distinguish from siblings, but no sibling name overlaps with audit verification, so it's sufficiently clear.

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

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

The description implies the tool should be used when there is a need to confirm both audit chains are unbroken, which provides adequate context. However, it doesn't explicitly state when not to use it, mention any prerequisites, or name alternative tools for related but different checks.

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

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

With no annotations provided, the description must carry the behavioral burden. It discloses important traits: isolation from the live checkout, read-only list behavior, and that create/remove are governed. However, 'two-chamber-governed' is unexplained jargon, and details about side effects, branch deletion, or force behavior are 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?

The description is compact and front-loads the key behavior (isolated worktree) before listing actions. The two sentences contain no filler. However, the phrase 'two-chamber-governed' is opaque and could be clearer without adding length.

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 8 parameters, no output schema, and no annotations. The description gives a good high-level summary and names the actions, but does not explain per-action parameters, return values, or the actual 'two-chamber-governed' mechanism. The rich schema compensates partly, but not fully.

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 high at 88%, so the parameters are already well documented in the input schema. The description adds only the action enum grouping, no additional meaning about base, branch, force, delete_branch, or worktree_path. The high coverage keeps this at baseline 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 identifies the tool's purpose: it runs dispatched work in an isolated Git-worktree sandbox, and explicitly enumerates the three actions (create, list, remove). This is a specific verb+resource statement that distinguishes it from the unrelated sibling tools.

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

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

The description provides clear context for when to use the tool—when you need to run work in isolation and avoid touching the live checkout. It also distinguishes read-only usage (list) from governed mutations (create/remove). It does not name alternative tools or explicit exclusions, but the usage context is sufficiently clear.

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