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

No annotations provided, so description carries full burden. Discloses side effects: applies license key, auto-configures permissions (writes settings.json). Notes skipped checks don't affect score. Could mention reversibility but still strong.

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?

Five sentences, well-organized with clear sections. Front-loaded with main purpose. No redundant information.

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

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

Covers activation, readiness checklist, side effects, and sibling distinction. Output schema exists so return values are handled. Complete for an activation 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 100%, so parameters are already well-documented. Description adds context about free-tier readiness for license_key but doesn't provide new semantic meaning beyond 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?

Describes the tool as 'Activate Delimit and run a readiness checklist.' Clearly distinguishes from siblings by contrasting with delimit_diagnose (diagnostic debugging) and delimit_quickstart (first-run discovery).

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

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

Explicitly states when to use (post-install confirmation) and when not to use (diagnostic debugging, first-run discovery). Provides sibling contrast for alternative tools.

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

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

Discloses side effects ('read-only on the policy store') and the underlying call. No annotations exist, so the description carries full burden. It covers the main behavioral trait (read-only) but could mention return value or error handling; however, output schema likely covers that.

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?

Concise, well-structured with clear sections (purpose, when to use, when not to use, sibling contrast, side effects). Every sentence adds value, front-loaded with key information.

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

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

For a simple two-parameter tool with an output schema, the description covers purpose, usage guidelines, side effects, and sibling differentiation comprehensively. No gaps for the complexity level.

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 describes both parameters (model, action) with clear descriptions, and coverage is 100%. The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Check if a model is allowed to perform an action under agent policy.' It uses specific verb-resource pairing and contrasts with siblings (delimit_agent_policy, delimit_gov_evaluate), making its role distinct.

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

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

Explicitly states when to use ('as a per-action gate before executing sensitive operations from a non-orchestrator model') and when not to use (setting policies or runtime governance), with alternative tool names provided.

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

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

With no annotations, the description fully carries the burden. It details side effects: writes a completion record, flips status from 'dispatched' to 'completed', persists result and files_changed, appends an audit log, and coerces files_changed from comma string to list. It also notes no license gate and no notification.

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 well-structured with a one-line summary, usage sections, sibling contrast, and side effects. While slightly long, every sentence provides essential information. No waste, but could be trimmed slightly.

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 (3 params, 1 required, 100% schema coverage, has output schema, no annotations), the description covers lifecycle, errors, side effects, and usage context. It fully compensates for the lack of annotations and provides a complete picture.

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

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

Schema coverage is 100%, and the description adds meaning beyond the schema: task_id is from delimit_agent_dispatch, result is a summary, files_changed is comma-separated paths, and it mentions coercion. This adds value without redundancy.

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: 'Close a dispatched agent task by recording the outcome.' It uses specific verbs (close, recording) and identifies the resource (dispatched agent task). It also distinguishes from siblings explicitly, naming delimit_agent_handoff and delimit_agent_status.

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

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

The description provides explicit 'When to use' and 'When NOT to use' sections, including alternatives like handoff, dispatch, and status. It also warns against repeated calls on the same task_id, giving clear guidance on correct invocation.

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

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

With no annotations, the description fully covers transparency: states it's read-only, names the underlying function call (ai.agent_dispatch.get_agent_dashboard), and outlines the return structure. No contradictions.

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?

Well-structured with labeled sections (main purpose, when to use/not use, sibling contrast, side effects, args, returns). Every sentence adds value; no redundancy.

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

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

For a zero-parameter, read-only dashboard tool, the description covers purpose, usage, side effects, underlying function, and return structure. An output schema exists but description adds enough context for invocation.

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

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

Schema has zero parameters, schema coverage 100%. The description explicitly states 'Args: None', making it clear. Baseline for no params is 4.

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 is for viewing a multi-agent orchestration dashboard, and distinguishes it from sibling tools (delimit_agent_status returns raw records vs. aggregated view). The verb 'View' and resource 'multi-agent orchestration dashboard' are specific.

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

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

Explicit 'When to use' and 'When NOT to use' sections provide clear guidance, including alternatives (delimit_agent_status for single task status, delimit_agent_dispatch for dispatching work). Sibling contrast further clarifies.

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

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

With no annotations, the description fully discloses side effects (writes to disk, string coercion), explicitly states NO subagent spawning, and notes lack of license gating. Comprehensive coverage.

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?

Well-structured with clear sections, front-loaded purpose. Slightly verbose but each sentence adds necessary detail. Could be trimmed slightly without losing value.

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 7 parameters, full schema coverage, output schema present, and many sibling tools, the description covers all needed aspects: purpose, usage, behavior, parameter nuance, side effects.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by noting coercion for string lists and clarifying assignee defaults beyond schema descriptions. Minor extra context.

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

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

Clearly states the tool records engineering-task dispatch with audit trail. Distinguishes from siblings by specifying it is for planning/audit surface, not execution.

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

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

Explicitly provides 'When to use' and 'When NOT to use' sections, plus sibling contrast. Guides the agent on proper context and alternatives like delimit_agent_status and delimit_agent_complete.

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

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

No annotations are provided, so the description carries the full burden. It discloses side effects: 'writes a handoff record' and 'updates assignee on the task.' This is good but does not cover potential error states or idempotency. Nonetheless, it is transparent about key behaviors.

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 well-structured with a one-sentence summary, followed by clear bullet-like sections for when to use, when not to use, sibling contrast, and side effects. Every sentence adds value with no redundancy.

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

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

Given the presence of an output schema (which explains return values) and the detailed description covering purpose, usage, and side effects, the description is complete for this tool's complexity. No gaps are apparent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add significant extra meaning beyond what the schema already provides for each parameter (task_id, to_model, context).

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

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

The description clearly states the tool's action ('Hand off an agent task to a different AI model') and distinguishes it from siblings in the 'Sibling contrast' section, specifically contrasting with delimit_agent_complete.

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

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

Explicit 'When to use' and 'When NOT to use' conditions are provided, naming specific alternatives (delimit_agent_complete, delimit_agent_dispatch) and contexts (blocked executor, cross-model review). This gives unambiguous guidance.

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

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

No annotations provided, but the description fully discloses side effects: status is read-only, other actions write and audit, dispatch only records intent. It details deterministic guards (kill switch, circuit breaker, ghost-title reject) and error format. This exceeds the burden typically expected.

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

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

The description is front-loaded with the core summary, then well-structured into usage guidelines and side effects. While verbose with guard details, every part earns its place given the tool's complexity. Slight verbosity keeps it from a 5.

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 12 parameters, 4 actions, multiple guards, and an output schema, the description covers the lifecycle, per-action parameter usage, side effects, error handling, and sibling relationships. No gaps remain.

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

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

Schema coverage is 100%, so baseline is 3. The description adds contextual nuance: which parameters apply to which actions, how 'context' differs for dispatch vs handoff, 'task_id' optional for status but required for complete/handoff. This adds meaningful value beyond the schema.

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

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

The description clearly states it manages the agent-task lifecycle and dispatches to one of four actions. It distinguishes from siblings by naming thin aliases and contrasting with other delimit tools like delimit_ledger_add.

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

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

Explicit when to use (single MCP surface for lifecycle actions) and when not to use (internal code paths preferring specific aliases). It warns about misconception that 'dispatch' executes, and clarifies separate tools that share the prefix.

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

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

No annotations provided, but description discloses side effect of writing a link. Lacks details on idempotency or error conditions, but sufficient given tool simplicity.

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?

Well-structured with purpose, when to use/not, sibling contrast, and side effects. No unnecessary words. Front-loaded.

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

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

Covers purpose, usage, side effects, and sibling contrast. Output schema exists so return details not needed. Could mention prerequisite that items exist, but overall complete.

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

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

Schema coverage is 100%, so parameters are well-documented there. Description does not add additional meaning beyond what's in the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool links an agent task to a ledger item, with specific verb and resources. It distinguishes from sibling tools like delimit_agent_dispatch and delimit_ledger_link.

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

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

Explicitly states when to use (after dispatch to show relationship) and when not to use (for new dispatch or close). Provides clear sibling contrast.

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?

Given no annotations, the description carries full burden. It discloses side effects (writes via ai.agent_policy.set_agent_policy, empty/no-changes is read-only) and explains access level values. However, it does not mention rate limits, auth requirements, or output format, but for a config tool this is adequate.

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 well-structured with clear sections (purpose, when to use, when not to use, sibling contrast, side effects, parameter details). It is front-loaded with the main purpose and concise without wasted words.

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

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

Covers purpose, usage, side effects, and parameter semantics. With an output schema present, return values need not be detailed. The description adequately addresses the tool's complexity and provides sufficient context for an agent 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 coverage is 100%, so baseline is 3. The description adds value by grouping parameters (ledger/memory/evidence as access levels with 'read-only', 'read-write', 'none'; deploy/secrets as boolean flags; custom_constraints as comma-separated) and clarifying allowed values beyond the schema descriptions.

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

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

The description clearly states 'Set or view per-model governance permissions' with a specific verb and resource. It distinguishes itself from sibling tools like delimit_gov_evaluate and delimit_project_config by explaining their different purposes.

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

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

Explicitly states when to use (inspect or modify per-model policy) and when not to use (runtime evaluation or session policy), with specific alternative tool names (delimit_gov_evaluate, delimit_project_config).

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?

States read-only nature and underlying function call. No annotations exist, so description carries the burden; it adequately covers safety but lacks detail on error conditions or rate limits. Still strong given the tool's simplicity.

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?

Very concise and well-structured: purpose sentence, usage sections, sibling contrast, side effects. Every sentence earns its place with zero 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's simplicity (one optional param, output schema present), the description covers all necessary aspects: purpose, usage, exclusions, side effects. Complete for its context.

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

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

Schema coverage is 100%, so baseline is 3. The description repeats the schema's parameter description (task_id optional, empty for all) without adding new semantics. No enhancement over schema.

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

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

Clearly states 'Check status of dispatched agent tasks' with a specific verb and resource. Distinguishes from sibling delimit_agent_dashboard by contrasting raw status records vs aggregate view.

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

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

Explicitly provides when to use (monitor open/closed tasks) and when NOT to use (dispatch or complete tasks), naming specific sibling tools as alternatives. The sibling contrast further clarifies differentiation.

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 side effects: gated by require_premium, calls ai.cross_model_audit.audit, and no ledger write. This is good coverage, though it could additionally mention output format or cost implications. Still, it provides significant transparency beyond minimal.

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 well-structured with clear headings (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence serves a purpose, no redundancy, and it is front-loaded with the core purpose.

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

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

Given the tool's complexity (3 params, output schema exists, no annotations), the description covers purpose, usage, alternatives, and key side effects. It does not explain the output format in plain language (but schema covers it) and omits potential costs, but the level of detail is sufficient for confident agent invocation. Minor room for improvement.

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

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

All 3 parameters are described in the schema with 100% coverage. The description adds context about the three lenses (security, correctness, governance) and the cross-model nature, but does not materially extend the schema's semantics. Baseline 3 is appropriate.

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

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

The description clearly states the tool's verb (audit) and resource (code change), specifying it uses 3 models and 3 lenses (security, correctness, governance). It distinguishes itself from siblings delimit_review and delimit_deliberate by highlighting the cross-model structured audit approach.

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

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

Explicitly provides 'When to use' and 'When NOT to use' with concrete alternatives (delimit_deliberate for debate, delimit_review for single-model review). The 'Sibling contrast' section further clarifies the differentiation, leaving no ambiguity for the agent.

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

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

No annotations provided, so the description carries the full burden. It details side effects for each loop_type (e.g., cycle dispatches swarm work, social drafts replies, deploy runs gates) and mentions writing to the session record. However, it does not discuss idempotency, error behavior, or permission requirements, which would elevate it to a 5.

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 well-structured with clear headings for usage, side effects, and loop types. It is concise—every sentence adds value—and front-loaded with the tool's core purpose.

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

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

Given the complexity (4 parameters, no annotations, output schema exists), the description is thorough. It covers when to use, side effects, and loop type details. The output schema likely explains return values, so the description does not need to repeat that.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the semantics of loop_type and cycle_mode beyond the schema's simple type descriptions, such as what each loop type does and the cycle_mode options. This complements the schema well.

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 'execute[s] one iteration of a governed continuous loop'. It specifies the verb 'execute', the resource 'governed continuous loop', and distinguishes from siblings like delimit_loop_status and delimit_loop_config. The inclusion of loop types adds further clarity.

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

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

Explicitly provides when to use ('advance the autonomous build / social / deploy loop one step') and when NOT to use (for status use delimit_loop_status, for configuration use delimit_loop_config). Also contrasts with sibling tools, offering clear guidance.

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

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

No annotations exist, so the description carries full burden. It discloses side effects (daemon thread spawn/halt, JSONL logging, config safeguards, premium gating). While comprehensive, it lacks details on error handling or concurrency behavior, but overall adds valuable 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 well-organized with clear sections (purpose, when to use, when not, sibling contrast, side effects). Every sentence is informative and free of fluff, making it easy for an AI to parse quickly.

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 (daemon lifecycle, multiple parameters, safeguards) and the presence of an output schema for return values, the description covers all necessary aspects: spawning, stopping, logging, and respecting configuration. It is self-contained for decision-making.

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

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

Schema coverage is 100%, so baseline is 3. The description adds marginal context (e.g., default interval of 15 minutes, loop_type options) but does not significantly enhance understanding beyond the schema's own descriptions. The side effects section links action values to behavior, which is helpful but not novel.

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 as a 'Background auto-pull daemon' for governed loops, which is specific and distinct from the one-shot 'delimit_build_loop' sibling. It uses strong verbs ('spawns', 'ticks') and defines the resource (governed build/social/deploy loops).

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

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

Explicit 'When to use' and 'When NOT to use' sections are provided, with direct alternatives: 'delimit_build_loop' for one-shot and 'delimit_loop_status' for metrics. Sibling contrast further clarifies the choice.

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 exist, so description fully bears the burden. It details read-only nature on inputs, side effects of writing to output_file, and the special prepend behavior for 'CHANGELOG.md'. It also describes the two modes and their effects.

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

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

Well-structured with clear sections: when to use, when not to use, sibling contrast, two modes. Each sentence adds value, no fluff. Front-loaded with purpose.

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

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

Given 8 parameters, two modes, and absence of annotations, the description is thorough. It explains mode selection, parameters, side effects, and contrasts with related tools. The output schema exists but description doesn't need to explain return values.

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% (all 8 parameters described). The description adds value by linking parameters to modes (e.g., repo_path for git mode, old_spec/new_spec for spec mode) and clarifying the prepend behavior for output_file. This goes beyond the schema.

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

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

The description clearly states the tool generates a changelog from git+ledger (git mode) or spec diff (spec mode). It distinguishes itself from siblings like delimit_explain (human prose) and delimit_release_plan (release planning).

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

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

Explicitly states when to use (part of deploy gate chain, producing release notes, prepending CHANGELOG.md) and when NOT to use (ad-hoc explanations, release planning) with alternative tools named. This provides clear 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?

Discloses side effects: claim/release mutate lock state, check is read-only. No annotations provided, so description fully handles behavioral disclosure with no contradictions.

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?

Concise three-section structure (purpose, usage, side effects) with no wasted words. Front-loaded with core purpose. Every sentence adds value.

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 moderate complexity (4 params, no annotations, output schema exists), description covers purpose, usage, side effects, and sibling contrast. Output format not needed due to output schema.

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

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

Schema description coverage is 100%, so description adds little beyond what schema already provides. Description repeats schema text for file_path but does not significantly enhance parameter meaning.

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

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

Clearly states the tool detects/prevents multi-model file edit collisions, with specific verb and resource. Explicitly differentiates from sibling delimit_swarm by stating it tracks per-file edit ownership.

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

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

Provides explicit 'When to use' (cross-model workflows, claim before edit, release after commit) and 'When NOT to use' (single-model sessions, general filesystem locking). Clear guidance on context.

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

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

With no annotations, the description carries full burden. It discloses that the tool is read-only ('read-only on the project'), sanitizes the project path via _sanitize_path, and returns the bundle in response without writing to a file. While it could mention error handling or additional side effects, it provides 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 well-structured with clear sections, concise sentences, and no redundancy. Every sentence adds value, and the main purpose is front-loaded. It achieves maximum efficiency in communication.

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 one parameter, good schema coverage, and an output schema, the description covers all necessary aspects: purpose, usage, side effects, and return behavior. It is complete for an agent to select and invoke the tool correctly.

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

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

The sole parameter, project_path, is well-described in the schema with a default and explanation. Schema coverage is 100%, so the description adds minimal additional meaning beyond what the schema provides. No further elaboration is given, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Export the current governance config as a shareable JSON bundle.' It also distinguishes from siblings by explicitly naming delimit_config_import as the round-trip counterpart and delimit_gov_policy for reading live policy, providing clear differentiation.

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

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

The description includes dedicated 'When to use' and 'When NOT to use' sections, giving explicit scenarios: use for packaging config for sharing/import, not for reading live policy or initializing a project. It also contrasts with sibling tools, providing comprehensive usage guidance.

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

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

No annotations are provided, so the description carries full burden. It discloses side effects: writes policy file, optionally writes workflow file, sanitizes project_path. However, it does not specify overwrite behavior, permissions needed, or error cases, slightly reducing completeness.

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 concise, well-structured with separate sections for core action, usage guidance, and side effects. Every sentence adds value 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?

Given the tool's complexity (3 params, output schema exists, no annotations), the description covers purpose, usage, side effects, and sibling relationships. It lacks details on error handling and prerequisites, but output schema covers return values. Overall, fairly complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context about config_json origin and write_workflow purpose, but does not significantly enhance parameter meaning beyond what the schema already provides.

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

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

The description clearly states the tool imports a governance config from a JSON bundle into a project, using a specific verb and resource. It distinguishes from siblings by mentioning the round-trip counterpart (delimit_config_export) and contrasting with init and project_config loading.

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

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

Explicit 'When to use' and 'When NOT to use' sections provide clear guidance, naming alternative tools for different scenarios (delimit_init, delimit_project_config). The sibling contrast further clarifies the tool's role.

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

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

No annotations provided, so description carries full burden. It discloses side effects: writes to backends, posts tweet, generates/upload video. This informs the agent of mutating behavior.

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

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

Concise, well-structured with labeled sections. Every sentence adds value. Front-loaded with main purpose.

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

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

For a simple tool with one parameter and an output schema, the description covers purpose, usage, side effects, and sibling relationships. Complete enough for correct selection and invocation.

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

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

Schema coverage is 100% and the description adds no additional parameter meaning beyond what the schema already provides. Baseline 3 applies.

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

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

Clearly states the action ('manually trigger a content publish') and resource ('tweet or YouTube video'). Distinguishes from siblings by naming delimit_content_schedule and delimit_content_queue.

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

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

Explicit 'When to use' and 'When NOT to use' sections, plus sibling contrast listing specific alternatives. Guidance is direct and actionable.

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 behavioral traits such as side effects for each action (seed populates, add appends, status read-only) and states that the tool mutates the queue. While no annotations exist, the description covers key behaviors, though could mention potential limits or additional side effects.

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

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

The description is very concise, using short bullet points under clear headings. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.

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 presence of an output schema (not shown but indicated), the description does not need to cover return values. It fully covers purpose, usage, side effects, and sibling contrasts, making it a complete and self-contained description for an agent.

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

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

The input schema covers both parameters with 100% coverage, but the description adds valuable behavioral context by mapping each action value to its side effect. This enhances understanding beyond the schema's raw 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 explicitly states the tool manages tweet and video content queues, and distinguishes it from siblings by noting that delimit_content_publish drains and delimit_content_schedule reads, while this tool mutates. The verb 'manage' plus specific actions (view, seed, add) make the purpose very 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 provides explicit when-to-use (view, seed, add) and when-not-to-use (publish or read schedule) guidance, including specific sibling tool names for alternatives. This leaves no ambiguity about context.

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

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

Despite no annotations, the description declares 'Side effects: read-only' and names the internal function call. It provides a clear return structure overview, ensuring the agent understands the tool is safe and non-mutating.

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 concisely structured with clear sections (description, when to use/not use, sibling contrast, side effects, args, returns). Every sentence adds value with no redundancy.

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

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

Given zero parameters and an output schema, the description fully covers the tool's purpose, usage guidelines, behavioral notes, and return structure, making it complete and self-sufficient.

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

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

No parameters exist, and the description explicitly states 'Args: None.' Schema coverage is 100% trivially, and the description adds no unnecessary detail, fulfilling the baseline with perfect clarity.

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 'View the upcoming content schedule (queued + pending + recent)' with a specific verb and resource. It explicitly distinguishes from siblings by stating what it is not for (publish, manage queue) and names the alternatives.

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 explicit when-to-use ('inspect what's queued...') and when-not-to-use ('to actually publish' or 'manage the content queue') scenarios, and contrasts sibling behavior ('delimit_content_queue mutates queue state; this reads').

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

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

No annotations provided, but the description details side effects for each action: 'list' is read-only, 'create' writes new branch namespace, 'merge' mutates main namespace and closes branch. States no code repo, git state, license gate, notification, or ledger write.

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?

Well-structured with clear sections (when to use, not to use, sibling contrast, side effects). Every sentence adds value, no redundancy.

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

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

Given tool complexity (multiple actions, 3 params, existing output schema), the description covers usage, side effects, and contrasts completely. No missing aspects.

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

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

Schema coverage is 100%, so baseline 3. Description adds behavioral context for actions but does not provide additional parameter details beyond schema descriptions.

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

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

The description clearly states the tool manages mutable working branches of a venture's context, using specific verbs like 'manage' and resource description. It distinguishes from siblings like delimit_context_snapshot (read-only) and delimit_context_read.

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

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

Explicitly provides 'When to use' (exploring alternative directions, write-isolated) and 'When NOT to use' (immutable evidence, reading context, git operations). Contrasts with delimit_context_snapshot and git directly.

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

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

No annotations provided, so description fully covers side effects per action: read-only vs write ops, idempotency, silent overwrite, deterministic errors, and destructive merge behavior (deletes branch).

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?

Well-structured with sections, but could be slightly more concise; the side-effect per-action list is thorough but verbose.

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 8 parameters, no annotations, and complex dispatch logic, the description is comprehensive, covering all actions, errors, and comparisons with sibling/memory tools. Output schema exists, so return details are not needed.

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

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

Schema coverage is 100%, but the description adds practical context like conditional dependencies (branch_action requires branch_name) and default behaviors, beyond the schema's type/default fields.

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 it is a 'unified context-filesystem entry point' that dispatches to six actions, and distinguishes itself from sibling aliases like delimit_context_read, delimit_context_write, etc., by being the dispatch core.

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

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

Explicit 'When to use' and 'When NOT to use' sections, compares to memory tools, and suggests preferring specific aliases for internal code paths.

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?

Despite no annotations, the description discloses side effects (creates venture directory and metadata files) and idempotency. It adds behavioral context beyond the schema, though it could mention error handling or output format, but output schema exists.

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

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

The description is extremely concise: a single-sentence function statement followed by clearly labeled sections (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence adds value.

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 simplicity (1 optional parameter, no required), high schema coverage, and presence of output schema, the description covers purpose, usage, side effects, and idempotency. No gaps.

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

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

Schema coverage is 100% for the only parameter 'venture', so the baseline is 3. The description does not add meaning beyond the schema (it essentially repeats the schema's description). With high coverage, this is acceptable.

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

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

The description clearly states that the tool initializes a context filesystem namespace for a venture, using specific verb and resource. It distinguishes from siblings by contrasting scope (venture vs conversation) and versioning (snapshot/branch).

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

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

Explicitly states when to use ('once per venture, the first time you want to persist cross-session/cross-model context') and when not to use, providing specific alternative tools (delimit_memory_store for single-session memory; delimit_context_read for reading artifacts). Also contrasts with sibling memory 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?

Discloses side effects as read-only and the internal call to ai.context_fs. With no annotations, the description does a fair job, though it could mention permissions or error handling. Still, it transparently describes behavior beyond basic purpose.

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

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

The description is extremely concise with structured sections (purpose, when to use, when not to, sibling contrast, side effects). Every sentence adds unique value, and there is no redundancy or fluff.

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

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

Given the tool's simplicity (one parameter, output schema present), the description covers all essential aspects: purpose, usage context, alternatives, side effects, and basic behavior. It is fully sufficient for an agent to correctly select and invoke the tool.

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

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

Schema coverage is 100% with a single required parameter 'venture' described as 'Venture namespace key. Required.' The description does not add additional semantic detail beyond what the schema already provides, which is adequate but not enhanced.

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 'List all artifacts in a venture's context filesystem' with a specific verb and resource. It distinguishes from siblings like delimit_context_read (reads content) and delimit_memory_recent (scans memories), leaving no ambiguity about the tool's function.

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

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

Explicit when-to-use ('to inventory what artifacts have been written') and when-NOT-to-use sections directly name alternative tools (delimit_context_read, delimit_memory_recent), providing clear decision guidance for the agent.

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

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

Declares side effects as read-only and mentions underlying call (ai.context_fs). Since no annotations provided, the description fully covers 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?

Very concise and well-structured: one-line purpose, then clear sections for when to use, when not to use, sibling contrast, and side effects. Every sentence adds value.

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?

Fully covers purpose, usage, side effects, and sibling contrast. With output schema present (as per context signals), no need to describe return values. Complete for a simple read operation.

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 already provides 100% coverage with descriptions for both parameters. The description reinforces parameter usage but adds no new semantic details beyond the schema, so baseline 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?

Clearly states the tool reads a specific artifact from a venture's context filesystem by name. Distinguishes from siblings like delimit_context_list (returns names only) and delimit_memory_search.

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

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

Explicitly states when to use (fetch a specific artifact) and when not to use (venture-wide listing or memory search), naming alternatives (delimit_context_list, delimit_memory_search).

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

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

With no annotations, the description carries full burden; it states side effect: 'writes a snapshot record under the venture namespace via ai.context_fs' and that the snapshot is an immutable point, sufficiently 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?

Efficiently organized: purpose, when to use, when not, sibling contrast, side effects. No extraneous information.

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

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

Given the tool's simplicity (2 params, clear schema), the description provides sufficient context for usage, side effects, and differentiation. Output schema exists, so return value details are covered.

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%, both parameters have clear descriptions. The tool description does not add additional meaning beyond the schema, so 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?

Clearly states 'Capture a point-in-time snapshot of a venture's context' with a specific verb and resource, and explicitly contrasts with siblings.

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

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

Provides explicit when to use (before risky handoff/edit/refactor), when NOT to use (individual artifact persistence or one-time memory), and alternative tools (delimit_context_write, delimit_memory_store).

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

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

No annotations provided, but description discloses side effect (file creation under ~/.delimit/context/<venture>/) and notes that artifact_type only affects render hints. Could mention overwrite behavior or size limits for a 5.

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?

Every sentence serves a purpose: action, when-to, when-not-to, sibling contrast, side effects. No extraneous words; front-loaded with core purpose.

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

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

Covers purpose, usage, side effects, and sibling differentiation. Output schema exists but is not shown; description does not need to return values. Missing concurrency or error details, but sufficient for a write tool.

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

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

Schema coverage is 100%, so baseline 3. Description adds value by explaining that artifact_type affects render hints but not storage format, and implies name is the file key. Adequately complements schema.

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

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

The description uses specific verb 'Write' and resource 'artifact to a venture's context filesystem', clearly distinguishing from siblings like delimit_context_read, delimit_context_list, and delimit_context_snapshot.

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

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

Explicitly states when to use (persist plans/decisions/code for future sessions) and when not to (ephemeral context, snapshot all), with named alternatives: delimit_memory_store and delimit_context_snapshot.

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?

Despite no annotations, the description fully discloses behavioral traits: list/get are read-only, approve/reject append to an existing store, reject stamps disposition='rejected', idempotent re-approve no-ops, and no new store created. This covers safety, side effects, and idempotency comprehensively.

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 well-structured with sections for purpose, when to use, when not, sibling contrast, and side effects. It is slightly verbose but every sentence contributes meaningful information. Front-loaded with core purpose.

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

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

Given the tool's complexity (multiple action types, lane unification) and the presence of an output schema, the description is complete. It covers purpose, usage boundaries, side effects, and differentiation from siblings. No obvious gaps in required information for agent invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that approve/reject act only on approval-class items and that item_id is required for specific actions, reinforcing schema descriptions. It does not fully redundantly document each parameter but provides useful context.

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 aggregates governance lanes into a shared queue and can approve/reject approvals. It specifies the verb+resource ('aggregate', 'approve/reject') and distinguishes itself from siblings like delimit_agent_dashboard, delimit_ledger_context, and delimit_notify_inbox.

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

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

Explicit 'When to use' and 'When NOT to use' sections provide clear guidance. It specifies that the tool is for the shared queue and approval-class actions only, and directs mutation of other items to their owning tools, which is excellent for agent decision-making.

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

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

No annotations provided, but description fully covers behavioral traits: read-only, failure-isolated partial errors, and npm-bundle behavior. Contradiction-free.

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?

Well-structured with clear sections, no unnecessary words, info dense yet readable.

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

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

Given no annotations but output schema exists, description covers return dict contents, failure modes, and npm-bundle edge case—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?

With zero parameters and 100% schema coverage, baseline is 4. Description states 'Args: None' which matches.

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 provides a unified 'corp status' snapshot, replacing a ritual. It uses specific verbs and distinguishes from sibling tools like delimit_obs_status and delimit_gov_health.

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

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

Explicit 'When to use' and 'When NOT to use' sections, with concrete alternatives (delimit_daemon_status, etc.) and sibling contrast, providing excellent guidance.

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

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

No annotations provided; description discloses side effects (write operations for create/delete/toggle, read-only for list) but lacks details on other behaviors like reversibility or failure modes.

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?

Concise and well-structured with separate sections for usage and side effects; no unnecessary words, but could be slightly more compact.

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

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

Covers purpose, usage, side effects, and sibling differentiation. Output schema exists so return values not needed. Lacks some detail on action behavior specifics but sufficient for a CRUD 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 100% so baseline is 3. Description adds no extra parameter meaning beyond what the schema already provides.

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

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

Clearly states it manages cost alert rules with CRUD operations. Distinguishes from siblings explicitly by specifying when to use and when not, and provides sibling contrast.

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

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

Explicitly states when to use (configure ongoing spend thresholds) and when not (one-shot analysis or optimizations), referencing specific sibling tools as alternatives.

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

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

With no annotations, the description carries full burden. It declares read-only side effects, gating by require_premium, and backend call. Lacks specifics like rate limits or response size, but output schema covers return structure.

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?

Well-structured with sections (when to use, not to use, sibling contrast, side effects). Every sentence is informative and 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 simple tool with one parameter and output schema, the description covers usage, behavior, and context adequately. No gaps identified.

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

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

Schema coverage is 100% for the single parameter 'target', including description. Description adds no extra meaning beyond schema, so baseline 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 states the tool analyzes projects for cost drivers, listing specific scans (Dockerfile, deps, cloud configs). It distinguishes itself from siblings delimit_cost_optimize and delimit_cost_alert.

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

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

Provides explicit 'When to use' (investigating spend) and 'When NOT to use' (enacting reductions or managing alerts), with clear references to alternative tools.

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

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

Lists side effects: actions 'set' and 'reset' mutate state, 'status' and 'quota' are read-only. Since no annotations exist, description carries full burden; it covers the key behavioral distinction among actions.

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?

Well-structured with clear sections (purpose, when to use, when not, sibling contrast, side effects). Every sentence adds value; no redundant text.

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

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

Covers purpose, usage, side effects, and sibling differentiation. No annotations provided, but description sufficiently guides selection and invocation. Output schema exists but isn't needed to explain returns.

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

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

Schema coverage is 100%, so baseline is 3. Description mentions actions and that tool_name is required for certain actions, but adds minimal extra meaning beyond the schema.

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

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

Clearly states 'Manage MCP rate limits and session cost controls' with specific verb and resource. Differentiates from siblings like delimit_cost_analyze and delimit_cost_alert.

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

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

Explicitly provides when to use (inspect/adjust), when not to use (project-cost analysis, alert configuration), and names alternative tools (delimit_cost_analyze, delimit_cost_alert).

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?

Discloses read-only nature and premium gating. No annotations exist, so description bears full burden. Could mention the output structure, but the presence of an output schema reduces need.

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 concise paragraphs with front-loaded purpose, clear usage guidance, and behavioral notes. Every sentence adds value; no redundancy.

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

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

Covers purpose, usage, side effects, and gating. With an output schema, return values are implicitly handled. One could argue it's complete for a simple 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?

Single parameter 'target' has full schema coverage with default and description. The description does not add extra meaning beyond schema, which is acceptable for a simple parameter.

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 finds cost optimization opportunities, specifies the context (after delimit_cost_analyze), and distinguishes from siblings like delimit_cost_alert. The verb-resource pair is specific and actionable.

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

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

Explicitly provides when-to-use and when-not-to-use guidance with concrete sibling tool names. The sibling contrast further clarifies differentiation, making it easy for an agent to decide.

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

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

No annotations provided, so description carries full burden. It declares read-only side effects and lists underlying API calls, providing good but not exhaustive 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?

Description is very concise, front-loads purpose, then usage guidelines, sibling contrast, and side effects in a clear, structured format.

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

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

Covers purpose, usage, side effects, and sibling differentiation. Output schema exists, so return values need not be explained. Minor gap: does not elaborate on risk tier or tool details, but these are likely in output.

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

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

Schema coverage is 100%, and description repeats similar info about item_id meaning without adding new details beyond what schema already specifies.

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?

Description clearly states verb 'Classify' and resource 'ledger item's risk tier and suggested automation tool'. It explicitly distinguishes from siblings by stating it previews daemon action versus run or 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?

Provides explicit when to use (preview classification), when NOT to use (run or check health), and direct alternatives (delimit_daemon_run, delimit_daemon_status).

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 bears the burden. It describes side effects: dry_run vs live mode, the internal call to ai.daemon.run_loop, and the 5-second interval. This is good but could mention permissions or the nature of 'automatable actions'.

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 brief and effectively front-loaded. Each sentence provides essential information without redundancy. Three short paragraphs and a bullet-like list cover purpose, usage, and side effects efficiently.

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 two simple parameters and an output schema, the description covers purpose, usage, differentiation, and side effects. It mentions the 5-second interval, which is valuable. Minor gaps: no mention of error cases or permission requirements, but overall sufficient for agent decision-making.

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

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

Schema coverage is 100%, so baseline 3 applies. The description does not add significant new information about parameters beyond what the schema already provides (defaults, infinite loop). It mentions dry_run in side effects but doesn't enhance parameter understanding.

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

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

The description clearly states the action: 'Advance the autonomous daemon by N iterations (Pro).' It specifies the verb and resource, and distinguishes from siblings (delimit_daemon_status, delimit_daemon_classify).

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

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

Explicitly states when to use (testing, cron-style execution) and when not to use (inspection, classification), with direct references to alternative tools. Sibling contrast is clearly explained.

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

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

With no annotations provided, the description carries full burden. It discloses read-only side effects, the internal function called (ai.daemon.get_daemon_status), and the return value structure. It lacks details on authentication or rate limits, but for a read-only status check this is sufficient. Score 4 due to minor omissions.

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

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

The description is well-structured with clear section headings (When to use, When NOT to use, Sibling contrast, Side effects, Args, Returns). It is concise, with no redundant sentences, and front-loads the primary purpose.

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

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

Given the tool has no parameters and an output schema exists, the description sufficiently explains the return value (loop counts, items processed, recent actions, next_steps). It covers all necessary aspects for an agent to use the tool correctly.

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

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

The tool has no parameters (input schema is empty). The description explicitly states 'Args: None.' with 100% schema coverage, meeting the baseline of 4 for zero parameters. The return value description adds context beyond schema.

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

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

The description clearly states the verb 'Report' and the resource 'autonomous daemon's status', and specifies the contents (loops, items, actions). It also contrasts with sibling tools delimit_daemon_run and delimit_daemon_classify, providing explicit differentiation.

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

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

The description explicitly provides 'When to use' and 'When NOT to use' sections, naming alternative tools (delimit_daemon_run and delimit_daemon_classify) for the excluded cases. This gives clear guidance on selecting the correct 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?

Discloses the side effect: writing timestamped copies to a specific directory via a backend function. Could mention if it overwrites or is safe to run multiple times, but overall good transparency given no annotations.

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?

Concise yet comprehensive: two sentences for the main action, followed by structured bullet points for usage context. No wasted words.

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

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

For a single-parameter tool with complete schema and existing output schema, the description covers purpose, when to use, and side effects, making it fully adequate.

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 single parameter 'target' is fully described in the schema. The description adds no extra semantics beyond the schema's explanation of the default and meaning.

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 explicitly states the tool backs up SQLite and JSON data files to a specific directory, distinguishing it from sibling tools that validate or migrate data.

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

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

Provides clear guidance on when to use (before risky migrations/refactors) and when not to use (for validation or migration), and names alternative tools.

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

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

No annotations provided, so description carries full burden. States 'Side effects: read-only inspection.' and 'Calls backends.tools_data.data_migrate.' Clearly indicates no destructive actions. Lacks details on permissions, error handling, or output format, but output schema may cover that.

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?

Concise and well-organized: one-sentence purpose, then bullet-like sections for usage, contrast, and side effects. No unnecessary words, every sentence adds value.

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

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

Covers purpose, usage guidelines, side effects, and parameter meaning. With an output schema, return values do not need to be described. Slightly lacking in detailing what the inspection output looks like, but overall sufficient for a simple read-only 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?

Input schema has 100% coverage for the single parameter 'target', with description 'Project path to scan for migration files. Default "." (cwd).' The description does not add additional semantic value beyond the schema, so baseline 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?

Starts with 'Inspect migration files (alembic / Django / Prisma / Knex) for status.' Clearly states verb (inspect) and resource (migration files) with specific types. Distinguishes from siblings by contrasting with delimit_data_validate and delimit_data_backup.

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

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

Explicitly provides when to use ('audit pending and applied migrations before a deploy, or as a CI gate'), when not to use ('to actually apply migrations' or 'back up data first'), and mentions alternative tool (delimit_data_backup). Includes sibling contrast.

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

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

No annotations provided, so description carries full burden. It discloses 'Side effects: read-only on the target' and mentions the backend call, addressing the key behavioral trait. Output schema covers return values.

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?

Extremely concise: 3 sentence blocks covering purpose, usage guidelines, sibling contrast, and side effects. No filler.

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

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

Given one optional parameter, no required fields, and presence of output schema, description fully covers purpose, when/how to use, and read-only behavior. Complete for this tool's complexity.

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

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

Input schema covers the single parameter with description and default. Description adds context ('Directory or file path') but doesn't add meaning beyond schema. Baseline 3 due to 100% schema coverage.

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

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

Description clearly states 'Validate data files: JSON parse, CSV shape, SQLite integrity.' It specifies the resource (data files) and actions (validate, parse, check integrity), distinguishing from siblings like delimit_data_migrate.

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

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

Explicitly provides 'When to use' (smoke check before relying on data files) and 'When NOT to use' (for migration status or backups), naming alternatives delimit_data_migrate and delimit_data_backup.

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?

Despite no annotations, the description thoroughly discloses behavioral traits: side effects (writes transcripts), model invocation details (configured providers, tier differences, BYOK for Pro/Premium), scope enforcements (3-model minimum, Grok tiebreaker), and modes (dialogue vs debate). This covers all necessary behavioral 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?

The description is concisely structured with front-loaded purpose, clear 'when to use/when not to use' sections, sibling contrast, and side effects list. Every sentence adds value 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?

Given the tool's complexity (multi-model deliberation, tiers, scopes), the description covers usage guidelines, behavioral side effects, tier differences, parameter details, and sibling context. With an output schema present, return values are not needed, making the description 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?

While input schema coverage is 100%, the description adds meaning beyond schema by explaining mode types ('dialogue' short turns, 'debate' long essays), default rounds per mode, scope override values ('strategic', 'social', 'operational'), and that empty scope triggers classification. This enriches parameter understanding.

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 'Run multi-model consensus via AI-to-AI deliberation (Pro)' and specifies use cases like foundational decisions, pricing, naming, public-facing copy. It distinguishes from sibling tools delimit_models and delimit_security_deliberate, making the purpose specific and unambiguous.

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

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

The description explicitly outlines when to use (foundational decisions, cross-model contradiction-detection) and when not to use (routine implementation choices). It also contrasts with sibling tools, providing clear context for selection.

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

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

Discloses read-only nature, calls ai.deliberation.get_deliberation_status, reads ~/.delimit state. No annotations provided; description fully covers 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?

Well-structured with clear sections, front-loaded purpose, and concise. Every sentence adds value.

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?

Complete description including output schema details. Covers all aspects for a status check 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?

No parameters; description states 'Args: None.' Schema coverage is 100% (empty). With zero params, baseline is 4.

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 it checks deliberation usage and mode, distinguishing it from siblings: delimit_deliberate runs the panel, delimit_models manages keys.

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

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

Explicit 'When to use' and 'When NOT to use' sections, plus sibling contrast. It specifies use before delimit_deliberate to check quota and OAuth state.

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 transparently discloses side effects: license gating (require_premium), local disk and CPU consumption via docker buildx, and no network push. It also mentions response routing. Lacks details on error behavior or build timeouts, but otherwise thorough.

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

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

The description is well-organized into logical sections (purpose, when to use, when not to use, sibling contrast, side effects). It is front-loaded with the core purpose. While comprehensive, it could be slightly more concise; the sibling contrast section, though helpful, is somewhat lengthy.

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 (build step with side effects) and the presence of an output schema (mentioned in context), the description adequately covers purpose, usage, side effects, and relationships to siblings. It does not detail the output format but that is handled by the output schema. Minor gaps: no mention of required permissions or error recovery.

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?

Both parameters (app and git_ref) are fully described in the schema (100% coverage). The description adds only boilerplate context (e.g., 'git ref (Pro)') but does not provide additional semantic guidance beyond what the schema already offers.

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

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

The description clearly states the verb 'Build container images for an app at a specific git ref', identifies the resource (container images), and distinguishes from siblings by positioning itself as the second step in the deploy chain. The title implies this is the build step, and the description reinforces that.

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

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

Explicit 'When to use' and 'When NOT to use' sections provide clear context for when this tool is appropriate, including the full chain (plan -> build -> publish -> verify -> rollback) and specific sibling alternatives for when not to use (e.g., delimit_deploy_publish, delimit_deploy_site).

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

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

No annotations are provided, so the description carries full burden. It thoroughly discloses behaviors: actions gated by require_premium, deterministic error for unknown actions, detailed per-action side effects (read-mostly, local writes, network writes, mutations, etc.), error handling, and dry_run suppression behavior. This is comprehensive.

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 very long and detailed, with multiple paragraphs and bullet-like sections. It is well-structured with headers, but could be more concise. Some per-action details might be better placed in separate docs. However, for a complex dispatch tool, brevity is difficult; it earns a 3.

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 (10 parameters, 8 actions, no annotations, output schema exists), the description is remarkably complete. It covers all actions, side effects, parameter usage by action, error handling, and output wrapping. Every necessary aspect for correct selection and invocation is covered.

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?

Input schema has 100% description coverage for all 10 parameters. The description adds contextual value beyond schema, such as case-insensitive action matching, dry_run behavior (suppresses only final publish), and which parameters are ignored per action. However, much parameter usage is already in schema, so baseline 3; extra context earns a 4.

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 it is a 'unified deployment entry point' that dispatches to eight deploy actions. It specifies the verb (dispatches) and resource (deploy operations), and distinguishes from sibling aliases and related tools like delimit_obs_status, delimit_test_smoke, and delimit_release_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?

Explicitly states when to use ('as the single MCP-registered deploy surface when the caller wants to pick the deploy operation by name') and when NOT to use ('from internal code paths or when you want the operation's behavior and gate to surface at the right name'), with specific alternatives listed (e.g., 'prefer the specific alias'). Also contrasts with non-deploy tools for health checks, smoke tests, and release tracking.

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

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

No annotations provided, so description fully addresses behavior: license check, local version bump, prepublishOnly hook, pack, network publish, irreversibility, and dry_run effects. Mentions a known regression.

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?

Well-structured with headings and bullet points, front-loaded purpose, and minimal redundancy. Slightly long but each sentence adds value.

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 complexity (4 params, output schema present, no annotations), description thoroughly covers all aspects: purpose, usage guidelines, behavioral side effects, parameter effects, and output context.

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

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

Schema coverage is 100% with descriptions, so baseline is 3. Description adds context about dry_run suppressing only publish step, but does not significantly extend beyond schema.

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

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

Clearly states 'Publish an npm package: version bump, pack, and push to registry' with specific verb and resource. Distinguishes from siblings like delimit_deploy_site and delimit_deploy_publish.

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

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

Explicitly defines when to use (ship new npm package version), when not to use (deploy site, push containers, dry-run locally), and provides alternatives. Also specifies prerequisite chain and founder approval requirement.

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 fully shoulders the burden of behavioral disclosure. It clearly describes side effects: auto-chaining of delimit_security_audit and delimit_gov_evaluate, with fail-closed behavior on critical findings (halting and returning status='blocked'). This provides essential behavioral transparency beyond basic read/write intent.

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 well-structured with clear headings for usage guidelines, sibling contrast, and side effects. It is concise—every sentence adds value—and front-loads the core purpose. No redundant or extraneous information.

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

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

Given the tool's moderate complexity (3 params, auto-chaining behavior, output schema present), the description covers all necessary context: when to use, side effects, and failure modes. The presence of an output schema reduces the need to describe return values, and the description adequately addresses the tool's role in the deployment pipeline.

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

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

Schema coverage is 100% and each parameter already has a clear description. The tool description does not add additional parameter details beyond what the schema provides, but the schema descriptions are sufficient. A score of 3 is appropriate as the description does not degrade understanding but adds no extra value for parameters.

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

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

The description clearly states the tool's purpose: 'Generate a deploy plan with security preflight (Pro).' It specifies a concrete action (generate a deploy plan) and a key differentiator (security preflight). It also explicitly contrasts with sibling tools delimit_deploy_build and delimit_deploy_publish, making its distinct role unmistakable.

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

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

The description provides explicit guidance on when to use ('as the first step in the deploy chain') and when not to use ('to actually build images' or 'to ship code'). It names specific alternatives (delimit_deploy_build, delimit_deploy_publish), enabling the agent to make an informed choice.

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

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

No annotations provided, but description details side effects: premium gating, network writes to container registry via backend. Lacks mention of reversibility but still strong.

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