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

The description goes well beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing concrete side effects: it applies the license key when provided, and when auto_permissions=True it writes .claude/settings.json. It also explains scoring semantics — skipped checks (premium on free tier, no test framework) don't count against the score — which is critical behavioral context an agent could not infer from the schema or annotations. This file-write disclosure is especially valuable since destructiveHint=false might otherwise imply no state changes.

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

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

The description is compact and superbly organized with labeled sections: core purpose first, then When to use, When NOT to use, Sibling contrast, and Side effects. Every sentence earns its place — there is no filler, and the labeled structure makes it trivially scannable for an agent. The length is justified by the tool's complexity (side effects, multiple checks, sibling ambiguity).

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

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

This is a mutation tool with real side effects and scoring behavior, and the description covers every angle an agent needs: purpose, usage conditions, exclusions, sibling differentiation, side effects, parameter effects, and handling of edge cases (skipped checks). The output schema exists, so return values need no explanation. Nothing material is missing 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%, so the baseline is 3 — the schema already documents all three parameters with types, defaults, and individual descriptions. The tool description adds genuine semantic value beyond the schema by explaining the behavioral effect of key parameters: license_key 'applies the license key when provided' and auto_permissions triggers the .claude/settings.json write. This links parameters to consequences rather than just formats, earning 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 first sentence states a specific verb and resource with a concrete outcome: 'Activate Delimit and run a readiness checklist.' The scope is further pinned down by naming the exact areas checked (license, MCP, governance, tests, permissions, premium), which distinguishes it from the vast sibling list. The explicit sibling contrast against delimit_diagnose and delimit_quickstart makes the tool's identity 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 has an explicit 'When to use' section (post-install confirmation that everything is wired up) and a 'When NOT to use' section that names the correct alternatives: delimit_diagnose for diagnostic debugging and delimit_quickstart for first-run discovery. This is the clearest possible routing guidance — an agent knows exactly when to pick this tool and when to pick a sibling.

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 side-effect scope ('read-only on the policy store') and names the underlying API call (ai.agent_policy.check_agent_permission), adding value beyond the annotations. Annotations set readOnlyHint=false, but the description clarifies that the policy store itself is not mutated; it could still have other side effects, which is a minor ambiguity.

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 front-loaded purpose, explicit usage sections, sibling contrast, and side effects. Every sentence earns its place, and the description is concise without sacrificing necessary guidance.

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, when to use, when not to use, sibling differentiation, side effects, and the underlying call. With full parameter schema coverage and an output schema present, an agent has essentially everything needed to invoke this tool correctly.

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

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

Schema description coverage is 100%, with model and action already clearly described in the input schema. The description reinforces the permission-check context but does not add new parameter-level semantics, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource: 'Check if a model is allowed to perform an action under agent policy.' The sibling contrast explicitly distinguishes this from delimit_agent_policy and delimit_gov_evaluate, so an agent can identify the tool's unique role.

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' and 'When NOT to use' guidance, naming the exact alternatives (delimit_agent_policy and delimit_gov_evaluate). This fully routes an agent to the appropriate tool with no inference required.

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?

Goes well beyond the annotations by disclosing the full side-effect profile: writes a completion record, flips task status from 'dispatched' to 'completed', persists result and files_changed, appends an audit log entry, coerces files_changed from a comma string to a list, and confirms no license gate or notification. This level of behavioral disclosure is exemplary.

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 structured into clear labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence carries actionable information with no filler, and the core purpose is front-loaded before the details.

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

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

The description fully covers the tool's place in the dispatch lifecycle, its mutation semantics, its exclusions, and its behavioral caveats. Even with an output schema present, nothing needed for correct invocation is missing.

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

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

The schema already covers all three parameters (100% coverage), so the baseline is 3. The description adds useful extra semantics by explaining that task_id originates from delimit_agent_dispatch and that files_changed is coerced from a comma string to a list, which the schema does not state.

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

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

The description opens with a specific verb and resource: 'Close a dispatched agent task by recording the outcome.' It clearly distinguishes itself from the sibling tools by explicitly contrasting with delimit_agent_dispatch, 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?

Provides an explicit 'When to use' section with a concrete lifecycle position, and a 'When NOT to use' section naming the exact alternative tools. It also warns against repeated calls on the same task_id, which is exactly the kind of disambiguation an agent needs.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by stating 'Side effects: read-only', naming the underlying call (ai.agent_dispatch.get_agent_dashboard), and clarifying the aggregated nature of the view. This goes beyond the annotations without contradicting them.

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 labeled sections: when to use, when not to use, sibling contrast, side effects, args, and returns. It is compact, front-loaded with the core purpose, and every sentence adds value without unnecessary filler.

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

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

For a zero-parameter, read-only dashboard tool with an output schema, the description is complete: it explains the purpose, usage boundaries, sibling differences, side effects, underlying function, and a summary of the return value. Nothing needed to correctly select and invoke this tool is missing.

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

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

The tool has zero parameters, so the baseline is 4. The description explicitly states 'Args: None', which removes any ambiguity for the agent even though the schema already shows an empty object. There is no parameter semantics to add beyond this.

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

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

The description states a specific verb and resource ('View the multi-agent orchestration dashboard') and explicitly distinguishes this tool from siblings: it returns an aggregated dashboard view while delimit_agent_status returns raw records. This makes the tool's purpose unambiguous even among a large sibling list.

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

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

The description gives explicit when-to-use guidance ('one-shot read of all agent activity grouped by assignee/status') and when-not-to-use guidance with named alternatives (delimit_agent_status for single task status, delimit_agent_dispatch for dispatching work). This fully routes an agent to 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?

The description thoroughly discloses side effects: it writes a JSON record to disk, adds an audit log entry, coerces comma-separated strings to lists, and does NOT spawn a subagent. It even states that the caller is responsible for invoking the Agent tool separately and notes that this surface is not license-gated. The write behavior is consistent with readOnlyHint=false and destructiveHint=false, so there is no contradiction.

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

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

The description is long, but every section earns its place: purpose, usage boundaries, sibling differentiation, and side effects are all critical for a tool that could easily be mistaken for an execution tool. Key information is front-loaded with clear headings and the most important caveat ('records dispatch but does NOT run the work') appears early.

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

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

For a tool with 7 parameters, false read-only/destructive hints, and an important non-execution caveat, the description is complete. It covers the dispatch lifecycle, side effects, sibling alternatives, coercion behavior, and what the caller must do next. An output schema exists, so return-value documentation is not required.

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

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

The schema already has 100% description coverage for all 7 parameters, so the baseline is 3. The tool description adds meaningful semantic value by explaining that tools_needed and constraints are coerced from comma strings to lists, and by framing the parameter set as the engineering-work surface with assignee, tools_needed, and constraints. This goes slightly 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 opens with a concrete verb and resource: 'Record an engineering-task dispatch with full audit trail.' It explicitly distinguishes the tool from actual execution by stating it records intent rather than running the work, and it names sibling tools it is not (status, handoff, complete). An agent can immediately understand what this tool does and how it differs from nearby tools.

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

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

The description provides dedicated 'When to use' and 'When NOT to use' sections with specific conditions: use as the planning/audit surface when delegating parallelizable engineering work, and avoid for auto-execution, conversational tasks, sub-5-minute work, or missing functions. It also names alternative tools explicitly (delimit_agent_status, delimit_agent_handoff, delimit_agent_complete), leaving no ambiguity about 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses concrete side effects: writes a handoff record via ai.agent_dispatch.handoff_task and updates the assignee on the task. This tells the agent exactly what state changes will occur and confirms the operation is a non-destructive but persistent mutation.

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

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

The description is compact and well-structured, with short labeled sections for usage, exclusions, sibling contrast, and side effects. Every sentence carries distinct information, and the essential purpose is front-loaded in the first line.

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 three-parameter tool with a full input schema, annotations, and an output schema, this description covers when, when-not, how it differs from siblings, and its side effects. Nothing an agent needs to decide whether to call it is missing.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters clearly. The description adds no new parameter-level details, but it reinforces the context by explaining the handoff scenario and the role of the next model. Baseline 3 is appropriate given the full schema coverage.

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

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

The opening sentence uses a specific verb and resource: 'Hand off an agent task to a different AI model.' It also names the exact sibling it is not (delimit_agent_complete) and clarifies that this transfers, rather than ends, the task. An agent can immediately distinguish it from close-out and dispatch tools without opening schemas.

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

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

The description explicitly states both when to use ('when an executor is blocked or when cross-model review is required') and when NOT to use ('to close out the task... or create a new one'), naming the alternative tools. This gives an agent clear, decision-ready routing guidance with no inference required.

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?

Beyond the minimal readOnlyHint/destructiveHint annotations, the description discloses exactly which actions read vs write, that dispatch only records intent and never runs a subagent, the deterministic guards (kill switch, circuit breaker, ghost-title reject, anti-duplicate), and the consistent error shape. This fully covers the behavioral profile an agent needs.

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

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

The description is long, but it is organized into clear sections and front-loaded with the most important usage facts. It loses a point for a couple of deliberate redundancies, such as the repeated warning that dispatch records rather than executes, but overall the density is justified by the tool's four-action complexity.

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 multi-action dispatcher with a large sibling family and 12 parameters, the description covers when to use it, what each action does, side effects, guards, errors, and relationship to aliases and adjacent tools. An output schema exists, so return-value detail is not the description's burden.

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 input schema already documents each parameter's action-specific meaning and defaults. The description adds context around dispatch's effect (persisting agent_prompt) but does not materially add parameter-level detail beyond the schema, so the high-coverage baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource ('Manage the agent-task lifecycle') and immediately names the four actions: dispatch, status, handoff, complete. It also distinguishes the tool from the delimit_agent_* aliases and from delimit_ledger_add, so an agent can tell exactly what this surface is for.

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 tell the agent to select this combined surface for name-based action selection and to prefer the specific delimit_agent_* aliases from internal code paths. It even warns against expecting dispatch to execute a subagent and names the separate prefix-sharing tools that are not actions.

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?

Annotations already indicate this is not read-only and not destructive. The description adds value by stating the exact side effect: 'writes the link via ai.agent_dispatch.link_ledger_item.' This tells the agent the operation mutates state and reveals the underlying write path, which is useful behavioral context beyond the 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?

The description is longer than the bare minimum but every section earns its place: purpose, when to use, when not to use, sibling contrast, and side effects. It is well-structured and front-loaded with the core purpose, though it is slightly more verbose than strictly necessary.

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 and annotations, the description covers the essential context completely: what the link does, when to create it, when to avoid it, how it differs from related tools, and what side effect it performs. Nothing critical is missing.

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

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

Schema description coverage is 100% and both parameters have descriptive names plus format hints (AGT-xxx, LED-xxx/STR-xxx). The description itself does not add parameter-level detail, but the schema already carries that burden, so a 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 opens with a specific verb and resource: 'Link an agent task to a ledger item' and explains the purpose (dashboard relationship). It also distinguishes itself from delimit_agent_dispatch and delimit_ledger_link, so an agent can quickly tell what this tool does versus its most similar 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?

The 'When to use' section gives a clear precondition: after delimit_agent_dispatch creates a task and the dashboard should show the ledger item. The 'When NOT to use' section explicitly names the alternative tools for dispatching and completing tasks, and the sibling contrast further disambiguates from delimit_ledger_link.

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 conditional write side effect: providing any of ledger/memory/deploy/evidence/secrets/custom_constraints writes via ai.agent_policy.set_agent_policy, while empty/no-changes is read-only. This goes well beyond the readOnlyHint: false annotation and gives the agent a precise mental model of when state changes occur.

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?

Organized with labeled sections for purpose, usage, side effects, and value formats. Every sentence contributes meaningful selection or invocation guidance, and the most decision-relevant content is front-loaded.

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

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

The description covers purpose, alternatives, side effects, allowed values, and write-versus-read behavior. With an output schema present, no return-format detail is needed; the description fully equips 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real value by enumerating allowed access levels ('read-only', 'read-write', 'none') and boolean flags for deploy/secrets. It also provides a concrete custom_constraints example, compensating for the absence of enums in the schema.

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

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

Opens with a clear verb-resource statement: 'Set or view per-model governance permissions.' It then names the exact resources governed (ledger, memory, evidence, deploy, secrets) and contrasts itself with delimit_gov_evaluate, so an agent can distinguish it without opening the schema.

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

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

Provides explicit 'When to use' and 'When NOT to use' guidance, naming delimit_gov_evaluate for runtime evaluation and delimit_project_config for session policy. The sibling contrast further clarifies that this tool configures the policy those evaluations consume.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description consistently reinforces 'read-only' while adding context beyond annotations: it discloses the underlying backend call (ai.agent_dispatch.get_agent_status), states it returns raw status records rather than aggregates, and clarifies open/closed task semantics. No contradiction with 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?

Every line earns its place: purpose sentence, when-to-use, when-not-to-use, sibling contrast, and side effects are cleanly separated into labeled sections. The most decision-relevant information (purpose) is front-loaded, and the structure makes the guidance scannable for an agent.

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

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

For a tool with one optional parameter, a present output schema, and safety annotations, the description covers everything needed for correct selection and invocation: purpose, scoping behavior, exclusions, sibling differentiation, and side effects. Nothing material is missing.

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

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

Schema coverage is 100%, so the schema already documents task_id with an example and the 'empty to list all' behavior. The description restates this same information ('either a single task_id or all tasks when task_id is empty') without adding new parameter-level meaning. Baseline 3 is appropriate since the schema carries the semantic load.

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?

Opens with a specific verb+resource statement ('Check status of dispatched agent tasks') that immediately conveys the operation. It also distinguishes itself from siblings by naming delimit_agent_dashboard as the aggregate-view alternative and clarifying this tool returns raw status records, so an agent can disambiguate without inspecting other tools.

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

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

Provides explicit 'When to use' and 'When NOT to use' sections that name exact alternatives (delimit_agent_dispatch, delimit_agent_complete) and the precise condition for choosing each. The sibling contrast with delimit_agent_dashboard further sharpens the decision boundary. Nothing is left to inference.

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

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

The description discloses side effects beyond annotations: it is gated by require_premium, calls models via ai.cross_model_audit.audit, and performs no ledger write. This gives the agent important context about cost, availability, and persistence behavior that the annotations do not convey.

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 and front-loaded purpose. Every sentence adds value—usage context, sibling contrast, or side effects—without unnecessary 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?

The definition is complete for selecting and invoking the tool correctly: purpose, routing, side effects, and sibling relationships are all covered. An output schema exists, so the lack of return-value detail in the description is acceptable.

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

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

Parameter schema coverage is 100%, so the schema already documents all parameters with defaults and allowed values. The description reinforces the lenses but adds no substantially new parameter semantics beyond what the schema 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 performs a cross-model code audit across three lenses with synthesized output. It explicitly distinguishes itself from sibling tools delimit_review and delimit_deliberate, making selection 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 gives explicit when-to-use and when-NOT-to-use guidance, naming the exact alternatives (delimit_deliberate, delimit_review). The sibling contrast further clarifies how this tool differs from those 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?

Annotations only indicate readOnlyHint=false and destructiveHint=false. The description goes well beyond this by detailing side effects per loop_type: 'cycle/build dispatches swarm work; social drafts replies; deploy runs gates and publishes.' It also discloses that 'All loops write to the loop_engine's session record.' No contradiction with annotations 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 well-structured with clear labeled sections: primary statement, when to use, when not to use, sibling contrast, side effects, and loop types. Every section earns its place and the critical scoping information is front-loaded. The ticket reference 'LED-239' is minor noise but does not undermine clarity.

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

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

For a complex loop-driving tool with an output schema, the description is highly complete: it explains the loop variants, side effects, exclusions, and alternative tools. The agent has enough context to invoke it correctly without needing additional inference.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds behavioral context for loop_type values (cycle/build/social/deploy) but does not meaningfully expand on action or cycle_mode beyond what the schema provides. This is adequate but not exceptional.

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

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

The description opens with a specific verb and resource: 'Execute one iteration of a governed continuous loop.' It also explicitly contrasts itself with sibling tools, stating 'delimit_loop_status reads; delimit_loop_config sets policy; this drives one iteration.' This makes the tool's unique 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 an explicit 'When to use' section and an explicit 'When NOT to use' section, naming the exact alternative tools (delimit_loop_status, delimit_loop_config) for those cases. This gives an agent clear branching 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?

Even though annotations only say readOnly=false/destructive=false, the description discloses significant side effects: start spawns a daemon thread, stop halts, each tick writes task_id to JSONL, and safeguards are consulted before each tick. It also mentions the log path for triage. This is exactly the behavioral context annotations don't convey.

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?

Structured into headers, front-loaded with the core statement, and every section contributes either selection rules or behavioral cautions. Minor redundancy between 'When NOT to use' and 'Sibling contrast' does not hurt readability.

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

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

Given that an output schema exists and the annotations are minimal, the description supplies selection rules, side effects, logging behavior, safeguards, and premium gating. Nothing critical for invoking the tool correctly seems missing.

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

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

Schema coverage is 100%, so the baseline applies. The description mostly reiterates which params are used on start and does not substantially extend the schema's per-parameter descriptions; it provides action-level side effects more than new parameter semantics.

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 lead sentence names the resource ('daemon') and function ('background auto-pull,' 'ticks governed loop'), and the sibling contrast explicitly separates it from delimit_build_loop and delimit_loop_status. An agent can tell what it does without inspecting the schema.

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

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

Includes an explicit 'When to use' block, a 'When NOT to use' block with named alternatives (delimit_build_loop for one-shot iteration, delimit_loop_status for metrics), and a sibling-contrast line. Also notes premium gating, which is a real selection constraint.

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 goes beyond the annotations by detailing side effects: read-only on git/spec inputs, writes only when output_file is provided, and prepends rather than overwrites CHANGELOG.md, preserving history. This is consistent with readOnlyHint=false and destructiveHint=false and gives practical safety-relevant 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 well organized with labeled sections, bullets, and a front-loaded summary. Every section earns its place, and the side-effects paragraph is a valuable safety emphasis rather than 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 the tool's complexity (two modes, 8 optional parameters, output behavior), the description is complete enough: it covers when to use it, when not to, what each mode does, and side effects. The schema already documents all parameters and an output schema exists, so no critical return-value or parameter detail is missing.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds meaningful conceptual structure by mapping repo_path to git mode and old_spec + new_spec to spec mode. It also clarifies what git mode does (reads git log, categorizes commits, pulls completed ledger items) and that spec mode produces an API changelog, which helps an agent select the right parameter group.

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

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

The description opens with a specific verb and resource: 'Generate a changelog from git + ledger (git mode) or spec diff (spec mode).' It also names the two sibling tools it is not (delimit_explain, delimit_release_plan), making the tool's unique output 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 has explicit 'When to use' and 'When NOT to use' sections, naming exact alternatives and the conditions that route to them. The sibling contrast reinforces these decision boundaries, so an agent knows precisely when to select this tool over delimit_explain or delimit_release_plan.

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 itself clearly discloses that action='claim'/'release' mutate lock state and action='check' is read-only. However, the annotations declare readOnlyHint=true and idempotentHint=true for the whole tool, directly contradicting the mutating actions. Per the rubric, this contradiction forces a score of 1.

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 scannable labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence carries distinct information, and there is 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?

The description is largely complete for a 4-parameter tool: it covers use cases, exclusions, sibling differentiation, side effects, and action-specific parameter requirements, and an output schema exists. The only deduction is due to the contradictory annotations, which force an agent to reconcile conflicting signals about whether the tool is read-only.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds valuable operational meaning beyond the schema: claim before editing, release after committing, and file_path being required for claim/release. It also clarifies which actions are read-only versus mutating, helping the agent choose valid parameter combinations.

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

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

The description states a specific verb-resource pair: 'Detect / prevent multi-model file edit collisions' and explains it tracks per-file edit ownership. It also contrasts with delimit_swarm, so an agent can distinguish it from siblings without opening schemas.

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

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

The description explicitly provides 'When to use' and 'When NOT to use' guidance, naming the exact cross-model workflow and rejecting single-model or general filesystem locking. It also gives a sibling contrast, making the selection criteria unambiguous.

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 states 'Side effects: read-only on the project' and 'no file write,' but the annotations declare readOnlyHint=false. These directly contradict each other: one says the operation is read-only, the other says it is not. Per the rubric, this contradiction forces a score of 1.

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 short labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence earns its place, and the most important information is 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?

For a simple one-optional-parameter tool with an output schema, the description covers purpose, exclusions, alternatives, side effects, and response behavior. It is nearly complete, but the direct contradiction between the stated read-only behavior and readOnlyHint=false prevents full marks.

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 adds meaningful parameter-related context by stating that project_path is sanitized via _sanitize_path, which is not present in the input schema. This exceeds the baseline.

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

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

The description opens with a specific verb and resource: 'Export the current governance config as a shareable JSON bundle.' It clearly identifies the output format and distinguishes this tool from its round-trip counterpart, delimit_config_import, making sibling differentiation immediate and 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 explicitly states when to use the tool ('to package a project's delimit.yml + GitHub Action workflow'), when NOT to use it, and names the alternatives (delimit_gov_policy and delimit_init). This is ideal routing guidance for an 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses concrete side effects: writes the policy file under project_path, conditionally writes a GitHub Action workflow when write_workflow=True, and sanitizes project_path via _sanitize_path. This is exactly the behavioral context an agent needs for a mutation tool.

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

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

The description is front-loaded with the core purpose, then organized into clearly labeled sections (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence earns its place—no filler or repetition of schema content.

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

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

For a 3-parameter mutation tool with a full output schema and annotations, the description covers purpose, usage boundaries, side effects, and path sanitization. There are no gaps an agent would need to resolve before invoking the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining behavioral consequences of write_workflow=True (writes workflow file if present in bundle) and clarifying that config_json is the output of a prior export from another project. These enrich parameter meaning beyond the schema, though the schema already does most of the work.

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 opening sentence states a specific verb (import), resource (governance config from a JSON bundle), and destination (into a project). The sibling contrast 'delimit_config_export produces; this consumes' further differentiates it from its closest counterpart, so an agent can distinguish it without inspecting schemas.

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

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

The description explicitly states when to use (apply a previously-exported bundle, round-trip counterpart to delimit_config_export) and when NOT to use (initialize a fresh project via delimit_init, or load existing config via delimit_project_config action="load"). Alternatives are named with conditions, leaving nothing to inference.

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

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

The description clearly discloses side effects for each content type, including the non-obvious report behavior: COMPOSE + STAGE ONLY, posts nothing to X, and creates no live GitHub Release. This goes far beyond the minimal readOnlyHint/destructiveHint annotations and prevents the agent from assuming all three types actually publish externally.

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?

Structured with clear labeled sections (When to use, When NOT to use, Sibling contrast, Side effects), each sentence adds information. The core action is stated upfront, and the detail is proportionate to the tool's branching behavior.

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

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

For a tool with three content types that behave very differently, the description covers when, when not, sibling alternatives, side effects, and the critical report staging caveat. An agent has enough context to invoke it correctly and interpret the outcome.

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

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

The input schema already fully documents the single content_type parameter at 100% coverage, so the baseline is 3. The description adds value by mapping each allowed value to its concrete behavior (post, generate+upload, or stage-only), which is meaningful beyond the schema text.

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

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

The description uses a specific verb ('trigger', 'publish') and names the exact resources: tweet, YouTube video, or report. It also distinguishes itself from the sibling tools delimit_content_schedule and delimit_content_queue by stating this performs a single publish step.

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 name the exact conditions and the alternative tools to use instead. The sibling contrast further clarifies the division of labor: schedule reads, queue mutates, this publishes.

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?

Even though annotations already mark readOnlyHint=false and destructiveHint=false, the description goes further by detailing per-action side effects: seed populates defaults, add appends, add_report stages without posting, and status is read-only. This is exactly the behavioral nuance an agent needs.

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 longer than average but well-organized with labeled sections and front-loaded scope. Each section earns its place given the multi-action, side-effect-bearing nature of the tool, though a couple of phrases could be tightened.

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

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

For a tool with two optional parameters and no required ones, the description is complete: it covers purpose, action semantics, side effects, sibling routing, and read-only behavior. An output schema exists, so the lack of return-value detail in the description is not a gap.

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

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

Input schema covers both parameters 100%, so the bar is baseline 3. The description adds meaning by attaching behavioral outcomes to each action value ('seed' populates defaults, 'add' appends tweet items, 'add_report' composes/stages) and clarifies that status is read-only, enriching the bare action enum.

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

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

The description opens with a specific verb and resource ('Manage the tweet, video, and report content queues') and then enumerates exactly what actions are possible. It explicitly contrasts with delimit_content_publish and delimit_content_schedule, making the tool's distinct role 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?

Provides a dedicated 'When to use' section, a 'When NOT to use' section naming the correct alternatives, and a direct sibling contrast. An agent can confidently decide between this tool, publish, and schedule without inferring from 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?

The description states 'Side effects: read-only' and names the underlying call, which would otherwise be strong transparency. However, the annotations declare readOnlyHint: false, directly contradicting the 'read-only' claim. Per the contradiction rule, this dimension must score 1.

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 structured with clear labeled sections, and every section serves a purpose: purpose, usage boundaries, sibling contrast, side effects, args, and returns. Although longer than a one-liner, none of it is filler and the key scoping information is 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?

Given the tool has zero parameters and an output schema exists, the description still adds a preview of the returned dict and the underlying API. It covers when to use, when not to use, side effects, and invocation shape, so an agent has everything needed to call it correctly — apart from the read-only annotation mismatch already penalized.

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 has zero parameters and schema description coverage is 100%, so there is no parameter detail for the description to add. The description explicitly confirms 'Args: None', eliminating any ambiguity about invocation.

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

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

The description opens with 'View the upcoming content schedule' — a specific verb and resource — and explicitly scopes it to queued, pending, and recent items. It also differentiates itself from sibling tools by noting that delimit_content_queue mutates queue state while this reads the resulting schedule.

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

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

It provides explicit 'When to use' and 'When NOT to use' sections, naming delimit_content_publish and delimit_content_queue as the correct alternatives for publishing and queue management. The sibling contrast reinforces the read-vs-mutate boundary, so an agent is unlikely to select the wrong 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?

Despite sparse annotations, the description discloses per-action side effects: 'list' is read-only, 'create' writes a new branch namespace, and 'merge' mutates the main namespace and closes the branch. It also explicitly states what the tool does NOT touch: code repository, git state, license gate, notification, or ledger. This goes well beyond the annotation fields and gives the agent a reliable behavioral model.

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 and front-loaded purpose. There is minor redundancy between the 'When NOT to use' section and the 'Sibling contrast' section, both covering delimit_context_snapshot, but overall every section earns its place and no filler exists.

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

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

Given the tool's multi-action complexity and mutable-vs-immutable semantics, the description is thorough. It covers when to use it, when not to use it, side effects, exclusions, and the filesystem target. The output schema is present, so return-value detail is not required here.

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

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

The input schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds useful semantic context by explaining what each action means ('list' inventories branches, 'create' mints a new branch, 'merge' folds a branch back into main), which enriches the action parameter meaning beyond the schema alone.

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

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

The description states a specific verb and resource: 'Manage mutable working branches of a venture's context.' It immediately distinguishes itself from related tools like delimit_context_snapshot and delimit_context_read, and from git branch operations. An agent can clearly identify what this tool does and what it does not do.

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

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

The description gives an explicit 'When to use' section with a concrete scenario ('what if we pivoted?'), a 'When NOT to use' section naming alternative tools, and a sibling contrast section. This is exemplary routing guidance that leaves little to inference.

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

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

The description itself is highly transparent, enumerating per-action side effects, deterministic errors, and which actions write vs read. However, it directly contradicts the idempotentHint:true annotation: write bumps a version counter, snapshot creates new timestamped directories, branch create errors when the branch already exists, and branch merge deletes the branch after mutating it. These are not idempotent 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 long but justifiably so: 8 parameters and 6 distinct actions require this level of detail. It is organized into scannable sections, front-loaded with the core purpose, and every sentence contributes operational knowledge rather than padding.

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 of a six-action dispatcher with mixed read/write/destructive behavior, the description is essentially complete: it covers storage namespace, cross-session persistence, per-action side effects, error format, and exclusions. An output schema exists to carry exact return shapes, so no critical gap remains for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful action-conditioned semantics: name is required only for read/write, label only for snapshot, content and artifact_type only for write, branch_name required for branch create/merge, and invalid action or branch_action values short-circuit before the backend call. This is selection guidance beyond the schema text.

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 opening sentence states a precise verb and resource: 'Unified context-filesystem entry point — dispatches to one of six actions.' It immediately describes the venture-scoped, versioned storage at ~/.delimit/context/<venture>/ and distinguishes itself from the delimit_context_* aliases and delimit_memory_* tools, so an agent knows exactly what this tool is and is not.

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 has explicit 'When to use' and 'When NOT to use' sections that name concrete alternatives: the specific delimit_context_<action> aliases, delimit_memory_store, and delimit_memory_search. It also explains the snapshot vs branch distinction and notes that this tool never touches git or a code repository.

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?

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the description does not need to re-cover those. It adds useful context beyond annotations by specifying side effects: creates the venture directory and metadata files via ai.context_fs.init_context, and explicitly states it is safe to call repeatedly. This is meaningful additional behavioral disclosure.

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

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

The description is compact, organized with clear headings, and front-loads the core purpose before usage guidance and side effects. Every sentence contributes useful information, with no filler or repetition of schema details.

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

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

For a tool with one optional parameter, existing output schema, and annotations covering idempotency and non-destructiveness, the description is complete. It explains when to use it, when not to use it, the side effects, the versioning model, and the fact that it is safe to rerun. Nothing needed for correct invocation is missing.

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

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

The input schema covers 100% of the single parameter with a default value and its own description ('Venture/project namespace key'). The tool description reinforces the venture context but does not add new semantic detail beyond the schema. Baseline 3 is appropriate because the schema already carries the full parameter documentation burden.

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

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

The description states a specific action: 'Initialize a context filesystem namespace for a venture,' which clearly identifies the verb, resource, and scope. It also distinguishes this tool from delimit_memory_* and delimit_context_read, so an agent can tell it apart from siblings without additional investigation.

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

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

Usage guidance is explicit: 'once per venture, the first time you want to persist cross-session/cross-model context.' It also gives clear when-not-to-use conditions with named alternatives (delimit_memory_store for single-session memory, delimit_context_read for reading artifacts), plus a sibling contrast explaining the venture-scoped and versioned nature.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by explicitly stating 'Side effects: read-only' and revealing the internal call to ai.context_fs. This gives the agent behavioral context beyond the structured annotations without contradicting them.

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 labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence earns its place and the information 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?

For a single-parameter, read-only listing tool with full schema coverage and an output schema present, the description covers purpose, usage boundaries, sibling distinction, and side effects. Nothing essential for an agent to call it correctly is missing.

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

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

Schema description coverage is 100%, with the single 'venture' parameter documented as 'Venture namespace key. Required.' The description reinforces that the venture is the scope of the listing but does not add substantial new meaning beyond the schema. 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 a specific verb and resource: 'List all artifacts in a venture's context filesystem.' It clearly distinguishes itself from the sibling by noting it returns metadata for all artifacts rather than a single artifact's content. An agent can immediately understand what the tool does and how it differs from related context tools.

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

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

The description provides explicit 'When to use' and 'When NOT to use' guidance, naming specific alternatives: delimit_context_read for artifact content and delimit_memory_recent for memory scans. It also includes a sibling contrast that reinforces the correct selection decision.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds 'Side effects: read-only' and 'Calls ai.context_fs,' but the read-only statement duplicates the annotation and the implementation detail adds limited behavioral context beyond what is already structured.

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 for usage, exclusions, sibling contrast, and side effects. It is mostly efficient, though the 'STR-048' reference and the redundant read-only statement add minor noise.

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

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

For a simple read operation with only two fully documented parameters, an output schema, and annotations covering side-effect safety, the description covers purpose, usage boundaries, sibling contrast, and behavior. Nothing important is missing 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?

Schema description coverage is 100% and both parameters are documented in the schema with 'Artifact name. Required.' and 'Venture namespace key. Required.' The description's mention of 'by name within a venture namespace' reinforces the schema but does not add significant meaning beyond it, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Read an artifact from a venture's context filesystem.' It clearly distinguishes this tool from delimit_context_list by noting that list returns names only while this returns a single artifact's content, so an agent can differentiate it from close 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?

The description explicitly provides 'When to use' and 'When NOT to use' guidance, naming delimit_context_list and delimit_memory_search as alternatives. This gives an agent clear routing logic without requiring it to infer intent from tool names.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context by disclosing that the tool 'writes a snapshot record under the venture namespace via ai.context_fs' and that the snapshot is 'immutable.' This goes beyond the structured annotations without contradicting them.

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 labeled sections: when to use, when not to use, sibling contrast, and side effects. Every section adds distinct value and the opening line is front-loaded with the core purpose. 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?

The description covers purpose, usage context, exclusions, alternatives, side effects, and storage behavior. An output schema is present, so return-value documentation is not needed. For a tool with this complexity, the description is complete and actionable.

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

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

Schema description coverage is 100%, so the schema already documents both parameters adequately. The description does not add parameter-specific details beyond schema, but given full coverage, no extra compensation is needed. This meets the baseline for schema-heavy parameter documentation.

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

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

The description opens with a specific verb-resource pair: 'Capture a point-in-time snapshot of a venture's context.' It also differentiates itself from sibling tools by explicitly contrasting with delimit_context_branch, which creates a divergent line of work. This makes the tool's purpose immediately clear and distinguishable.

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

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

The description gives explicit 'When to use' guidance (before a risky model handoff, doctrine edit, or refactor) and explicit 'When NOT to use' guidance with named alternatives (delimit_context_write, delimit_memory_store). It also adds a sibling contrast with delimit_context_branch. This is exemplary routing information.

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 annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds meaningful behavioral context by disclosing the side effect: the artifact is written under the venture namespace via ai.context_fs, with file creation under ~/.delimit/context/<venture>/. It does not address overwrite behavior on an existing artifact name, but it provides solid transparency beyond the 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?

The description is well-structured with clear sections: primary purpose, when to use, when not to use, sibling contrast, and side effects. It is front-loaded and every sentence earns its place without redundancy.

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

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

For a tool with 4 well-documented parameters and an output schema, the description covers selection criteria, exclusions, sibling differentiation, and side effects. Nothing essential is missing for an agent to decide when to invoke it and what to expect.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds usage context like persisting plans, decision records, or code artifacts, but it does not add significant parameter-level meaning beyond the schema. 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 opens with a specific verb and resource: 'Write an artifact to a venture's context filesystem (STR-048).' It distinguishes itself from the closest siblings by stating that delimit_context_read fetches one artifact, delimit_context_list inventories the venture, and this one writes one. The scope and intent are 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 'When to use' and 'When NOT to use' guidance, naming delimit_memory_store for ephemeral context and delimit_context_snapshot for snapshotting all artifacts. It also adds a sibling contrast for read and list, making the selection criteria clear.

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

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

Beyond annotations, the description clearly discloses that list/get are READ-ONLY, approve/reject append to the existing ~/.delimit/inbox_routing.jsonl store, reject stamps disposition="rejected", no new store is created, and idempotent re-approve no-ops. This aligns with and enriches the idempotentHint and destructiveHint 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?

The description is structured into clear labelled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence adds information, and the core purpose is front-loaded in the first sentence.

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 multi-action tool with mixed read/write behavior, the description covers the shared-queue scope, action restrictions, side effects, sibling differentiation, and idempotency. An output schema exists, so return-value documentation is already handled; nothing essential is missing for an agent to invoke this tool correctly.

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

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

Schema coverage is 100%, so the schema already documents all six parameters. The description adds operational meaning by clarifying which actions apply to which item classes, listing example item id forms (att_…, STR-437, LED-1709, WO-…, DIR-…), and reinforcing that approve/reject only act on approval-class items.

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

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

The description opens with a specific verb-resource pair: 'Aggregate all governance lanes into one queue' and 'approve/reject approvals (LED-1709).' It also names the exact item classes (attestations, approvals, sensing STR-*, ops LED-*) and contrasts against four sibling tools, so an agent can distinguish it without ambiguity.

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' guidance, including the Phase 1 restriction that approve/reject are approval-class only. It also gives sibling contrast naming delimit_agent_dashboard, delimit_ledger_context, and delimit_notify_inbox, telling the agent exactly when this tool is the right choice versus 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?

Annotations already mark it read-only and idempotent, and the description reinforces this with 'read-only across all subsystems.' It adds valuable behavior beyond annotations: failure isolation per sub-section, gateway-only availability, and the npm-bundle fallback response shape. This is exactly the kind of contextual behavior an agent needs.

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 organized into clear labeled sections with no wasted sentences. Each section adds value: use cases, alternatives, side effects, return behavior, and deployment constraints. It is longer than average, but every sentence earns its place.

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

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

Covers the complete decision surface: what the tool returns, when to use it, when not to use it, how it behaves on partial failure, where it is available, and what happens on unsupported installs. An agent has everything needed to correctly select and invoke this tool.

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

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

The tool has zero parameters, the schema already reflects that, and the description explicitly states 'Args: None.' There is no parameter semantic burden to carry, so a baseline of 4 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 opens with a clear, specific purpose: 'One-call corp status' and a full list of included subsystems. It explicitly differentiates itself from finer-grained single-subsystem tools and names sibling rollups, so an agent can immediately tell what this tool is and is not.

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?

Contains explicit 'When to use' and 'When NOT to use' sections, including named alternatives such as delimit_daemon_status and delimit_obs_status. This gives an agent direct, actionable routing guidance with no ambiguity.

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 clearly discloses that create/delete/toggle actions write to a file-based alert store while list is read-only, which adds meaningful behavioral detail beyond the write/destructive annotations. It also states the Pro license prerequisite and the unlicensed error response, giving the agent an accurate expectation of side effects and failures.

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, front-loaded purpose, and no filler. Each section earns its place: usage guidance, sibling contrast, side effects, and prerequisite are all present without unnecessary elaboration.

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

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

The description covers the key contextual aspects: what the tool does, when to use it, how it differs from siblings, side effects, and licensing requirements. An output schema exists, so the description does not need to explain return values, and nothing essential is missing 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?

The input schema already provides 100% description coverage for all four parameters, including which are required for which action, so the description does not need to repeat those details. The description adds useful action-level context (list/create/delete/toggle and their side effects) but no deeper per-parameter semantics 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 states a specific verb ('Manage') and a precise resource ('cost alert rules'), explicitly covering CRUD on spending thresholds. It distinguishes itself from the sibling tools delimit_cost_analyze and delimit_cost_optimize by defining what it does versus what they do.

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

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

The description gives explicit 'When to use' and 'When NOT to use' guidance, naming the correct alternatives for one-shot cost analysis and optimization. The sibling contrast section further clarifies the decision boundary, leaving no ambiguity about when this tool is the right 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?

Beyond the readOnly/idempotent/destructive annotations, the description states the target is scanned read-only, that the tool is gated by require_premium, that it calls a specific backend function, and that an unlicensed call returns an upgrade payload without executing. This gives the agent a clear model of side effects and failure 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?

The description is more verbose than minimal but remains well structured with labeled sections and a front-loaded summary. There is minor redundancy between 'Gated by require_premium' and the later 'Prerequisite' sentence, so it is not perfectly concise.

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 one-parameter, read-only analysis tool with an output schema, the description covers purpose, usage boundaries, prerequisites, side effects, and unlicensed behavior. Nothing essential for calling it correctly is missing.

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

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

With 100% schema description coverage, the schema already documents target and its default. The description adds some context about what the scan looks for (Dockerfile, dependency manifests, cloud configs), but it does not introduce substantial new parameter semantics 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 opens with a specific verb and resource: 'Analyze a project for cost drivers (Dockerfile, deps, cloud)'. It later contrasts with delimit_cost_optimize and delimit_cost_alert, making it easy to distinguish this tool from the most relevant 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?

The 'When to use' section gives a concrete investigation scenario, and 'When NOT to use' explicitly routes to delimit_cost_optimize and delimit_cost_alert. This is unambiguous selection 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?

The description clearly discloses side effects ('action="set" / "reset" mutate the rate-limiter state'), which is excellent transparency in isolation. However, this directly contradicts the annotation readOnlyHint=true, which claims the tool makes no modifications. This is the same pattern as the create_record calibration example: a description claiming write operations while annotations declare read-only. The conflicting signals leave the agent unsure whether invoking this tool is safe.

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 (When to use, When NOT to use, Sibling contrast, Side effects) that make it easily scannable. Every sentence earns its place, and the most decision-relevant information is front-loaded. The format is exemplary for an agent-facing definition.

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

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

The description covers purpose, usage boundaries, sibling differentiation, and per-action side effects. An output schema exists, so return values don't need describing. Minor gaps: it doesn't distinguish what 'status' vs 'quota' actions each return, and the annotation contradiction undermines the otherwise complete safety picture. Still, nearly everything needed to call it correctly is present.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's phrases ('per-tool hourly rate limits', 'session cost cap') reinforce the mapping to limit/cost_cap, and the side-effects section adds action-level semantics (which actions mutate vs read). But this largely restates what the schema already documents rather than adding meaningful new 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?

The opening line 'Manage MCP rate limits and session cost controls' uses a specific verb and resource, and the scope is unmistakable. It also distinguishes itself from siblings by explaining that delimit_cost_analyze inspects project spend while this manages per-session call quotas. An agent can clearly tell what this tool is for.

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

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

The description explicitly states 'When to use', 'When NOT to use', and names the alternative tools (delimit_cost_analyze for project-cost analysis, delimit_cost_alert for alert configuration). The sibling contrast section further reinforces the decision boundary. No inference is required to choose correctly between this and related 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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description reinforces this in operational terms ('Side effects: read-only on the target'). It adds genuinely new behavioral context beyond annotations: the premium gating ('Gated by require_premium'), the exact unlicensed failure mode with the upgrade URL, that the call fails without running, and the internal backend routing ('Calls backends.tools_data.cost_optimize').

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?

Organized into labeled, scannable sections (When to use / When NOT to use / Sibling contrast / Side effects / Prerequisite) with the core purpose front-loaded. Every line carries distinct information; there is no filler or restatement of the title.

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 for a single-optional-parameter tool: purpose, use cases, exclusions, sibling differentiation, safety profile, licensing prerequisite, failure behavior, and backend identity are all covered. Return values are handled by the output schema, so no gap remains for an agent to invoke this correctly.

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

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

Schema description coverage is 100%, so the schema fully documents the single 'target' parameter (path, default '.'). The description adds no parameter-level detail beyond the schema's own description, so the 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?

Opens with a specific verb+resource: 'Find cost optimization opportunities in a project (Pro).' The sibling contrast line ('delimit_cost_analyze identifies sources of cost; this proposes reductions') explicitly differentiates it from the nearest sibling, so an agent can distinguish it without opening schemas.

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

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

Provides explicit when-to-use ('after delimit_cost_analyze surfaces drivers, to get concrete suggestions'), when-NOT-to-use ('to inventory current spend... or manage threshold alerts'), and names the alternatives (delimit_cost_analyze, delimit_cost_alert). The sequencing guidance ('after... surfaces drivers') is especially 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?

Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds further context by explicitly stating 'Side effects: read-only' and naming the internal functions it calls (ai.daemon.classify_item / get_next_automatable_item / get_open_ledger_items), which is valuable beyond the 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?

The description is tightly structured with clear sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence earns its place and key classification behavior is 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?

With annotations covering safety, an output schema present, and a single fully-documented parameter, the description covers all essential guidance. The agent has enough information to select, invoke, and interpret this tool correctly.

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

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

Schema description coverage is 100%, and the schema fully documents item_id including the empty-string behavior. The description reinforces this by mentioning 'next automatable one' but does not add meaning beyond what the schema already provides. 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 opens with a specific action and resource: 'Classify a ledger item's risk tier and suggested automation tool.' It also distinguishes itself from daemon_run and daemon_status, so an agent can tell exactly what this tool does relative to its closest 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?

The description provides explicit when-to-use and when-not-to-use guidance, naming delimit_daemon_run for executing and delimit_daemon_status for health checks. Sibling contrast is also stated clearly, leaving no ambiguity about 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?

Beyond the annotations, the description discloses the dry_run vs live mode side effects, that it calls ai.daemon.run_loop, and the 5-second interval between iterations. This gives the agent a clear picture of what executing the tool actually does.

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 labeled sections, front-loads the core behavior, and avoids filler. Every sentence contributes either usage guidance, sibling differentiation, or behavioral transparency.

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

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

The tool carries a safety-relevant readOnlyHint=false and destructiveHint=false, and the description explains the side-effectful behavior in both modes. An output schema exists so return-value documentation is not required here. The description is sufficient 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 description coverage is 100%, so both parameters are already fully documented in the schema. The description adds narrative context around dry_run and iterations but does not meaningfully extend the parameter semantics beyond what the schema 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?

The description opens with a specific verb and resource: 'Advance the autonomous daemon by N iterations.' It also explicitly contrasts itself with delimit_daemon_status and delimit_daemon_classify, so an agent can distinguish it from closely related 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?

It has a dedicated 'When to use' section with concrete examples like testing and cron-style execution, plus a 'When NOT to use' section naming delimit_daemon_status and delimit_daemon_classify as alternatives. The sibling contrast further clarifies the decision boundary.

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?

Even though annotations already declare readOnlyHint and idempotentHint, the description adds meaningful behavioral detail: it states 'Side effects: read-only', explicitly reveals the underlying backend call ai.daemon.get_daemon_status, and clarifies that it reads runtime state. These details go beyond what annotations alone provide and leave no hidden 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 tightly structured with clear, scannable sections: purpose, when to use, when not to use, sibling contrast, side effects, args, and returns. Every sentence adds information, and the most critical usage guidance is 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?

For a zero-parameter, read-only status tool with annotations covering safety and an output schema available, the description is fully adequate. It even enumerates the returned fields (loop counts, items processed, recent actions, next_steps), giving the agent a complete mental model with no missing 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?

The tool takes zero parameters and the input schema confirms this, so there is no parameter semantics burden. The description additionally states 'Args: None', removing any ambiguity for the agent.

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

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

The description begins with a specific verb and resource: 'Report the autonomous daemon's status', and lists the exact observed dimensions (loops, items, actions). It also explicitly differentiates itself from siblings like delimit_daemon_run, which advances iterations, making the tool's purpose unmistakable.

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

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

The description provides a dedicated 'When to use' section, a 'When NOT to use' section with named alternative tools, and a sibling contrast note. This is exemplary routing guidance: an agent knows exactly when to call this tool and when to call delimit_daemon_run or delimit_daemon_classify instead.

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 beyond the annotations: writes timestamped copies to a specific location, captures a restore point, and does not claim to modify original files. The annotations destructiveHint=false and readOnlyHint=false are consistent with this behavior; no contradiction.

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 and front-loaded: purpose, when to use, when not to use, sibling contrast, and side effects are each given their own concise labeled section. Every sentence carries useful routing or safety information with no filler.

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

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

For a simple one-parameter tool with an output schema and safety annotations, the description covers purpose, trigger conditions, exclusions, alternatives, side effects, and destination. Nothing an agent needs to decide whether to call it or to call it safely is missing.

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

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

Schema description coverage is 100% and the schema already documents target as the directory or file to back up and the default '.'. The description adds domain context about backing up SQLite and JSON data, but it does not materially expand parameter-level semantics 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?

Opens with a specific verb and resource: 'Back up SQLite and JSON data files to ~/.delimit/backups/.' It also explicitly contrasts itself with delimit_data_validate and delimit_data_migrate, so an agent can distinguish it from the most similar 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 guidance ('before a risky migration or refactor'), when-not-to-use guidance ('to validate data integrity... apply migrations'), and names the exact alternatives. This leaves no ambiguity about tool 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?

Annotations already mark this as read-only and non-destructive, and the description reinforces this with 'read-only inspection' and 'this tool only inspects status.' It adds useful behavioral context that the tool does not apply migrations and names the backend call, going slightly beyond the 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?

The description is organized into clear, front-loaded sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence earns its place; the backend call detail is minor but does not bloat the description.

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

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

For a simple read-only tool with one optional parameter, an output schema, and strong annotations, the description is complete. It covers use cases, exclusions, safety profile, and scope without needing to explain return values since an output schema exists.

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

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

Schema coverage is 100%, so the single optional 'target' parameter is fully documented in the input schema. The description adds no additional parameter-level detail, but none is needed given the schema already explains the default and purpose.

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

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

The description opens with a specific verb and resource: 'Inspect migration files (alembic / Django / Prisma / Knex) for status.' It clearly distinguishes itself from siblings by naming delimit_data_validate and delimit_data_backup and stating what this tool does not do.

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

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

The description explicitly states when to use the tool ('to audit pending and applied migrations before a deploy, or as a CI gate') and when not to use it ('to actually apply migrations... or back up data first'). It also provides sibling contrast, leaving no ambiguity about which tool to select.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by specifying the validation dimensions (JSON parse, CSV shape, SQLite integrity), stating the side effect is read-only, and noting it calls backends.tools_data.data_validate. It does not detail failure handling or output behavior, but output schema and annotations reduce that burden.

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

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

The description is compact, well-organized, and front-loaded with the primary purpose. Every section earns its place: what it validates, when to use it, when not to use it, sibling contrast, and side effects. No filler or redundant elaboration.

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

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

For a simple read-only validation tool with one optional parameter, an output schema, and full annotation coverage, the description is complete. It gives the agent sufficient context to decide when to call it, what it checks, and which siblings to use instead.

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

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

Schema description coverage is 100% and the only parameter, target, is already documented as a directory or file path with data files and a default of '.'. The description does not add significant new meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Validate data files: JSON parse, CSV shape, SQLite integrity.' It clearly states what the tool operates on and what checks it performs, and it distinguishes itself from sibling delimit_data_migrate by noting that this tool exercises the data files themselves rather than migration files.

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' (smoke checks before relying on data files, CI pipelines, before migrations), 'When NOT to use' (migration status, backups), and names the alternative tools delimit_data_migrate and delimit_data_backup. It also adds a sibling contrast sentence, so an agent knows exactly when this tool is appropriate versus its siblings.

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

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

Annotations only provide readOnlyHint=false and destructiveHint=false, so the description carries most of the behavioral burden. It discloses side effects (transcript writes under save_path), external model calls through configured providers, tier-dependent model availability, and special constraints for strategic/social scopes including a 3-model minimum and possible Grok tiebreaker. This goes well beyond the bare 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?

The description is well-structured with clear headers for use cases, exclusions, sibling contrast, and side effects. It front-loads the core purpose and every sentence contributes distinct decision-relevant information, making the length justified rather than padded.

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, the description plus full input schema and output schema provide everything an agent needs: required parameter, supported modes, scope behavior, provider configuration, side effects, and when to avoid this tool. No critical information is missing.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters. The description adds no new parameter-level syntax or format details beyond what the schema provides, and therefore remains at the baseline 3 rather than needing to compensate.

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

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

The description opens with a specific verb phrase, 'Run multi-model consensus via AI-to-AI deliberation,' and names the exact resource. It explicitly differentiates from delimit_models and delimit_security_deliberate, so an agent can distinguish this tool from its siblings without opening their schemas.

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

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

The description provides an explicit 'When to use' list with concrete decision types such as pricing, naming, copy framing, doctrine edits, and external PR diffs. It also gives a clear 'When NOT to use' exclusion for routine implementation choices and names alternatives like in-thread orchestration or subagent dispatch.

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?

Annotations already declare readOnly, idempotent, and non-destructive; the description adds that it reads ~/.delimit state, exposes OAuth signed-in status, retains legacy fields, and notes the LED-2092 account requirement. No contradiction with 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?

Purpose is front-loaded in the first sentence, with clearly labeled When/When-not/Sibling contrast/Side effects/Returns sections. Although detailed, every section adds actionable context rather than filler.

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

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

For a zero-parameter, read-only status check with an output schema, the description covers invocation timing, return fields, legacy compatibility, and backend state. Nothing an agent needs to select and call it correctly is missing.

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

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

There are zero parameters, so there is little to explain; the description explicitly states 'Args: None' and the schema confirms empty properties. This is the appropriate baseline for a no-parameter tool.

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

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

Opens with 'Check deliberation usage and mode', a specific verb plus resource, and explicitly contrasts itself with delimit_deliberate and delimit_models. An agent can distinguish this from all siblings without inspecting schemas.

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

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

Provides explicit 'When to use' guidance (before delimit_deliberate to confirm quota/BYOK/OAuth state) and 'When NOT to use' with named alternatives. This is strong routing guidance that leaves no ambiguity about invocation 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?

The description goes well beyond the annotations. It discloses the premium gating behavior ('require_premium — unlicensed callers receive a license payload and no build runs'), the internal backend invocation, the local resource consumption (disk and CPU), that no network push happens at this step, and that the response is routed through _with_next_steps. This is rich behavioral context that annotations do not provide.

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 detailed but relevant, with clear section headers and front-loaded purpose. The 'Sibling contrast' section is somewhat redundant with the 'When NOT to use' section, repeating similar routing guidance. Still, it earns a 4 because every section serves a clear decision-making purpose and the organization is effective.

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

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

Given the tool has an output schema, a complete set of 3 parameters, and rich context about the deploy chain, prerequisites, side effects, and alternatives, nothing critical is missing. The description covers licensing gate, resource impact, chain position, and routing behavior. An agent has enough to decide when and how to invoke it correctly.

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

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

Schema description coverage is 100%, so each parameter (app, git_ref, repo_path) is already documented in the schema. The description adds context around the git_ref default ('Default None = backend HEAD') but mostly relies on the schema. A baseline of 3 is appropriate since the schema covers parameter meaning adequately.

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

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

The description states a specific verb+resource ('Build container images for an app at a specific git ref') and distinguishes itself from siblings by naming the deploy chain step. It clearly identifies this as the build step producing local SHA-tagged images, not the plan or publish step.

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', 'When NOT to use', and a full chain (plan -> build -> publish -> verify -> rollback). It names the alternative tools (delimit_deploy_publish, delimit_deploy_site, delimit_deploy_npm) and explains when they are appropriate instead. The sibling contrast section reinforces the routing decision clearly.

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

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

The description richly discloses behavior far beyond the readOnlyHint=false/destructiveHint=true annotations: all actions are gated by require_premium, unrecognized actions return a deterministic error before any gate/backend call, plan is fail-closed, build writes locally, publish is a network write, rollback mutates the environment, status is read-only, and npm includes a non-undoable public publish. This is exemplary behavioral disclosure.

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

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

The description is long but every section earns its place: when to use, when not to use, sibling contrast, side effects, and per-action breakdown. It is front-loaded with the core purpose and uses structured bullets for the eight actions, making a complex dispatch surface navigable rather than bloated.

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 high complexity (16 params, 8 actions, multiple side-effect profiles), the description is complete: it covers action selection, per-action gates, side effects, error behavior, parameter relevance, and even continuation behavior on Vercel timeout. The output schema is present, so return-value details do not need to be re-explained.

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 69%, so the description carries meaningful weight. It adds semantics beyond the schema: dry_run suppresses only the final publish while bump and pack still run, repo_path is required for every deploy action, site defaults to pre-staged changes with explicit paths as the only staging mechanism, and Vercel timeout yields pending continuation identifiers. A few parameters (venture, target_urls) get no extra explanation, but the schema covers the main ones.

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

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

The description opens with a specific verb and resource: 'Unified deployment entry point — dispatches to one of eight actions (Pro).' It clearly names the exact operations covered and explicitly contrasts itself with the thin aliases delimit_deploy_plan/build/publish/etc., making the dispatch-core role 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 has explicit 'When to use' and 'When NOT to use' sections. It names the preferred aliases for action-specific behavior, and routes health checks to delimit_obs_status, smoke tests to delimit_test_smoke, and release metadata to delimit_release_status. No inference is needed.

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?

Beyond readOnlyHint=false, the description discloses step-by-step side effects: local package.json bump, prepublishOnly hook execution (including a known regression), npm pack, and npm publish as a publicly visible network write that is not undoable. It also covers dry_run's exact scope (suppresses step 4 only) and the unlicensed-caller behavior, giving the agent a precise model of consequences. This does not contradict destructiveHint=false because publishing is not deleting data, but it correctly labels the side effect as irreversible.

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

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

The description is long but every paragraph earns its place: purpose, routing guidance, sibling contrast, side effects, and prerequisites are each one dense block with no filler. It front-loads the core action and immediately follows with deployment-safety context.

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

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

For a production deploy tool, the description fully covers what will happen, what won't happen in dry run, what must precede it, who can call it, and which sibling tools handle other cases. The output schema exists, so return-value documentation is not the description's job; nothing needed for correct invocation is missing.

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

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

Input schema already covers all five parameters (100%), so baseline is 3; the description earns extra by adding one important behavioral nuance: dry_run=True still performs the version bump and pack, not just a no-op, so the chain can be exercised. It also clarifies that this is a Pro-gated operation, which indirectly prepares the agent for a license-related response. No per-parameter details beyond what the schema already provides are added, so 4 rather than 5.

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

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

The description opens with a precise action and resource: 'Publish an npm package: version bump, pack, and push to registry (Pro).' It distinguishes itself from delimit_deploy_site and delimit_deploy_publish by naming exactly what it ships (npm tarballs) versus sites or container images, so an agent can disambiguate immediately.

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 'When to use' and 'When NOT to use' sections are explicit, naming the correct alternative for each excluded case (delimit_deploy_site, delimit_deploy_publish, local npm pack --dry-run) and even pointing to dry_run=True for testing the chain without publishing. It also states the required preceding chain and founder approval, leaving no ambiguity about when invoking it is appropriate.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses side effects in detail: it auto-chains delimit_security_audit and delimit_gov_evaluate before the underlying deploy_plan handler, halts on critical findings, and returns status="blocked" without producing a plan. This is substantial behavioral context that the annotations do not provide.

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 organized into clear labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every section adds distinct value, and the key purpose is front-loaded before any secondary details.

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

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

The description covers the tool's role in the deploy chain, exclusions, side effects, and failure behavior. An output schema exists, so return-value documentation is not required here. The only minor gap is that it doesn't explain what happens if the tool is invoked without Pro access or how auth is handled, but this is not essential for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description does not add parameter-level meaning, but it doesn't need to because the schema handles it. This matches the baseline for high schema coverage.

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

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

The description opens with a specific verb and resource: 'Generate a deploy plan with security preflight.' It clearly distinguishes itself from delimit_deploy_build and delimit_deploy_publish by framing itself as the planning gate, so an agent can immediately tell what this tool does relative to its 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?

The description gives explicit 'When to use' and 'When NOT to use' guidance, names the exact alternative tools, and explains the positioning in the deploy chain. This removes ambiguity about when the agent should select this tool versus the build or publish steps.

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 annotations only set readOnlyHint=false and destructiveHint=false, so the description carries the transparency burden. It discloses that publish is gated by require_premium, calls backends.deploy_bridge.publish, performs network writes to the registry, and returns a specific unlicensed response without running. This is valuable behavioral context an agent cannot infer from annotations alone.

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 organized into labeled, scannable sections and front-loads the core action before caveats. Every section serves a purpose: what it does, when to use it, when not to, side effects, and prerequisite. Minor redundancy around the Pro requirement is acceptable and does not reduce clarity.

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

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

For a mutating publish operation with an output schema, the description covers the essential context: position in the deploy flow, side effects, licensing failure mode, and sibling roles. Parameters are fully covered by the input schema and return values by the output schema. No material gap remains for correct invocation.

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

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

Input schema coverage is 100%, with descriptive comments for app, git_ref, and repo_path. The description does not add parameter-specific detail beyond what the schema already provides. A baseline of 3 is appropriate when the schema fully documents the parameters.

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

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

The opening sentence uses a specific action and resource: 'Publish previously built images to the registry (Pro)'. It distinguishes this tool from siblings by naming delimit_deploy_build as the local-image producer and delimit_deploy_verify as the rollout-health checker. This goes well beyond restating the title.

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 has explicit 'When to use' and 'When NOT to use' guidance, directing the agent to use this after delimit_deploy_build has produced local images. It names the alternatives for building and starting the deploy chain, and contrasts with delimit_deploy_verify. Tool selection is unambiguous.

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?

Annotations already flag destructiveHint=true, but the description adds substantial behavioral detail: the call is gated by require_premium, invokes backends.deploy_bridge.rollback, mutates the running environment, and returns a specific error payload with an upgrade URL when unlicensed. This goes well beyond the annotation hints and clearly sets expectations for side effects and failure 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?

The description is well structured with clear labeled sections: purpose, when to use, when not to use, sibling contrast, side effects, and prerequisite. Every sentence adds necessary information, and the most important scoping details are 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?

Given the tool's complexity and the presence of both input and output schemas, the description covers all essential operational guidance: trigger condition, exclusion criteria, reversal-only behavior, side effects, licensing prerequisite, and failure mode. No critical information needed to invoke it correctly is missing.

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

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

Schema description coverage is 100%, and each parameter already has its own description. The tool description adds only minimal extra insight by referencing 'prior to_sha,' while the schema already explains that null selects the previous deployed SHA. The schema carries the semantic weight, 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 opens with a clear verb and resource: 'Roll back an environment to a previous SHA.' It also distinguishes the tool from delimit_deploy_publish by stating that publish moves forward while this moves backward, so an agent can identify the correct tool without ambiguity.

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 define the exact scenario (delimit_deploy_verify shows a regression) and explicitly rule out forward deploys. It also names the sibling tool and the condition that selects it, leaving no inference required.

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