Server Quality Checklist

Tool Scores

• orchestrate_and_recordC
  2.2/5.0
  Behavior3/5

  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.

  Conciseness2/5

  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.

  Completeness1/5

  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.

  Parameters1/5

  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.

  Purpose3/5

  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.

  Usage Guidelines2/5

  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.

• recall_and_replanC
  2.4/5.0
  Behavior2/5

  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.

  Conciseness3/5

  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.

  Completeness2/5

  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.

  Parameters1/5

  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.

  Purpose4/5

  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.

  Usage Guidelines2/5

  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.

• recallC
  2.9/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness2/5

  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.

  Parameters1/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• sentarion_birthC
  2.9/5.0
  Behavior2/5

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

  With no annotations present, the description carries the full burden, but it only mentions that an identity is earned and a soul_id is returned. It does not disclose side effects, persistence, constraints, prerequisites beyond the call, or what 'earning an identity' entails. This is thin for a creation-like tool.

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

  Conciseness5/5

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

  The description is a single compact sentence with no filler. It front-loads the core purpose and the key return value, while the Humane Law reference adds flavor without bloating the text.

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

  Completeness2/5

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

  The tool is simple, but the total absence of parameter explanation and behavioral details leaves gaps. The description does note the return value and ordering intent, but an agent would struggle to provide a valid `covenant` or know what happens after birth.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description gives no meaning for the required parameters `name` or `covenant`. The agent is left with raw schema types only, with no guidance on values, format, or how these parameters relate to earning an identity.

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

  Purpose4/5

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

  The description clearly states a specific action — earning an identity — and the useful result (a soul_id to be used as actor). The 'born, not configured' phrasing hints at a distinction from configuration-style tools, though it doesn't explicitly name a sibling. This goes well beyond a tautology.

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

  Usage Guidelines3/5

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

  The phrase 'before acting' implies this tool should be invoked first to obtain an identity, which is useful usage guidance. However, it does not explicitly state when this should be avoided or mention any alternative tools from the sibling list, leaving the routing partially to inference.

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

• sentarion_proC
  2.9/5.0
  Behavior2/5

  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 offers one behavioral reassurance—'Zero-pressure — the free tier stays whole'—but does not state what the tool returns, whether it is read-only, whether it triggers any side effects, or what an agent should expect after invocation.

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

  Conciseness4/5

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

  The description is compact and front-loads the core offering list in the first sentence. The second sentence is short and adds a relevant reassurance about the free tier. It is concise, though the second sentence reads more like marketing than operational guidance.

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

  Completeness3/5

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

  Given zero parameters and no output schema, the description conveys the informational content of the tool reasonably well. However, it never explicitly says what invoking the tool does or what kind of response to expect, which leaves an important gap for a tool with no structured output metadata.

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

  Parameters4/5

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

  The input schema has zero parameters and the schema description coverage is 100%, so parameter semantics are trivially satisfied. The description does not need to explain parameters, and with no params the baseline of 4 applies.

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

  Purpose3/5

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

  The description names a specific subject—the maintainers' paid offering—and lists concrete items (hosted endpoint, priority support, InboxAxe business suite), so it is not a tautology. However, it lacks an explicit verb and resource, e.g. 'returns', 'lists', or 'describes', leaving the tool's actual operation vague. It also does not distinguish itself from sibling tools such as cost_estimate.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to invoke this tool versus alternatives. It never mentions related sibling tools or conditions under which this should be used, so an agent must infer the tool's purpose from the name and marketing-like text.

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

• dispatch_with_dependenciesB
  3.1/5.0
  Behavior2/5

  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.

  Conciseness4/5

  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.

  Completeness2/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• rememberA
  3.5/5.0
  Behavior3/5

  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 several behavioral traits: it writes to both chains at once, is tamper-evident, and requires a born soul_id. Missing are failure semantics (e.g., partial chain failure), idempotency, and reversibility, so transparency is partial.

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

  Conciseness5/5

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

  Two sentences with no filler; the core action and scope are front-loaded, and the prerequisite is stated as a separate clarifying sentence. Every sentence earns its place.

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

  Completeness2/5

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

  The tool has no output schema, no annotations, and three parameters including a nested object, yet the description omits what action should contain, what data is for, and what the tool returns on success or failure. An agent would need to infer or seek external information for safe invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only clarifies the actor parameter ('Requires a born soul_id as actor'). Nothing is said about the meaning or expected format of action or data, leaving two of three parameters under-specified.

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

  Purpose5/5

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

  The description says 'Write a tamper-evident record to BOTH chains at once (local Humane + hosted ArkHive)' — a specific verb, resource, and scope. The dual-chain behavior clearly distinguishes it from reading/verifying siblings such as recall and verify.

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

  Usage Guidelines3/5

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

  The 'Requires a born soul_id as actor' prerequisite provides some contextual guidance, and the dual-chain write purpose implies when it should be used. However, there is no explicit comparison to alternatives or statement of 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.

• verifyA
  3.5/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness3/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• worktreeA
  3.8/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• cost_estimateA
  3.9/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• governA
  3.9/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness2/5

  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.

  Parameters2/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.