delimit

Official

by delimit-ai

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v4.13.2
Disambiguation2/5
With 209 tools, there is substantial overlap between similar tools like the many ledger, governance, and deploy variants. The detailed descriptions help, but the boundaries are often subtle, and internal implementation tools (prefixed with underscore) add confusion. An agent would frequently misselect.
Naming Consistency3/5
The naming mostly follows a consistent verb_noun snake_case pattern (e.g., delimit_agent_dispatch, delimit_ledger_add). However, there are irregularities like delimit_ledger_done instead of delimit_ledger_complete, and internal tools with underscore prefixes break the pattern.
Tool Count1/5
209 tools is far beyond the typical well-scoped range of 3-15. The server attempts to cover an enormous breadth of functionality (governance, deploy, social, design, etc.), making it monolithic and unfocused. This extreme count severely hurts usability.
Completeness3/5
Given the server's vast scope, it covers many operations (CRUD for ledger, deploy pipeline, governance lifecycle, social posting, etc.). However, many tools are marked experimental or gated behind Pro, and some workflows require chaining multiple tools, indicating room for improvement.
Average 4.6/5 across 170 of 209 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 80 commits in the last 12 weeks
- Last stable release on September 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is behaviorally rich, stating read-only behavior, no write/probe/notification, Pro licensing gating, and the internal backend call. However, the annotations declare readOnlyHint=false, which directly contradicts the description's explicit read-only claim. Per the rubric, a description that contradicts annotations receives a score of 1, and this is an annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, with clear sections for purpose, usage, non-usage, sibling contrast, side effects, and prerequisites. It is longer than minimal, but most content earns its place. Minor redundancy exists: Pro licensing is mentioned both as a gating side effect and as a prerequisite, and the registry-inspection contrast is somewhat peripheral.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers use cases, exclusions, licensing prerequisites, side effects, internal behavior, and response routing, while the output schema accounts for return values. It is nearly complete, but the conflicting readOnlyHint annotation leaves the safety profile unreliable, and the optional parameter behavior (especially repo_path) is not elaborated beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters. The tool description does not add parameter-level detail beyond the schema, but it does not need to compensate for a coverage gap. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read the current rollout metadata for an app/env.' It then concretely lists what is inspected (deployed SHA, rollout state, in-progress deploy) and contrasts with delimit_deploy_verify and delimit_release_status, making sibling differentiation explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 equally explicit 'When NOT to use' section, naming exact sibling alternatives such as delimit_deploy_verify, delimit_obs_metrics, delimit_obs_status, delimit_deploy_plan, and delimit_release_status. An agent can determine routing without inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses useful behavior such as Figma API auto-activation, secret lookup paths, backend calls, and token_types coercion. However, it states the operation is a 'read-only scan,' while the annotation readOnlyHint is false. Because readOnlyHint=false signals that the tool may modify state, this is an annotation contradiction, so the score is 1 per the rubric.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized: purpose, usage guidance, sibling contrast, then side effects. Some internal identifiers like backends.ui_bridge.design_extract_tokens add noise, but the structure is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, when to use it, when not to, sibling contrast, side effects, and Figma credential discovery. With an output schema present, return values need no explanation; the only completeness concern is the safety contradiction noted above.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% and each parameter already has a description, default, and token_types values. The description's mention of _coerce_list_arg adds a minor implementation detail but does not materially improve parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Extract design tokens from a project's CSS/SCSS/Tailwind config.' It also names sibling tools it is not, so an agent can distinguish it from delimit_design_generate_tailwind and delimit_design_generate_component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides 'When to use,' 'When NOT to use,' and names the alternative tools for the excluded cases. This is exactly the routing guidance an agent needs and leaves no ambiguity about when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The prose is rich, disclosing gating, per-action backend routing, deterministic errors, and _with_next_steps wrapping. However, it directly contradicts the readOnlyHint:true annotation by explicitly stating that only action='health' and action='status' are read-only, implying the other actions are not. Per the rubric, a description that contradicts annotations must receive a score of 1 and be flagged as an annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear headings for usage, non-usage, sibling contrast, and side effects. It is front-loaded with the core purpose and each section carries meaningful information for a seven-action dispatcher. Minor redundancy exists between the sibling contrast section and the when-to-use/when-not-to-use paragraphs, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with seven actions, eight parameters, and nontrivial routing, the description covers selection criteria, exclusions, per-action side effects, license gating, error behavior, and coercion short-circuiting. An output schema exists, so return-value detail is not required. The only completeness gap is the incoherence introduced by the readOnlyHint annotation contradicting the description's explicit read-only scoping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter already documented for requiredness, defaults, and action-specific usage. The description adds general action dispatch and gating behavior, but those are behavioral, not parameter-semantic, details. Coercion of context and rejection of empty eval_action are already present in the schema descriptions, so the description adds little beyond the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a unified governance entry point that dispatches to one of seven actions by name. It explicitly contrasts with the delimit_gov_* alias siblings, explaining that this is the implementation core while the aliases are thin wrappers. The verb and resource are specific, and the purpose is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contains an explicit 'When to use' and 'When NOT to use' section. It names the exact condition for selecting this tool (picking action by name in one call) and directs internal code paths to prefer specific aliases like delimit_gov_health or delimit_gov_evaluate. Sibling contrast is also provided, making routing unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides rich behavioral context: licensing gate, unlicensed payload, no write/probe/notification, and internal invocation. However, it states 'read-only against the ops backend' while the annotations declare readOnlyHint=false, directly conflicting with the annotation; per rubric this is a 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and organized into scannable sections, and most content earns its place for a tool with many siblings. It is slightly long and includes some implementation detail like '_with_next_steps' that an agent does not need for selection, so 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter, an output schema, and comprehensive sibling/alternative/exclusion guidance, the description covers everything needed to invoke the tool correctly. The contradictory readOnlyHint=false annotation versus the 'read-only' claim leaves the agent with conflicting safety signals, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter, environment, is described with a default in the schema. The description reinforces environment-level scope but adds no new syntax, constraints, or format details beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: 'Report the active release version for a whole environment (Pro).' It clarifies the release-tier vs deploy-tier distinction and names the sibling tools it is not, so an agent can differentiate it from delimit_deploy_status and delimit_release_history 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.
Usage Guidelines5/5
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 delimit_deploy_status, delimit_release_history, and delimit_release_plan as alternatives with the conditions that select them, and adds a sibling contrast paragraph.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that actions like 'register', 'clear', and 'flush' mutate the cache, and that only 'status', 'delta', and 'estimate' are read-only. This directly contradicts the annotation readOnlyHint=true, which declares the entire tool read-only. The 'clear'/'flush' actions also sit awkwardly with destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded one-sentence purpose, followed by compact labeled sections for when to use, when not to use, sibling contrast, and side effects. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main usage context, exclusions, sibling distinction, and side effects, and the output schema plus full parameter coverage reduce the need for return-value details. However, the direct contradiction between the stated mutating side effects and the readOnlyHint=true annotation leaves an agent unable to trust the tool's safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters and their purposes. The description adds some value by labeling which actions are mutating vs read-only and clarifying the cache side-channel nature, but it does not add significant new parameter-level semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Manage'), a concrete resource ('tool-schema cache'), and a clear objective ('reduce per-session token waste'). It also distinguishes itself from delimit_help, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, including a concrete use case (repeated dumps, sending diffs) and a clear exclusion (runtime tool dispatcher). It also names the sibling alternative delimit_help for contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly claims 'read-only network call' and 'No writes', but the annotations set readOnlyHint to false, which implies the tool is not marked read-only. This is a direct annotation contradiction, and the description's 'No writes' also conflicts with its own mention of an SQLite cache that presumably writes to disk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured with clear sections and the most important information is front-loaded. It is slightly verbose due to ticket references and repeated sibling contrast, but every section earns its place and the format is easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, when to use, alternatives, side effects, caching, and budget behavior, and an output schema is present. It is complete enough for an agent to invoke correctly, though the read-only contradiction with annotations prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters have detailed descriptions including mutual exclusivity and normalization behavior. The tool description adds no parameter-level detail beyond restating 'by id or URL', so the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Fetch tweets from X by id or URL') and explicitly names the integration. The sibling contrast further clarifies exactly what this tool is and is not, making it easy for an agent to distinguish from delimit_social_target and delimit_reddit_fetch_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 the exact alternative tools and the conditions that should route to them. This gives the agent clear decision criteria without needing to infer anything.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: the description states 'Side effects: read-only on the heartbeat directory. No network, no write, no ledger, no notification,' but the annotations declare readOnlyHint: false. This directly contradicts the structured metadata and creates conflicting signals about whether the tool may mutate state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: purpose, usage guidance, sibling contrast, side effects, classification semantics, and thresholds. It is front-loaded with a clear one-sentence summary and uses structured headings for scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no prose description. The description covers classifications, thresholds, override mechanism, local-only behavior, and alternatives. It would be fully complete were it not for the readOnlyHint contradiction, which introduces avoidable uncertainty about side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single optional parameter heartbeat_dir is already well documented with its default and environment variable fallback. The description adds useful context about heartbeat files and thresholds but does not need to compensate for schema gaps, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb, resource, and outcome: 'Walk the heartbeat directory and report which scheduled services are stale.' The sibling contrast explicitly distinguishes this tool from delimit_obs_status and delimit_gov_health, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, including concrete alternatives like delimit_obs_status and direct file reads for one-off liveness checks. This leaves 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states 'read-only analysis (does NOT auto-create ledger items)', but the annotations set readOnlyHint: false. An agent receives conflicting signals about whether invoking this tool can mutate state, which is exactly the kind of contradiction that undermines safe tool selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the purpose in one sentence, then uses labeled sections for usage, non-usage, sibling contrast, and side effects. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full parameter schema, an output schema, and clear side-effect disclosure, the description is nearly complete for an agent to invoke it correctly. It loses the top score only because the readOnlyHint: false annotation conflicts with the description's read-only claim, leaving the overall context inconsistent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so focus, venture, and max_items are already documented with defaults and semantics. The description does not add parameter-level meaning beyond suggesting 3-5 items, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and object: 'Propose new ledger items based on signals, completed work, and gaps.' It directly distinguishes this from delimit_ledger_add and delimit_ledger_list, so an agent can tell what the tool is for 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('end of a build loop or when the queue is empty'), when-not-to-use ('to add a known item' or 'list current items'), and names the correct sibling tools. This leaves 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims this is a 'read-only scan' and 'Does not write to project files,' but the annotations declare readOnlyHint=false. This is a direct contradiction about a critical behavioral trait, so the score must be 1 despite the otherwise useful side-effect disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized with labeled sections, opens with the one-sentence purpose, and has no filler. Every sentence contributes either routing guidance or behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, the description covers what, when, when not, and side effects thoroughly. However, the conflict between the stated read-only behavior and readOnlyHint=false leaves a serious ambiguity about side effects, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single optional project_path parameter is already fully described with a default value and meaning. The description adds no parameter-specific detail, but none is required beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Scan a project'), a clear object (the project), and the output ('report what Delimit can do for it'). It also lists concrete discovery results (OpenAPI specs, security issues, frameworks) and distinguishes itself from delimit_init and delimit_quickstart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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_quickstart and delimit_init as alternatives. The sibling contrast section further reinforces the correct selection logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'Side effects: none. Pure read-only static analysis via ast (no import, no execution)' and explicitly says it does not write ledger/evidence/notify. However, the annotations declare readOnlyHint=false, which signals the tool is not read-only. This direct contradiction undermines the agent's trust in whether invoking the tool can mutate state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear 'When to use', 'When NOT to use', 'Sibling contrast', and 'Side effects' sections, and the main purpose is front-loaded. It is slightly longer than necessary — the ticket reference (LED-2108) and some repetition of the sibling distinction could be trimmed — but every substantive sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 an output schema, the description covers purpose, operational scope (file pattern), non-goals, side effects, and alternatives. No critical operational information for an agent selecting or invoking the tool is missing; the only issue is the annotation contradiction already scored.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds some context for target_file by mentioning it operates on Python files with @mcp.tool() decorators, but it does not explain the 'human' parameter beyond the schema. Baseline 3 is appropriate because the schema carries the parameter-documentation load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb-resource pair: 'Score MCP tool docstrings against the 6 TDQS dimensions.' It also names sibling tools it is not, noting it differs from delimit_lint (OpenAPI specs) and delimit_spec_health (spec quality scoring). An agent can clearly distinguish this from the many delimit_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'When to use' ('as a CI gate before publishing the MCP server') and 'When NOT to use' (runtime tool selection or policy decisions), and names alternatives for those cases (delimit_lint for OpenAPI specs, delimit_gov_evaluate for policy). This gives the agent unambiguous selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides unusually rich behavioral detail: read-only side effects, gating by require_premium, the backend call target, and the unlicensed error payload. However, it directly contradicts the annotations, which set readOnlyHint to false while the description claims the tool is read-only; per rubric this is a contradiction, so 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet sectioned: purpose, when/when-not, sibling contrast, side effects, and prerequisite. The implementation detail about backends.repo_bridge.evidence_verify is slightly superfluous but does not hurt. Front-loading is excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the input schema covers both parameters, the description supplies all selection and invocation context: use case, exclusions, preconditions, side effects, and failure mode. An agent can correctly decide when to call and what to expect from an unlicensed call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage), so the description does not need to add much. It adds the context that the bundle was previously collected, but the schema already covers the mutual exclusivity of bundle_id and bundle_path. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Verify the integrity of an evidence bundle (Pro).' It explains what verification means (attesting the bundle has not been tampered with) and distinguishes itself from delimit_evidence_collect in the sibling contrast. This is a clear, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use (replay or audit) and when NOT to use, naming both delimit_evidence_collect and delimit_ledger as alternatives. The sibling contrast reinforces the boundary, leaving 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'read-only' and 'No ledger write, no notification, no evidence file,' but the annotation readOnlyHint is false. This is a direct annotation contradiction, which per the rubric forces a score of 1 regardless of the otherwise rich 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but tightly organized with labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Each section adds distinct value, 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the session-start and CI use cases, fail-closed behavior, explicit sibling distinctions, implementation details, and side-effect profile. The output schema exists, so the description does not need to document return values, and nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, repo, is fully documented in the input schema with a type, default, and description. The tool description adds no parameter-specific detail, but with full schema coverage it does not need to, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource: 'Report whether the governance kernel and policy are reachable.' The sibling contrast explicitly distinguishes this from delimit_gov_status, which reports per-repo workload, so an agent can tell it apart from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context: session start orchestrator ritual and CI smoke check before a gated deploy. It also provides a when-NOT-to-use list with named alternatives (delimit_gov_evaluate, delimit_gov_policy, delimit_gov_status), which is exemplary routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description itself is exemplary — 'READ-ONLY', 'NO writes, env mutation, git config changes, network, ledger, or notification', fail-closed verdict semantics, and an explicit phase-1 not-wired-into-live-path disclosure. However, the annotations declare readOnlyHint=false, which directly contradicts the description's emphatic read-only/no-writes claims; per rubric, a description that contradicts its annotations scores 1. Annotation Contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but front-loaded: the first sentence states the purpose, and each paragraph carries distinct information — when/when-not, sibling contrast, phase limitation, side effects, and verdict semantics. No filler or repetition; the LED-1710 reference is the only minor noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool that already has an output schema and annotations, the description covers selection (when/not-to-use), invocation safety (read-only, hermetic git env), result interpretation (fail-closed, critical vs warn severities, per-check record shape), and operational limitations (phase-1 validator only). Nothing needed for correct selection or invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — project_path is fully documented as 'Repository path to inspect. Empty resolves via the gateway resolver, then cwd.' The description adds tool-behavior context (which state is inspected at that path) but no new parameter-level semantics, so the high-coverage baseline of 3 holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource pair: 'Validate cross-agent handoff invariants before switching coding agents.' It names the exact invariants checked (core.bare=true, git identity, GIT_* env leaks, index.lock, .last_capture) and explicitly differentiates itself from delimit_revive, delimit_soul_capture, delimit_repo_diagnose, and delimit_gov_health, so an agent can select it from ~200 siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('before a session hands off to a different coding agent... or an Auto-Phoenix revive'), when-not-to-use ('to capture or restore session context... or for general repo health'), and names the exact alternatives (delimit_soul_capture, delimit_revive, delimit_repo_diagnose). The sibling contrast adds exclusion criteria by noting delimit_revive is read+write while this is a narrow read-only gate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description asserts 'Side effects: read-only on the ledger,' but the annotations declare readOnlyHint: false, which signals the tool is NOT read-only. An agent receives conflicting cues — the structured hint implies possible mutation while the prose claims a read-only operation. The return-action disclosure (BUILD/CONSENSUS/STOP) is valuable, but the contradiction with the annotation forces a score of 1 per the rubric.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded one-sentence purpose, then tightly organized When/When NOT/Sibling/Side-effects sections. Every sentence earns its place for an agent choosing among roughly 200 sibling tools; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations already exist, the description covers everything an agent needs to decide whether to call it: purpose, usage boundaries, sibling contrast, side-effect scope, and the three possible return actions with their meanings. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three parameters are already documented (venture auto-detect, max_risk levels, session_id resume/new). The description only loosely ties max_risk to the 'safeguard checks' concept and adds no per-parameter meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Get the next task to work on' — and narrows it to the highest-priority open task in a loop session with safeguard checks. It explicitly contrasts itself with delimit_task_complete (closes + advances) and delimit_ledger_list (general listing), so an agent can disambiguate it from a very large sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides the full when/when-not/alternatives structure: when to use ('inside a loop session'), when NOT to use (marking done, listing all tasks), and names the exact sibling tools for those cases. 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses rich behavior (read-only side effects, license gating with require_premium, internal call path, no ledger/notification effects), but it contradicts the annotation readOnlyHint=false by repeatedly asserting the operation is read-only and writes no data. Per the rubric, a description that contradicts annotations scores 1 and must be flagged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The key purpose is front-loaded in the first sentence, and the rest is organized under clear labels (When to use, When NOT to use, Sibling contrast, Side effects, Prerequisite). Dense but every section earns its place for a tool with license-gating and sibling ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema, 100% parameter coverage, and a complex licensing path, the description covers prerequisites, side effects, and sibling routing completely. The only issue is the annotation contradiction, which is scored separately; as prose, the contextual guidance is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents query, source, and time_range with defaults. The description's phrase 'named time window' aligns with time_range but adds no new parameter-level meaning; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: 'Pull numeric metric series from the observability backend (Pro).' It names example metrics (CPU, memory, request rate) and contrasts with delimit_obs_logs (text vs numeric), delimit_obs_status (rollup vs raw), and delimit_obs_alerts (threshold config), 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('during runtime health investigation when you need numeric series'), a pairing strategy with delimit_obs_logs, and clear when-NOT-to-use exclusions that name the correct alternative for each excluded case. No inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is very transparent about side effects, internal backend calls, and experimental status. However, annotations declare readOnlyHint=false while the description explicitly claims 'read-only against the ops backend' and 'No write'. This is a direct contradiction, so the score must be 1 per rubric.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and organized into clear, purposeful sections. Every section contributes actionable information without boilerplate or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers when to use, when not to use, sibling relationships, side effects, backend implementation, and experimental caveats. Since an output schema exists and the tool has only two simple parameters, this is complete enough for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema already documenting environment as required and limit as an integer defaulting to 10. The description adds useful context about 'recent' releases but does not need to restate parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation on a specific resource: returning the recent release timeline for an environment. It also distinguishes itself from related siblings such as delimit_release_status, delimit_release_rollback, and delimit_evidence_collect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to use' and 'When NOT to use' sections with concrete scenarios and names the alternative tools. It also clarifies the time-axis versus point-in-time relationship with delimit_release_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly claims 'Side effects: read-only. Pure validator... no network, no ledger writes, no notifications,' while the annotations declare readOnlyHint: false. This is a direct contradiction: the annotation signals the tool may have write/network effects, but the description insists it is a pure read-only validator. An agent cannot trust the safety profile, which is critical before invoking a pre-submit gate. Flagged as Annotation Contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is well-structured with clearly labeled sections (when to use, when not, sibling contrast, side effects, two stages) and front-loads the purpose. The two-stage explanation is detailed and somewhat documentation-like, so not every sentence is lean, but the complexity of the gate justifies most of the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex policy gate, the description covers the two veto stages, the side-effect profile, mandatory-usage context, and sibling interaction — essentially everything an agent needs to invoke it correctly. The one caveat: the contradictory readOnlyHint annotation leaves the operational safety picture unresolved, which slightly undermines completeness despite the thorough prose. Output schema exists, so return-value documentation 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.
Parameters4/5
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 genuine meaning beyond the schema by explaining how parameters participate in the two-stage logic: repo/repo_description/repo_topics feed the 'target-side veto' and body feeds the 'content shape' checks, including the KYC/deanonymization rationale. This tells the agent WHY each parameter matters, not just what it is.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-and-resource purpose: 'Pre-submit gate for autonomous github outreach' that validates the substantive-content boundary. It explicitly distinguishes itself from the closest sibling: 'delimit_external_pr_check guards PR duplication; this guards the substantive-content boundary itself.' An agent can tell what this tool does and how it differs from delimit_external_pr_check without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('as the LAST step before any agent submits a comment, issue body, or PR description to a third-party github repo via the outreach_substantive task path'), when-NOT-to-use ('for internal repo content, for posts on platforms other than github, or for non-outreach submissions'), mandatory policy context (CLAUDE.md SHIFT-1, founder-approval bypass), and call-ordering relative to delimit_external_pr_check. This is the gold standard for routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior1/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: the description claims 'read-only on policy storage' and says no task, ledger write, or evidence file is created, while the annotations set readOnlyHint to false. This directly conflicts with the structured read-only signal and makes the safety profile ambiguous despite otherwise rich 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but tightly organized with clear sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence carries routing or behavioral information, and the core purpose is front-loaded before the alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers timing, alternatives, licensing, side effects, and input coercion, and an output schema exists so return-value documentation is not required. However, the readOnlyHint false contradiction leaves unresolved ambiguity about whether the tool mutates state, preventing a perfect completeness score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful behavior beyond the schema by specifying that a string context is coerced to {'text': ...} via _coerce_dict_arg and that a malformed context short-circuits with an error response.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states the exact verb and resource: 'Evaluate whether a proposed action triggers governance gating.' The sibling-contrast section explicitly distinguishes it from delimit_gov_policy, delimit_external_pr_check, and delimit_gov_new_task, so an agent can reliably tell this tool apart from its closest alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'When to use' list with concrete scenarios, a 'When NOT to use' list naming the correct alternatives, and a critical timing constraint: the verdict is decision-time and a retroactive call has no gating effect. This is unambiguous routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior1/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'read-only on the log backend' and 'no data is written, no ledger entry, no notification,' but the annotations set readOnlyHint to false. This is a direct annotation contradiction, so the score must be 1 despite the otherwise strong behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with labeled sections: when to use, when not to use, sibling contrast, side effects, and prerequisite. Each section adds distinct 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites, license-gating behavior, failure payloads, internal backend routing, side-effect profile, and use-case constraints. An output schema is present, so return-value details are not required. The only significant flaw is the annotation contradiction, which is scored separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful semantic context beyond the schema by giving example query values (error string, trace id, user id, request id) and clarifying that the search happens over a time window across configured sources.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Search application and system logs across configured sources (Pro).' It also explicitly contrasts itself with delimit_obs_metrics, which returns numeric series, making the tool distinguishable from many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a detailed 'When to use' section with concrete symptoms such as error strings, trace IDs, user IDs, and request IDs, plus a 'When NOT to use' section naming delimit_obs_metrics, delimit_obs_status, and delimit_obs_alerts. It even warns against using it as a streaming/tail-follow surface.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'read-only on the observability backend' and states 'No write, no ledger entry, no notification,' but the annotations set readOnlyHint=false, which signals the tool may modify state. This is a direct annotation contradiction. The description otherwise provides rich behavioral detail about license gating, backend invocation, response wrapping, and error handling, but the contradiction is disqualifying.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: primary purpose, when to use, when not to use, sibling contrast, side effects, args, and returns. Each section earns its place and provides operational guidance without meaningless filler. The main purpose is front-loaded, and the formatting aids agent scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status-rollup tool, the description covers trigger conditions, exclusions, licensing behavior, backend failure behavior, and the exact return shape including keys and license-gate payloads. With an output schema present and rich sibling-tool context, an agent has all necessary information to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to compensate for. The 'Args: None' statement is clear and the description adds useful context that parameter choices are not involved and that behavior is driven by license state rather than arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Return a high-level health rollup from the observability layer (Pro).' It clearly distinguishes itself from sibling tools by contrasting synthesized rollups against raw numeric series from delimit_obs_metrics, and by contrasting the observability layer with the governance layer of delimit_gov_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, naming alternative tools such as delimit_obs_metrics, delimit_obs_logs, and delimit_obs_alerts. It also specifies orchestrator flow context, deploy-gate caveats, and required pairing with delimit_security_audit and delimit_test_smoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Side effects: read-only' and lists the files it reads, but the annotations declare readOnlyHint: false. This directly contradicts the annotation. While the description provides useful detail about what it greps/reads, the contradiction forces a score of 1 per the rubric.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into labeled sections (When to use, When NOT to use, Sibling contrast, Side effects, Args, Returns) with no filler. Each section earns its place, and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the annotation contradiction, the description is otherwise complete: it covers purpose, usage boundaries, side effects, arguments, and return shape ('Dict with cron_installed, last_run_ts, sensor stats...'). An agent has enough to decide whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty. The description explicitly states 'Args: None,' which is clear and sufficient. Baseline 4 applies for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Health check for the vendor-news riff system (LED-1253).' It names concrete sibling tools and clarifies that this tool is specifically the vendor-news subsystem health check, distinguishing it from delimit_vendor_news_draft and delimit_social_daemon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' guidance with concrete diagnostic questions ('is the cron firing? are drafts landing? what's getting rejected?') and 'When NOT to use' rules with named alternatives. This gives an agent clear routing criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the explicit 'Side effects: read-only' statement and the internal call target, but these largely repeat or extend the annotation without revealing meaningful additional behavioral constraints such as permissions, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly organized with clear labeled sections: what it does, when to use it, when not to use it, sibling contrast, and side effects. Every section earns its place, and the key 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only inspection tool with one optional parameter, an output schema, and comprehensive annotations, the description covers all necessary context: target resource, metrics inspected, alternatives, and exclusions. Nothing an agent needs to select or invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single session_id parameter is already fully documented in the schema, including the 'Empty = most recent session' behavior. The description mentions 'for a session' but does not need to add parameter details since the schema carries that burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') with a clear resource ('autonomous loop metrics for a session') and enumerates the metrics returned: iterations completed, cost, errors, and safeguard status. It also distinguishes itself from siblings by stating that delimit_loop_config configures and delimit_build_loop runs, while this tool reports the result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 clearly state the appropriate context for inspection and route the agent to the sibling tools delimit_loop_config and delimit_build_loop. The sibling contrast line reiterates the decision boundary, leaving 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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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" and revealing the underlying call ai.drift_monitor.get_drift_history, which goes beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. There is mild redundancy between the "When NOT to use" section and the "Sibling contrast" section, both making the same delimit_drift_check comparison, but overall the content is tightly written and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation with one optional parameter and an output schema available, the description is complete: it explains the purpose, the use case, the alternative, and the underlying side-effect behavior. Nothing essential for correctly selecting or invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, limit, is fully documented in the input schema with default and meaning, so the description does not need to carry that burden. However, the description itself adds no extra semantic detail about the limit parameter beyond what the schema already states, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "List recent drift-check results from the drift monitor." It also explicitly contrasts itself with delimit_drift_check, making the tool's role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use context (investigate when API spec drift was last detected) and an explicit when-not-to-use instruction with the named alternative delimit_drift_check. The sibling contrast reinforces the decision with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no readOnly or destructive annotations present, the description carries the behavioral burden. It is transparent about being a dispatch core with six possible actions, thin alias wrappers, and a sync_action mapping. The main gap is that potentially mutating actions like rollback and sync are implied by name rather than explicitly flagged as state-changing operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with its core purpose and organized into labeled sections: purpose, when to use, when not to use, and sibling contrast. The long alias lists earn their place because they directly route the agent to the correct tool among hundreds of siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multi-action dispatch tool with 8 parameters and many sibling tools, the description is nearly complete: it defines dispatch scope, differentiates tiers, names alternatives, and relies on the 100%-covered schema for parameter detail. It loses one point for not explicitly disclosing side-effect or safety characteristics of the rollback/sync actions, especially since annotations provide no mutation hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema already gives each of the 8 parameters a thorough description, defaults, and action-scope notes. The description adds only the useful but nonessential cross-reference that the public sync surface names the sub-action 'action' while this implementation receives it as 'sync_action', so it stays at the high-coverage baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a specific verb-plus-resource statement: a unified release-management entry point that dispatches to one of six named actions. It also differentiates itself from the delimit_release_* alias wrappers and from deploy-tier tools, so an agent can distinguish this tool from its many siblings without opening other definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There are explicit 'When to use' and 'When NOT to use' sections. It tells the agent to call this single MCP-registered release surface when selecting an action by name, to prefer specific delimit_release_* aliases from internal code paths, and names the correct alternative tools for deploy status, publish, and linting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects (queuing when draft=True, immediate posting otherwise), rate caps with environment overrides, and approval-email behavior with registry_draft_id. Annotations only say readOnlyHint=false and destructiveHint=false, so the description adds substantial operational context. It does not contradict 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headers and bullets, but it is overlong and repeats the rate cap and auto-trigger rule nearly verbatim. A leaner version would be easier to consume, though the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers when to use, when not to use, side effects, approval flow, rate caps, categories, and per-platform tone. The only material gap is the platform inconsistency between the prose ('Twitter / Reddit', LinkedIn rules) and the schema's twitter-only platform parameter; otherwise an agent has enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 8 parameters at 100%, so the baseline is 3. The description adds useful category values and auto-generation behavior, but its platform guidance (Reddit/LinkedIn tone rules) conflicts with the schema's platform parameter description ('Social platform (twitter)'), which keeps it from rising above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with 'Post to social media (Twitter / Reddit) (Pro)' — a specific verb and resource — and immediately contrasts with delimit_social_generate and delimit_social_history, so an agent can tell this is the actual posting tool. The sibling contrast removes ambiguity about what this tool is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains dedicated 'When to use' and 'When NOT to use' sections, names the alternatives (delimit_social_generate, delimit_social_history, delimit_social_approve), and encodes an explicit auto-trigger rule. This is unambiguous routing guidance beyond anything the schema provides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description reinforces this with 'read-only static analysis.' It also adds useful behavioral context beyond the annotations: the scan targets HTML/JSX/TSX and calls backends.ui_bridge.story_accessibility_test. This adds real transparency without contradicting the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose and clear labeled sections. It is slightly longer than strictly necessary because 'Sibling contrast' partially repeats the information already given in 'When NOT to use,' but the organization makes it easy for an agent to parse, so it remains efficient rather than bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with a fully documented input schema, an output schema, and explicit annotations, the description is complete. It covers what the tool does, when to use it, when not to use it, named alternatives, side effects, and scope. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both standards and project_path clearly documented in the schema itself. The description does not add parameter-level semantics beyond the schema, so the baseline of 3 is appropriate; it neither improves nor harms parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Scan HTML/JSX/TSX for WCAG accessibility issues.' It enumerates concrete problem types (missing alt, missing labels, empty buttons, heading order, aria-hidden on focusable elements), and explicitly distinguishes itself from the layout-focused sibling, making purpose and scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context ('CI gate or pre-merge check on UI changes'), explicit when-not-to-use conditions, and names the exact alternatives (delimit_design_validate_responsive for layout, delimit_story_visual_test for visual regression). This is model routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnlyHint=false and destructiveHint=false; the description adds meaningful side-effect detail by stating it writes a new .tsx file to a specific location via a named backend and detects Tailwind config. This clarifies the mutation behavior beyond what the annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections, front-loads the core purpose, and every sentence serves a distinct function: purpose, usage, exclusions, sibling contrast, and side effects. There is no filler or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, full parameter coverage, annotations, and a description that covers purpose, usage boundaries, alternatives, and side effects. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description mostly restates output_path and project_path behavior already present in the schema, adding little new parameter-level meaning beyond the implementation detail of the backend call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate a React/Next.js component skeleton with Tailwind support.' It also differentiates from siblings by explicitly naming delimit_story_generate and delimit_design_extract_tokens, so an agent can disambiguate without inspecting other schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 and actionable, naming the exact alternative tools for the excluded cases. The sibling contrast reinforces the routing decision, so no inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and destructiveHint=false. The description goes further by disclosing the precise side effect: 'writes tailwind.config.js if missing, otherwise reads the existing one.' It also mentions the backend call, giving the agent a concrete model of what happens when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with labeled sections and front-loads the core purpose. Minor redundancy exists between the opening sentence, 'When to use', and 'Sibling contrast', and the backend call line is implementation detail, but overall every meaningful behavioral fact is included without excessive prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete parameter schema, output schema, and annotations, the description covers the essential behavior: when to use, when not to use, and side effects. It could have added error cases or behavior when no CSS tokens are detected, but for this tool's complexity the current description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level detail beyond the schema, but the schema already documents output_path, project_path, and figma_file_key, including the note that figma_file_key is reserved for future use. There is no gap requiring description compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Read an existing tailwind.config or generate one from detected CSS tokens.' It names the resource and the two behavioral paths, and the 'Sibling contrast' line explicitly distinguishes it from delimit_design_extract_tokens, saying 'this writes a tailwind config from those tokens.' This fully separates it from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to use' and 'When NOT to use' sections, naming the exact alternative tools: delimit_design_extract_tokens for general token extraction and delimit_design_generate_component for component generation. This gives an agent clear 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.
Behavior4/5
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 beyond those by stating the operation is read-only, is a pure structural diff without policy, and specifically calls backends.gateway_core.run_diff. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and organized into brief, scannable guidance sections. Every sentence contributes either to selecting the tool or understanding its behavior; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only annotations, an output schema, 100% parameter documentation, and clear routing to neighboring tools, nothing essential is missing. An agent can correctly decide when to call it and what inputs to provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions for old_spec and new_spec, so the baseline is 3. The description adds general context about the change set but does not need to repeat the parameter-level details the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names the exact action ('Diff two OpenAPI specs'), the resource ('OpenAPI specs'), and the output ('list all changes'), and immediately distinguishes it as 'pure diff, no policy.' It also contrasts with delimit_lint and delimit_diff_report, so an agent can tell it apart from 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'When to use' section, a 'When NOT to use' section that names the CI alternative (delimit_lint) and reporting alternative (delimit_diff_report), plus a sibling contrast. This is unambiguous decision guidance, not merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar for additional disclosure is lower. The description adds useful context by stating 'Side effects: read-only inspection' and naming the underlying backend call, which goes beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core purpose, and organized by use case, exclusions, sibling contrast, and side effects. Every section serves a clear decision-making purpose for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter validation tool with an output schema and strong annotations, the description covers why, when, when not, and what side effects to expect. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single optional 'target' parameter is fully documented in the schema. The description does not add parameter-level detail, but the baseline of 3 is appropriate since the schema already carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Validate documentation quality and completeness.' It explicitly contrasts with delimit_docs_generate, making the tool's purpose unambiguous and distinguished from its sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('as a CI gate to surface missing READMEs, undocumented public functions, and broken internal markdown links') and when-not-to-use guidance with a named alternative. The sibling contrast further clarifies the division of labor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Side effects: read-only on spec + governance state.' It also adds transparency about the underlying call to ai.drift_monitor.check_drift, 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.
Conciseness5/5
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. Every section adds distinct value, and the core statement is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with optional parameters, full schema coverage, an output schema, and read-only annotations, the description provides all necessary operational context: trigger context, exclusions, sibling relationships, and side effects. Nothing critical 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for all three parameters, so the description is not required to repeat parameter meanings. It adds some contextual value by mentioning 'stale baseline,' which relates to staleness_days, but does not meaningfully expand on the schema's parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check for API spec drift since last governance review.' It identifies the specific resource (API spec drift) and distinguishes itself from siblings delimit_lint and delimit_drift_history, 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('scheduled (cron) compliance monitor') and when-not-to-use guidance ('one-shot lint' and 'historical drift'), naming the exact alternative tools. This fully orients an agent for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 naming the underlying backend call 'backends.governance_bridge.status', giving the agent extra implementation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: purpose first, then usage guidance, sibling contrast, and side effects. Every section earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one simple parameter, an output schema present, rich safety annotations, and explicit usage/contrast guidance, 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.
Parameters3/5
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 the repo parameter fully. The description reinforces the per-repo scope but adds no material parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Report governance state (open tasks, decisions) for a repo.' It clearly distinguishes itself from delimit_gov_health and delimit_gov_evaluate via the sibling contrast, so an agent can tell them apart 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit 'When to use' and 'When NOT to use' sections, naming the exact alternative tools and the conditions that route to them. This leaves 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.
Behavior4/5
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 a clear 'Side effects: read-only' statement and names the underlying function call, which provides useful implementation context without contradicting 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with each section earning its place: purpose, usage, exclusions, sibling contrast, and side effects. Key information is front-loaded and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with full schema coverage, an output schema, and clear sibling differentiation, the description covers when to use, when not to use, alternatives, side effects, and the backing implementation. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already documented including defaults and allowed values. The description adds no extra parameter-level meaning, but the schema fully carries the burden, 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.
Purpose5/5
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: 'List session handoff receipts.' It immediately distinguishes itself from sibling write/acknowledge tools, so an agent can tell exactly what this tool does and 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use scenarios ('at session start...', 'to audit acknowledged handoffs') and explicit when-not-to-use guidance with named alternatives (delimit_handoff_create, delimit_handoff_acknowledge). The sibling contrast makes routing unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 useful context beyond these: it states 'Side effects: read-only' and reveals the implementation detail 'Looks up an in-memory help table.' This gives the agent confidence about safety and internal behavior without contradicting 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured with clear labeled sections (When to use, When NOT to use, Sibling contrast, Side effects) and no filler. Every sentence contributes either usage guidance or behavioral context, and the most important purpose statement is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only help tool with one optional parameter and a proper output schema, the description is complete. It covers purpose, usage boundaries, sibling differentiation, side effects, and parameter behavior, so an agent can safely and correctly invoke it without further research.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single optional parameter tool_name is already documented in the schema, including that empty returns the workflows overview. The tool description itself does not add much parameter detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get help for a Delimit tool — purpose, parameters, examples.' It also distinguishes itself from siblings by noting it 'returns per-tool descriptions from the TOOL_HELP table,' making its scope clear against the many delimit_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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' conditions, and names the alternative tools (delimit_version, delimit_gov_health) for those excluded cases. The sibling contrast line further clarifies the boundary by contrasting the returned content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 known. The description adds useful context beyond annotations: it is 'informational only', not a gate decision, and it calls backends.gateway_core.run_impact. This gives the agent a clear picture of behavior without being exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: purpose first, then usage guidance, then sibling contrast, then side effects. Every sentence serves a distinct purpose and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analysis tool with rich annotations, full schema coverage, and an output schema, the description covers purpose, usage, alternatives, exclusions, and side effects. Nothing needed for an agent to select and invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both api_name and dependency_file. The description reinforces that dependency_file is a manifest path (package.json, requirements.txt, go.mod), but this is also in the schema, so no significant extra meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Analyze downstream impact of an API change', and clarifies scope via 'blast radius' and 'dependency manifest'. It also distinguishes itself from delimit_lint by noting that this returns a blast-radius report rather than pass/fail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' guidance, explicitly says 'When NOT to use', and names the exact alternatives (delimit_lint, delimit_gov_evaluate). This fully routes the 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered by structured data. The description adds value beyond that by stating 'Side effects: read-only' and, more usefully, revealing the concrete backing call 'ai.ledger_manager.get_context'. It does not contradict the annotations; the read-only claim aligns with readOnlyHint=true. The minor deduction is because the read-only statement partially duplicates what the annotation already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence summary of the tool's purpose, followed by clearly labeled sections: When to use, When NOT to use, Sibling contrast, and Side effects. Every line earns its place. There is slight redundancy between the 'When NOT to use' and 'Sibling contrast' paragraphs, but it is minor and reinforces rather than bloats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, everything needed for correct selection and invocation is present: usage timing, exclusions with named alternatives, safety profile (via annotations), implementation detail, and the parameter is fully documented in the schema. An output schema exists, so return-format explanation is not the description's burden. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the single optional 'venture' parameter is already documented in the schema ('Project name or path. Empty = auto-detect from cwd.'). The tool description adds no parameter-level detail, but per the rubric the baseline of 3 applies when the schema carries the full burden, and here it does. No extra credit needed, no penalty warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific function: 'Quick summary of what's open in the ledger (top 5 by priority)' — a concrete resource (ledger), scope (open items), and constraint (top 5). It explicitly distinguishes itself from the siblings in the same domain: delimit_ledger_list (full list) and delimit_ledger_query (specific item). An agent can tell this tool apart 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit When-to-use ('at session start as part of the orchestrator session ritual') and When-NOT-to-use guidance with named alternatives (delimit_ledger_list for full list, delimit_ledger_query for a specific item). The sibling contrast section further reinforces the routing decision. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description restates 'read-only' and adds the underlying call to ai.ledger_manager.get_links, but it does not disclose additional behavioral details such as error behavior or response shape; with annotations present the added value is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, scannable, and organized with clear labeled sections (When to use, When NOT to use, Sibling contrast, Side effects). No filler; every sentence adds routing or behavioral value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with full schema coverage and a declared output schema, the description covers purpose, alternatives, exclusions, and side effects. It even names the backing API call. Nothing important is missing for an agent to decide and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters 100%, and the description adds semantic depth beyond the schema by explaining what relationships mean in practice: blocks, depends on, parent/child, related items, duplicates. This helps an agent understand what item_id is actually resolving even though the schema only says 'look up links for.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the exact action — 'List relationships / dependencies for a ledger item' — with a concrete resource and scope. It explicitly contrasts with delimit_ledger_link ('this reads existing ones'), so an agent can distinguish read vs write ledger-link tools immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a dedicated 'When to use' section listing inspection scenarios (blocking, dependencies, parent/child, related items, duplicates) and a 'When NOT to use' section naming the exact alternative tools (delimit_ledger_link, delimit_ledger_update). This leaves 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces this by stating 'Side effects: read-only.' It adds useful internal behavior context by noting that it maps natural language to filters and internally calls list/context queries, which is value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings, front-loads the core purpose, and includes only high-value details: examples, exclusions, sibling contrast, and side effects. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter schema with full coverage, an output schema, and thorough annotations, the description fully covers what an agent needs: when to use it, when not to, how it differs from siblings, and its side effects. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds helpful examples of natural-language queries but does not add significant meaning to the 'venture' parameter beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: asking natural-language questions about the ledger, with concrete examples. It also explicitly distinguishes this tool from delimit_ledger_list and delimit_ledger_context, making the resource and behavior unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to use' and 'When NOT to use' sections, naming the specific alternative tools for structured listing and top-N summaries. This gives an agent clear routing criteria without requiring inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond annotations: it mentions the Free tier, no license gate, and that it calls backends.memory_bridge.get_recent. These details help an agent reason about cost, access, and implementation-level behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear labeled sections: core behavior, when to use, when not to use, sibling contrast, and side effects. It is compact, front-loaded with the primary purpose, and every sentence contributes either usage guidance or behavioral context. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 and an output schema, the description is complete. It covers the use case, exclusions, sibling distinction, side effects, licensing, and implementation path. An agent has everything needed to decide when to call it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single limit parameter is already fully documented in the schema with type, default, and meaning. The description's mention of 'last N memory captures' reinforces the parameter but does not add substantial semantic value 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.
Purpose5/5
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: 'Return the most recent memory entries.' It also clearly differentiates itself from siblings by naming delimit_memory_search as Pro semantic search and positioning this tool as the 'free chronological tail.' An agent can distinguish it from related memory 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('at session start to recall what the previous session was working on, or to scan for the last N memory captures') and explicit when-not-to-use guidance with named alternatives (delimit_memory_search for semantic/structured search, delimit_memory_store for writes). This is model routing behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false and destructiveHint=false, which are coarse. The description adds valuable nuance: action='configure' writes via ai.notify.save_routing_config, action='test' sends test notifications, and action='status' is read-only. This meaningfully clarifies what the tool actually does beyond the annotations. It stops short of 5 because it doesn't discuss persistence/irreversibility of configure, but the disclosure is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear 'When to use', 'When NOT to use', 'Sibling contrast', and 'Side effects' sections. Every sentence serves a purpose: selection guidance, sibling disambiguation, and behavioral disclosure. The ticket reference 'LED-233' 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 optional parameters, an action switch, an output schema, and sibling overlap), the description covers all critical context: purpose, alternatives, side effects, and read-only vs mutating actions. The output schema exists and the annotations are present, so the description does not need to restate return values or safety hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all five parameters with defaults and examples. The description adds behavioral context around actions (configure writes, test sends notifications, status is read-only), which connects the schema to behavior, but it does not add significant new meaning about individual parameter formats beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('impact-based notification routing') and a concrete purpose: inspecting or updating rules that route change alerts to email/webhook/digest by severity. It also distinguishes itself from sibling tools delimit_notify and delimit_notify_inbox, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 (inspect/update routing rules) and when NOT to use it (reading the inbox or firing a single notification), naming the exact alternative tools. This gives unambiguous selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false and destructiveHint=false; the description adds concrete side effects: it triggers init (writes .delimit/) and runs a read-only scan. This is valuable behavioral context beyond the annotations, though it does not go deeper into failure modes or environmental interactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Each section—summary, when to use, when not to use, sibling contrast, side effects—adds distinct value and is front-loaded with the core purpose. No filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully orients an agent: when to call, when not to, which siblings do what, and what side effects to expect. With the output schema and full parameter 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single project_path parameter fully described (default '.'). The tool description adds no extra parameter semantics, aligning with the baseline 3 when the schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific outcome ('60-second guided quickstart for a new install') and clarifies it as the unified first-run flow combining init, scan, and environment detection. It explicitly contrasts with delimit_init, delimit_scan, and delimit_activate, 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
A 'When to use' section defines the exact trigger (immediately after installation) and the 'When NOT to use' section routes to delimit_activate and delimit_diagnose. The sibling contrast further clarifies the alternatives, leaving no ambiguity about when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value beyond them by flagging the tool as 'experimental' and disclosing that remote inputs are shallow-cloned, plus naming the call path via backends.repo_bridge.config_audit. A minor gap is the absence of failure-mode disclosure for invalid or unreachable repo targets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with labeled sections (When to use, When NOT to use, Sibling contrast, Side effects). The core purpose is front-loaded immediately, and every sentence contributes meaningful information — the experimental warning and side-effect disclosure each earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single fully-documented parameter, an output schema, and safety annotations, the description covers all essentials: purpose, routing against siblings, accepted input formats, remote handling behavior, and side effects. Nothing an agent needs to select and invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the single 'target' parameter is already fully documented in the input schema. The description's mention of accepted formats (local path, owner/repo, GitHub URL) largely repeats schema content; the only added meaning is the shallow-clone behavior for remote inputs, which is more behavioral than parameter-semantic. The baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource phrase — 'Audit repository configuration for compliance' — which precisely states the tool's function. It further distinguishes from siblings by contrasting 'delimit_repo_config_validate checks well-formedness; this checks compliance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit 'When to use' and 'When NOT to use' sections with named alternatives: delimit_repo_config_validate for structural validity and delimit_repo_analyze for full quality analysis. The sibling contrast paragraph reinforces the routing decision, leaving no ambiguity about when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive; the description adds that it performs a network call through a driver and names the internal functions it invokes (ai.data_plane.get_driver and the driver's get_* method). This is useful behavioral context beyond the annotations, though it does not detail failure modes or connection requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into labeled sections, starts with the core action, and each sentence carries distinct value: scope, exclusions, sibling contrast, and side effects. There is no filler or redundant repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-item read tool, the description covers what it does, when to use it, when not to, how it behaves, and its side effects; the schema documents all parameters and an output schema exists. An agent has enough context to select and invoke it correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies and the schema already explains repo, driver, resource, and identifier. The description adds no parameter-level detail beyond the schema; its mention of 'single item by identifier' supports conceptual semantics but is not necessary for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a clear resource ('a specific resource from a connected data-plane system'), and explicitly limits scope to a single item by identifier: repo, PR, issue, or workflow run. It also distinguishes itself by saying delimit_resource_list returns many while this returns one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It includes explicit 'When to use' and 'When NOT to use' sections, naming the exact sibling tools to choose instead (delimit_resource_list, delimit_resource_drivers). This gives an agent clear decision criteria rather than leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context by explicitly stating the operation is read-only, that it reads and applies the soul, and that it is cross-model. This aligns with and supplements 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with front-loaded purpose, concise when/where/contrast sections, and a short side-effects note. Every sentence adds value, and the formatting makes scanning easy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers when to use, when not to use, sibling contrast, side effects, and model scope. With a rich output schema and full parameter documentation in the input schema, nothing critical 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions cover 100% of the three parameters, including defaults and empty-string meanings. The description itself adds no parameter-specific detail, but because the schema carries the full burden, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Revive the last session's captured soul') and clearly distinguishes it from sibling tools like delimit_soul_capture and delimit_memory_recent. The unique resource ('soul') and the intent ('any model') are immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('at session start'), when NOT to use (capturing a soul or reading recent memories), and names the alternative tools. It also contrasts with delimit_soul_capture, giving the agent unambiguous routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description reinforces the read-only side effect and names the underlying call 'ai.secrets_broker.get_access_log.' It also adds useful behavioral context by noting that delimit_secret_get appends to this log while this tool reads it back, which helps the agent understand the operational relationship.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear labeled sections: core purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence contributes useful selection or invocation guidance without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only audit-log tool with one optional parameter and an output schema, the description covers purpose, usage boundaries, sibling relationships, and side effects. It provides everything an agent needs to decide when to call it and how it behaves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single optional 'name' parameter with the meaning of an empty value. The description adds no new parameter-level detail, so with 100% schema coverage the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Show the audit log of secret accesses.' It explicitly distinguishes itself from the sibling tools delimit_secret_get and delimit_secret_list by stating what each is for, so an agent can select this tool with confidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete use cases ('compliance review, incident investigation, or to see who/what fetched a credential') and explicit negative guidance ('When NOT to use: to read a secret value... or to inventory secrets...'), naming the alternative tools. This leaves no ambiguity about when the tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 useful behavioral context by stating 'Side effects: read-only on the target' and revealing the internal backend call, which 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings, front-loads the core purpose, and every sentence adds value. It covers usage, exclusions, sibling contrast, and side effects without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema, full parameter documentation, robust annotations (read-only, idempotent, non-destructive), and the presence of an output schema, the description covers all necessary context. It clearly explains when to use this tool versus its security-focused siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single 'target' parameter. The description adds no extra parameter meaning, but with full schema coverage and a simple optional parameter, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Scan a repository for security vulnerabilities.' It also explicitly contrasts itself with sibling tools, distinguishing this built-in scan from ingest and triage tools, so an agent can tell them apart immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance (baseline security pass before deploy/release), when-not-to-use guidance (don't ingest external results or triage findings), and names the alternative sibling tools. This fully routes the 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive behavior, and the description reinforces this with 'Side effects: read-only' while adding new context: it calls backends.gateway_core.run_semver and is deterministic on top of the diff engine output. This goes beyond the annotation metadata without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every section earns its place: core purpose, usage guidance, sibling contrast, and side effects are all compact and front-loaded. The use of short headings makes it easy to scan without any padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with full parameter documentation and an output schema, the description covers all selection-relevant context: what it returns, when to use it, when not to, how it relates to siblings, and side-effect behavior. Nothing an agent needs to pick or invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents old_spec/new_spec as required paths and current_version as optional. The description's mention of 'optionally computing the next version string' mirrors the schema and adds no new parameter-level detail. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb-resource pair—'Classify a spec change's semver bump'—and names the exact output enum (MAJOR/MINOR/PATCH/NONE), so an agent knows exactly what the tool produces. It also explicitly contrasts itself with delimit_diff and delimit_lint, making sibling differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Has explicit 'When to use' and 'When NOT to use' sections that name delimit_lint and delimit_diff as alternatives. The sibling contrast line further clarifies the boundary: this maps a diff to a semver verdict only, while siblings list changes or add policy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this with 'Side effects: read-only' while adding the implementation target (ai.ledger_manager.session_history) and what the recovered content consists of. It stops short of describing edge cases or empty-state behavior, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence summary followed by clearly labeled sections for usage, exclusions, sibling contrast, and side effects. Every line earns its place; there is no filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 annotations covering safety, the description covers selection context, usage timing, sibling distinctions, and side effects. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter, limit, is already documented in the schema with its default. The description's 'last N runs' is largely a restatement of 'recent sessions' and adds no new constraints such as minimum/maximum values or ordering rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Load recent session handoffs for context recovery.' It then contrasts itself with siblings (delimit_session_handoff writes, delimit_revive reads soul state), making its role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit 'When to use' section (session start, to recover completed items, decisions, blockers) and an explicit 'When NOT to use' section naming the correct alternatives. This removes ambiguity for an agent selecting between read and write handoff tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 useful behavioral context beyond that: it only creates a draft, never publishes, and calls ai.social.generate_post. This meaningfully supplements 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, well-structured, and front-loaded with the core purpose before diving into usage guidance. Every sentence provides useful information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has only one optional parameter, and has an output schema. Annotations cover safety semantics, and the description covers purpose, usage boundaries, sibling contrast, and side effects. Nothing critical 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single optional category parameter is already fully documented in the schema. The description does not add parameter-level detail, but it does not need to because the schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a social media post draft without posting, which is a specific verb and resource. It also distinguishes itself from delimit_social_post and delimit_content_publish, so an agent can tell them apart immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it (drafting a tweet for review) and when NOT to use it (publishing, managing targets), and names the alternative tools. 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.
Behavior4/5
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 value beyond annotations by revealing the underlying call (ai.social.get_post_history), explicitly stating 'Side effects: read-only,' and noting that Reddit entries include thread context. This is useful behavioral context, though it could go further with pagination or filtering details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with short labeled sections (When to use, When NOT to use, Sibling contrast, Side effects) that make scanning easy. Every sentence carries functional information, with no filler or redundant restatements of the title. It is dense but appropriately sized for the amount of guidance it provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage conditions, exclusions, sibling relationships, and side effects. With a 100% documented schema and an output schema present, nothing essential for correct invocation is missing. The note about thread context also prepares the agent for the shape of returned Reddit entries. The tool is fully contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all four parameters have clear descriptions in the schema. The tool description does not add parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies. No parameter explanation is missing, but the description contributes no extra semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'View recent social media post history.' It also explicitly differentiates from siblings by stating 'this reads what was already posted,' making it unmistakably distinct from delimit_social_generate and delimit_social_post. The purpose is fully clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 with concrete use cases (recalling prior posts/comments for follow-ups and DM replies) and an explicit 'When NOT to use' section naming delimit_social_generate and delimit_social_target. The sibling contrast further clarifies role boundaries, leaving no ambiguity about when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=false, destructiveHint=false) only signal that the tool mutates and is not destructive. The description adds a Side effects section that classifies which action classes mutate (register/create_tool/create_agent/approve_agent/reload) versus which are read-only (status/venture/agent/list_*/check/approve/guide/rules) — genuinely useful beyond the annotations. Minor deductions: 'approve' appears in the read-only list while 'approve_agent' is in the mutation list, creating slight ambiguity, and permission requirements are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with labeled sections: purpose sentence, when to use, when not to use, sibling contrast, side effects, and a venture-structure note. The purpose is front-loaded and every section earns its place. Slightly long, but the length is justified by the tool's polymorphic action surface with 14+ action values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity tool (7 optional parameters, polymorphic action, no enums), the description covers the critical decisions: when to use it, which actions mutate state, and how it differs from the per-task sibling. Output schema presence relieves it of explaining return values. Remaining gaps: it never states that calling with no arguments defaults to action='status', and the action-specific parameter roles rely on the schema's terse hints ('for register/venture/create_agent').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description earns the extra point by supplying the vocabulary for the polymorphic action parameter — the schema's own action field defers to it ('See actions above') — and by enumerating access_action values (read/write/deploy; deploy_production/deploy_staging/social_post). It does not fully resolve ambiguous parameters like repo_path ('description, or reason depending on action'), but the schema's per-parameter hints cover most of the remaining meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb-resource pairing ('Manage the cross-venture agent swarm') and enumerates concrete capabilities (register a venture with its 5 agent roles, create custom tools, hot-reload modules, check namespace access). It distinguishes itself from delimit_agent_dispatch, which the description explicitly labels as per-task, so an agent can separate the two 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.
Usage Guidelines5/5
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, the latter naming exact alternatives (delimit_agent_dispatch for single-task dispatch; delimit_agent_status / dashboard for agent state). Adds a sibling contrast line and even cites the governing standard (Agent Swarm Standard v1.2). This is complete routing guidance, not merely implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, lowering the bar. The description adds genuinely useful context beyond that: gated by require_premium (a key failure mode), experimental status, and the heuristic nature of coverage-runner detection. The 'Side effects: read-only inspection' line is redundant with the annotation, but the premium gating and reliability caveat earn the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with labeled sections (when to use, when not to use, sibling contrast, side effects), front-loaded with the core function in the first sentence. Each section earns its place; the experimental and premium-gating disclosures justify the length. Only minor redundancy is the read-only line repeating the annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a 2-parameter tool with an output schema and safety annotations. Covers purpose, selection criteria, exclusions, sibling alternatives, side effects, premium gating, backend call, and an experimental/heuristic caveat. The output schema covers return values, so the description needn't explain them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (project_path, threshold) are already documented with descriptions and the threshold has a default. The description mentions 'against a threshold' and pass/fail semantics, echoing the schema rather than adding new parameter-level detail. Baseline 3 is correct when the schema carries the full weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Analyze test coverage for a project') and then sharpens the scope: surfaces coverage by file/folder against a threshold and produces a pass/fail signal for CI. The sibling contrast explicitly distinguishes it from delimit_test_smoke and delimit_test_generate, so an agent can tell them apart 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.
Usage Guidelines5/5
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 with named alternatives (delimit_test_generate for stubs, delimit_test_smoke for smoke runs), plus a sibling-contrast paragraph explaining exactly how each sibling differs. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context by stating that the tool 'writes new test files alongside the source' and explains the parsing approaches for different languages. This goes beyond the structured fields 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly organized into labeled sections that are easy to scan. Every section earns its place: purpose, when to use, when not to use, sibling contrast, and side effects. It is long enough to be useful but not padded with filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema and 100% schema coverage, the description covers the remaining contextual needs: selection criteria, exclusions, side effects, and implementation nuance. An agent has enough 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.
Parameters3/5
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 and the schema already documents all three parameters. The description adds some framing like 'public functions' and framework names, but it does not meaningfully extend the parameter-level semantics provided in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate test skeletons for source code (Jest / pytest / vitest).' It goes beyond a generic label by naming the frameworks and the artifact produced, and the sibling contrast explicitly distinguishes this tool from delimit_test_coverage and delimit_test_smoke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to use' and 'When NOT to use' sections, including concrete alternative tools for excluded cases. The sibling contrast further clarifies the division of labor, leaving no ambiguity about when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral detail beyond those: it is read-only on the project source, calls backends.gateway_core.run_zero_spec, and may invoke a Python subprocess. This is relevant execution context that annotations alone 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action is front-loaded, and the rest is organized into short labeled sections: when to use, when not to use, sibling contrast, and side effects. Each section carries distinct information without unnecessary padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two optional parameters, a well-documented schema, and annotations covering safety, the description supplies the remaining context an agent needs: supported frameworks, alternative routing, and execution side effects. It is complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (python_bin, project_dir) are already documented with defaults and semantic descriptions in the input schema. The description does not add parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Extract OpenAPI spec from framework source code'. It also explicitly differentiates from delimit_lint by stating this tool generates a spec from source rather than operating on an existing spec file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 (delimit_lint, delimit_diff), and specifies the deciding condition: absence of a checked-in spec file. 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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing license gating via require_premium, the backend invocation, the network checks performed, the absence of writes, and the experimental nature with possible partial results. The readOnlyHint=false is consistent with the side-effecting license gating and backend probe, while 'No write' adds useful precision about state mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well-organized with labeled sections and a front-loaded purpose. Some redundancy exists—'experimental' appears twice and the sibling contrast partially repeats the when-not guidance—but the structure makes it easy for an agent to extract the relevant decision information quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and input parameters are fully covered by the schema, the description supplies the missing operational context: workflow position, rollback path, license gating, backend behavior, and experimental caveats. Nothing an agent needs to decide when and how to invoke this tool is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all five parameters. The description adds no parameter-specific meaning beyond naming the verification context, and does not clarify which optional parameters are typically expected for a verification call. Baseline 3 is appropriate because the schema carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Probe a freshly-deployed revision's health.' It clearly distinguishes this tool from delimit_deploy_status, delimit_obs_status, and delimit_test_smoke, and places it within the deploy workflow. An agent can immediately understand what this tool does and how it differs 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('immediately after delimit_deploy_publish'), names the downstream chain, and specifies the rollback path if health is unhealthy. It also provides a dedicated 'When NOT to use' section with concrete alternatives for steady-state checks, metadata reads, and pre-deploy smoke tests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the side effect of writing a markdown reference file via backends.ui_bridge.docs_generate, beyond the annotations. It also clarifies a behavioral limitation: generation does not validate docs. This goes well beyond the structured annotation fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections and front-loaded purpose. There is slight redundancy between the 'When NOT to use' and 'Sibling contrast' sections, both covering the validation distinction, but overall it is compact and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, an output schema, and clear annotations, the description covers purpose, usage, alternative, and side effects. Nothing essential is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single 'target' parameter fully documented in the schema including its default '.'. The description adds project-level context but does not need to compensate for schema gaps. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Generate a markdown API reference') and resource ('from source docstrings/JSDoc'), and clearly distinguishes itself from delimit_docs_validate, which inspects existing docs. An agent immediately knows what this tool produces and how it differs from its sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, names the alternative tool delimit_docs_validate, and explains the key distinction: generation does not validate. This leaves no ambiguity about when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden and meets it: it discloses the write side effect ('Writes a new evidence bundle via backends.repo_bridge.evidence_collect'), the licensing gate (require_premium / Delimit Pro), and the unlicensed failure mode (returns an error with an upgrade URL without running). No annotation contradiction — readOnlyHint=false is consistent with the write behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with labeled sections (When to use, When NOT to use, Sibling contrast, Side effects, Prerequisite) and a front-loaded purpose. Slightly repetitive — the sibling contrast largely restates the when-NOT-to-use section — but every section still earns its place given the licensing and side-effect nuances.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an existing output schema and 100% schema parameter coverage, this description is complete: it covers trigger conditions, exclusions, named alternatives, side effects, prerequisite licensing, and the exact unlicensed failure behavior. There are no meaningful gaps for an agent deciding whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the schema already documents all three parameters. The description adds indirect contextual value by linking gate events (deploy, security audit, test run) to the evidence_type examples, but it does not materially explain 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource: 'Collect evidence artifacts for governance (Pro).' The sibling contrast section explicitly differentiates it from delimit_evidence_verify (verifies) and delimit_ledger (queries the chain), so an agent can distinguish it from nearby 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use conditions ('after a deploy, security audit, test run, or other gate event'), an explicit when-NOT-to-use with named alternatives (delimit_evidence_verify, delimit_ledger), and a sibling contrast. 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.
Behavior5/5
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 valuable behavior beyond those: read-only side effects on policy storage, license gating via require_premium, and the exact unlicensed-call response shape including an upgrade link. This is the kind of contextual behavior an agent needs to predict outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses structured labeled sections for when-to-use, when-not-to-use, side effects, and prerequisites, making it highly scannable. There is minor redundancy between the side-effects note about an unlicensed license payload and the prerequisite section repeating the unlicensed-call behavior, but overall the content is tight and purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 and an output schema, the description covers everything needed: purpose, selection criteria, sibling differentiation, side effects, and licensing behavior. The presence of an output schema means return-value details need not be repeated in the description, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter repo is clearly documented with a default value and description. The tool description does not add parameter-specific meaning beyond the schema, so the baseline of 3 applies. No additional semantic detail is required, but none is provided either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: 'Read the active governance policy for a repository (Pro).' It names the exact resource (governance policy) and the verb (read), and immediately distinguishes itself from delimit_gov_evaluate, which runs an action against the policy rather than returning the policy itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 exactly when to invoke this tool and when to avoid it. The sibling contrast with delimit_gov_evaluate provides a concrete alternative and differentiates the two tools, so an agent can select the correct one without guesswork.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context: the ledger is append-only, hash-chained, stores signed governance events, and can verify integrity. It also discloses that it calls backends.gateway_core.query_ledger, which is useful and consistent with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded key information and labeled sections. A minor redundancy exists: the hash-chained contract ledger is described more than once, and the 'Side effects: read-only' line partly repeats the annotations, but the overall length is still appropriate and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the annotations cover safety, and the input schema covers parameters at 100%, the description is complete for selection and invocation. It explains the data store, integrity verification capability, and sibling distinctions without needing to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not repeat parameter-level details, which is appropriate, but it only lightly contextualizes validate_chain via the 'audit' and 'verify integrity' language. The schema already explains each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Query the append-only contract ledger (hash-chained JSONL).' It clearly distinguishes this tool from delimit_ledger_list and delimit_audit by naming what each sibling reads, so an agent can tell them apart 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit 'When to use' section and an explicit 'When NOT to use' section that names the alternatives (delimit_ledger_list / delimit_ledger_query). The sibling contrast further clarifies routing to delimit_audit vs. this tool, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint: false and destructiveHint: false, which are weak generic signals. The description adds meaningful behavioral disclosure: it "writes a new ledger entry via ai.ledger_manager.add_item" and coerces tags/acceptance_criteria/tools_needed from comma strings to lists via _coerce_list_arg. This reveals internal mechanics and transformation behavior an agent needs to predict outcomes. Minor gap: no mention of error behavior or failure modes (e.g., invalid venture auto-detection).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly organized into labeled sections: purpose, when-to-use, when-not-to-use, sibling contrast, and side effects. Every sentence earns its place, the core purpose is front-loaded, and there is zero filler. The structure makes it scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, 100% schema coverage, an output schema, and annotations, the description covers the decision-critical aspects thoroughly: purpose, alternatives, exclusions, side effects, and coercion. What's missing is prerequisite context — e.g., whether the target project/ledger must already exist, or failure behavior when venture auto-detection from cwd fails. These are real edge cases for a write tool but not crippling gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 — the schema already documents all 13 parameters. The description adds value beyond the schema by explaining that tags, acceptance_criteria, and tools_needed accept comma-separated strings that get coerced to lists, which clarifies the anyOf string/array types. That lifts it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Add a new item to a project's ledger." It then distinguishes itself from siblings explicitly — "delimit_ledger_update changes; delimit_ledger_done closes; this creates" — and from delimit_gov_new_task and delimit_memory_store. An agent can confidently select this tool 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.
Usage Guidelines5/5
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 (work that should outlive the session: tasks, bugs, features, decisions, strategy items) and a "When NOT to use" section naming exact alternatives (delimit_gov_new_task for governance-classed work, delimit_memory_store for quick conversation memory). This is the strongest possible routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses the key side effects: with dry_run=False it archives via bulk_action(archive), with dry_run=True it returns only the plan, items are never hard-deleted, and the JSONL append-only log retains full records. It also explains the composition with the stale-detector and bulk_action, which goes well beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections and front-loaded purpose, but it is somewhat long and repeats sibling contrast in both the 'When NOT to use' and 'Sibling contrast' sections. The trailing internal reference 'LED-1145 Phase 2 #4' also adds little value for an agent selecting or invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, destructive nature, and rich sibling set, the description covers selection criteria, invocation semantics, dry-run behavior, persistence guarantees, and composition with bulk actions. An output schema exists, so lack of explicit return-value detail is acceptable; nothing essential for correct use is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all four parameters with detailed descriptions (100% coverage), so the baseline is 3. The tool description adds general context about the 60-day default and strict threshold, but does not materially extend the schema's parameter-level explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (auto-archive open ledger items dormant past stale-TTL threshold) with the resource and behavior clearly named. It differentiates itself from siblings like delimit_ledger_groom and delimit_ledger_auto_close_external, so an agent can select it accurately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 exact alternatives (delimit_ledger_groom, delimit_ledger_health, delimit_ledger_auto_close_external) and the conditions that route to each. This is ideal for an agent deciding between closely-related ledger tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavioral details beyond the annotations: dry_run defaults to true and returns a plan, false applies changes via delimit_ledger_bulk, detection fields and link formats are specified, an action map covers merged/closed/open/error cases, and errors are recorded. This is thorough and does not contradict the readOnlyHint=false/destructiveHint=false annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, with clear sections for purpose, usage, side effects, detection, and action mapping. It loses one point because the detection fields are introduced twice in near-identical wording: once in prose and again in the bulleted list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of this complexity, the description is remarkably complete: it covers side effects, dry-run behavior, detection patterns, per-state actions, error/404 handling, implementation reuse, and output truncation. The presence of an output schema means return-value details do not need to be repeated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description largely restates what the parameter schemas already say (dry_run plan vs apply, venture auto-detection, max_items cap with truncated=True). It adds no significant parameter-level 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.
Purpose5/5
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: 'Auto-close ledger items whose linked GitHub issue/PR already resolved.' It also distinguishes itself from delimit_ledger_done, making the tool's batch/auto-detection scope immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 concrete alternatives (delimit_ledger_done for manual per-item closing, delimit_resource_get for reading external state) and clarify the periodic-maintenance context. This leaves little ambiguity about when this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 goes further by explaining that the tool returns proposals only, never applies changes, requires founder review before risky operations, and includes a copy-pasteable ready_to_apply invocation. This adds meaningful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, with clear When to use, When NOT to use, and Sibling contrast sections. However, the final LED-1145 paragraph largely repeats the Side effects paragraph, creating minor redundancy that could be trimmed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 alternatives, safety behavior, and the proposal response pattern. Since an output schema exists, return-value details do not need to be repeated. All four parameters have defaults and descriptions, so an agent has everything needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters with defaults and meanings. The description adds high-level context by mentioning stale, duplicate, and garbage detectors, but it does not add meaningful detail beyond the schema's per-parameter descriptions. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read-only grooming proposal — flags stale / duplicate / garbage items.' It clearly distinguishes itself from nearby ledger tools by positioning itself as 'the read-only proposer' versus delimit_ledger_bulk's applying role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('as a periodic review tool'), when NOT to use it ('to apply the changes'), and names the alternative (delimit_ledger_bulk). The sibling contrast further clarifies that delimit_ledger_health composes this with other checks, leaving 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent/destructive annotations, it discloses that the tool internally calls list_items + groom + P0 quota helpers, is a composition, and produces a self-contained response with pre-formatted next_actions. This gives an agent an accurate model of what happens when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-line summary and uses clear section labels. It is somewhat longer than strictly necessary — the 'LED-1145 capstone' line and the detailed Returns list partly duplicate the output schema and earlier usage guidance — but the structure keeps it scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers selection criteria, exclusions, side effects, internal behavior, output shape, and self-contained actionability. With a rich output schema and annotations also present, nothing an agent needs to invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes venture, stale_days, and dup_min_count, including defaults. The description adds only indirect context, so it meets the baseline but adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening phrase 'One-shot ledger health check — totals + P0 + stale + duplicates + garbage' combines a specific verb, resource, and distinctive scope. It also names sibling tools it composes, so an agent can distinguish it from delimit_ledger_groom and delimit_ledger_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (session start or nightly review), when not to use (applying changes or inspecting a single item), and names the correct alternatives (delimit_ledger_bulk, delimit_ledger_query). This is exactly the guidance needed for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds 'read-only' and explicitly names the underlying call 'ai.license.get_license', plus a return shape with next_steps. This is useful context beyond the annotations, though no rate limits or error behaviors are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections and front-loaded purpose. It is slightly repetitive in stating the read-only nature multiple times ('this is a read', 'read-only', 'this reads license state'), but overall every section adds meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool, the description is complete: it explains purpose, usage triggers, exclusions, sibling contrast, side effects, underlying call, and return fields. No important detail an agent would need 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered at 100%. The description includes 'Args: None,' which confirms the empty schema and gives agents no reason to invent arguments. This meets the no-parameter baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: "Report the current Delimit license tier, validity, and expiry." This clearly identifies the resource and the action. It further distinguishes itself from siblings by noting it reads license state while gated tools call require_premium internally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, including diagnostic scenarios like require_premium rejections. It names concrete sibling tools and clarifies it is not for installing or rotating licenses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by detailing exact side effects: writes to target_path, marker-based replacement semantics, append behavior when markers are absent, file creation when missing, and one-way projection with format-drift risk. This is exemplary transparency for a tool that modifies files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and front-loaded purpose. It is longer than average but the side-effect detail is necessary for safe invocation. The trailing 'LED-1165 Phase 2 #5 PR-B.' reference is internal metadata that does not help an agent select or invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with complex file-writing behavior, the description covers when to use it, when not to use it, exact file mutation behavior, marker handling, default path, and the one-way projection constraint. With an output schema present, no return-value documentation is needed. The description is fully sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with descriptions at 100% coverage, so the baseline is 3. The description does not add much parameter-level detail beyond what the schema provides, though it does reinforce the default target path in the side-effects section.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Project delimit_memory hot entries into Claude Code's MEMORY.md.' This states exactly what the tool does and distinguishes it from memory-store, search, and recent siblings by positioning it as the one-way projection tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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_memory_store, delimit_memory_search, and delimit_memory_recent. The sibling contrast reinforces the routing decision, leaving no ambiguity about when this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 depth: it writes via backends.memory_bridge.store, has no license gate on the Free tier, and explains that hot_load=True projects into the MEMORY.md hot-load index on next sync. No contradiction with annotations; a small gap is the lack of detail on idempotency or overwrite behavior, but the core side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and front-loaded purpose. It is slightly longer than strictly necessary — the side-effects section repeats that a memory entry is written — but every section earns its place and the organization helps an agent scan quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter write tool, the description covers when to use it, when not to use it, how it differs from siblings, its side effects, and the hot_load behavior. An output schema exists, so detailed return-value documentation is unnecessary. Nothing essential 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.
Parameters4/5
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 content, tags, context, and hot_load. The description adds value beyond the schema by explaining the real-world consequence of hot_load=True (projection into the Claude Code MEMORY.md hot-load index), which is more informative than the schema's phrasing. It could also elaborate on tags/context semantics, but those are already adequately covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Store a memory entry for future cross-session retrieval.' It then explicitly contrasts with sibling tools: delimit_memory_search retrieves, delimit_memory_recent reads the tail, and this one writes. This leaves no ambiguity about the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 tied to the orchestrator's memory rules and specific content types, plus a 'When NOT to use' section with a named alternative (delimit_context_write for venture-scoped artifacts). It also clarifies that routine code changes belong in git. 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by detailing side effects per action: action='poll' with process=True forwards owner-action emails (network writes), process=False is dry-run, and action='status'/'history' are read-only. This is exactly the kind of behavioral context an agent needs, and it does not contradict 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections and front-loaded purpose. It is slightly longer than strictly necessary because it restates action/process behavior that the schema already documents, but every section serves a clear decision-making purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mixed read/write behavior, three optional parameters, and existing output schema, the description fully covers when to use it, what side effects it may have, how to stay safe with dry-run, and which siblings are alternatives. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents limit, action, and process. The description reinforces the action/process interplay but does not add new parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource combination: 'Check inbound email inbox, classify, and route.' It clearly distinguishes the tool from its siblings by naming delimit_notify (outbound) and delimit_inbox_daemon (daemon control), so an agent can identify what this tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 poll the operator inbox and classify which emails require owner action'), when NOT to use it ('to send notifications ... or control the polling daemon'), and provides sibling contrast. 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=false, destructiveHint=true) correctly signal a mixed read/write tool, and the description richly expands on this: it breaks down which actions are READ-ONLY, which sub-actions mutate alert configuration, the require_premium license-gating behavior (unlicensed callers get a license payload with no backend call), the experimental alerts path with evolving schema, deterministic error format, and explicit non-effects (no ledger writes, no notifications). This goes far beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long (~280 words) but earns most of its length given the tool's complexity: 4 actions, mixed read/write paths, license gates. It is front-loaded with the core purpose and uses clear labeled sections (When to use, When NOT to use, Sibling contrast, Side effects). There is some redundancy — the alias relationship is explained three times across the when-to-use, when-not-to-use, and sibling-contrast sections — which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, 4-action tool with mixed side-effect profiles, license gating, and an experimental write path, this description is remarkably complete. It covers dispatch semantics, per-action return behavior, read/write boundaries, license-gate failure behavior, error format, and known volatility of the alert_rule schema. An output schema exists, so detailed return-shape documentation is not required from the description. Nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 — the schema already thoroughly documents every parameter's action-scoping, defaults, and requiredness. The description adds a modest framing layer (what each action returns — numeric series, text matches, health rollup — and which params matter per action), but it doesn't add per-parameter detail beyond the schema. It reinforces rather than extends.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — "Unified observability entry point — dispatches to one of four actions" — and enumerates exactly what the four actions cover (runtime metrics, log search, alert-rule management, health rollup). It explicitly contrasts itself with the delimit_obs_* wrapper siblings, calling itself the dispatch core, and even steers away from delimit_gov_health. An agent can tell exactly what this tool is for 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.
Usage Guidelines5/5
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 alternative-selection guidance. It names the exact conditions under which to prefer the delimit_obs_* aliases (internal code paths, docstring/license-gate placement) and points governance-kernel callers to delimit_gov_health. The sibling contrast section further explains the alias relationship. 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses concrete side effects: launching headless Chromium or a terminal subprocess, writing MP4/GIF files to ~/.delimit/recordings/, gating on require_premium, and returning an upgrade error without running when unlicensed. Annotations only provide readOnlyHint=false and destructiveHint=false, so this description adds substantial behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headers, front-loaded purpose, and useful side-effect and prerequisite sections. It is slightly longer than necessary because the 'When NOT to use' and 'Sibling contrast' sections partially overlap, but every section still contributes actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with optional parameters, a Pro licensing prerequisite, file-output side effects, and an output schema, the description covers the prerequisite, the failure behavior, output locations, duration cap, and sibling differentiation. Nothing an agent needs to decide whether and how to invoke it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all five parameters with defaults and constraints. The description reinforces the 120-second cap and browser/terminal modes, but does not add significant 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.
Purpose5/5
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: 'Record a screen capture (browser or terminal session)'. It clearly identifies this as a duration-bound recording tool and contrasts it directly with delimit_screenshot, making the tool's identity and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 naming delimit_screenshot as the alternative for still images. This gives an agent a clear decision rule for selecting this tool over its closest sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses concrete side effects: launching headless Chromium via Playwright, writing a PNG under ~/.delimit/screenshots/, and requiring a Pro license. It also describes the unlicensed failure response, which makes actual runtime behavior predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections and the core action front-loaded. There is minor redundancy—'headless Chromium' appears twice and Pro is mentioned in both the opening and prerequisite—but every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description covers purpose, usage boundaries, sibling comparison, side effects, licensing prerequisite, and failure behavior. Nothing an agent needs 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.
Parameters3/5
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 url and name. The description adds context about the output artifact (a PNG file under ~/.delimit/screenshots/) but does not provide additional parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb and resource: 'Take a screenshot of a URL using headless Chromium.' It also explicitly distinguishes itself from delimit_screen_record, so an agent can tell them apart despite the 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use scenarios (audit evidence, visual regression baselines, documentation captures) and explicit when-not-to-use cases (time-based recordings, rendered HTML extraction). For time-based recordings it names the alternative tool, delimit_screen_record.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, the description states read-only side effects, calls an internal backend, discloses the lazy-import behavior ('returns verification_unavailable' if cryptography is absent), and notes there is no license gate. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized and front-loaded with purpose, but it is slightly repetitive: 'Free tier' and 'No license gate' say similar things, and the signature/content-pin checks are described twice. Still, each major section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with schemas and annotations carrying the structured details, the description adds the necessary selection context, side-effect and failure-mode transparency, sibling differentiation, and mode guidance. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description reinforces mode='a1' context but does not add significant parameter-level meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: verifying a Delimit Seal receipt against the bundled Layer-0 constitution, with concrete checks (content-pin, Ed25519 signature, structure). It distinguishes itself from delimit_evidence_verify by naming what this tool checks versus what the sibling checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 alternatives: delimit_evidence_verify for evidence bundles and delimit_ledger for ledger queries. The mode='a1' path is also scoped with a condition, leaving no ambiguity about when this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses concrete behavioral details: writes findings to the ledger, creates new items, optionally closes resolved ones, computes a stable fingerprint for diffing, is gated by require_premium, and returns a specific unlicensed-call error without running. This fully informs the agent of side effects and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and front-loaded purpose. It is slightly redundant, repeating the Pro/premium requirement and partially restating sibling contrast, but overall every major section earns its place and the length is justified for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return-value documentation is not required. The description covers when to use, when not to use, sibling alternatives, side effects, prerequisites, and unlicensed behavior. Nothing critical is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters thoroughly, including allowed scanner names and auto-detect behavior. The description adds useful high-level context about external scanner JSON output but does not contribute meaningfully beyond the schema for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Ingest external security scan output and normalize into ledger findings.' It immediately distinguishes itself from delimit_security_scan and delimit_security_deliberate by naming the exact bridging role it plays, 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.
Usage Guidelines5/5
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, names the alternative tools (delimit_security_scan, delimit_security_deliberate), and explains the sibling contrast. An agent can reliably decide whether to call this tool or a sibling without further inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and destructiveHint=false, which are coarse. The description adds crucial per-action side effects: 'promote' writes a ledger item, 'freeze' cold-archives a month, and 'query', 'digest', 'show', 'status' are read-only. It also names the storage path, giving the agent a realistic behavioral model 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections and front-loaded purpose. It is slightly longer than strictly necessary because 'Sibling contrast' partially repeats the 'When NOT to use' content, but every section contributes useful decision and side-effect information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action tool with eight optional parameters and an output schema, the description covers the corpus boundary, when to use it, when not to use it, alternatives, side effects, and read-only vs write actions. Combined with the fully documented schema, nothing essential 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% and each parameter already has a clear description with defaults and allowed values. The tool description doesn't add parameter-level detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'review and manage the signal corpus (LED-877).' It clearly distinguishes this tool from platform sensors and ledger write tools by naming them directly, so an agent can tell it apart from delimit_reddit_scan, delimit_github_scan, and delimit_ledger_add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, names the exact alternative tools for each excluded case, and adds a sibling contrast sentence that captures the boundary: sensors capture; this manages. An agent has clear decision criteria for selecting this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by describing side effects: writes a handoff record via ai.ledger_manager.session_handoff, coerces list inputs from comma strings, and refreshes a pointer-soul for project_path which affects future delimit_revive behavior. This discloses meaningful state-changing behavior beyond what readOnlyHint/destructiveHint convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but logically structured with a lead sentence, usage guidance, sibling contrast, and side effects. The internal ticket reference (LED-3731) adds minor noise, but every major section earns its place and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with an output schema, complete schema coverage, and clear annotations, this description covers the action, alternatives, side effects, and downstream behavioral implications. Nothing needed for correct invocation or sibling differentiation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so detailed per-parameter semantics already exist in the schema. The description adds useful context about comma-string coercion and project_path default behavior, but these are also partially implied by the schema and do not fundamentally compensate for missing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Save a session summary') with a clear resource and purpose (cross-session continuity). It also distinguishes the tool from siblings by explicitly contrasting it with delimit_soul_capture and delimit_memory_store.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, including named alternatives (delimit_soul_capture, delimit_memory_store) and the conditions that would select each. This gives the agent directly actionable routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only and non-destructive. The description adds valuable side-effect disclosure: it writes a new .stories.tsx file next to the component and coerces variants via _coerce_list_arg. It could also state what happens if the target file already exists, but the provided behavior is still solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections: purpose, when/how to use, sibling contrast, and side effects. Every sentence contributes useful information without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage boundaries, side effects, and variant coercion. An output schema exists, so return-value documentation is not required. The only minor gap is whether an existing .stories.tsx file is overwritten, but overall the description is sufficiently complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining that variants can be supplied as a comma string and are coerced to a list, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Generate a .stories.tsx file for a UI component.' It also clarifies the Storybook-free context and contrasts with delimit_design_generate_component, so an agent can distinguish it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 alternative tools (delimit_story_accessibility and delimit_design_generate_component). This leaves no ambiguity about routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and destructiveHint=false; the description adds the critical nuance that the first run writes baseline images while subsequent runs are read-only against the baseline. It also discloses the Puppeteer fallback when Playwright is unavailable. These are genuine behavioral disclosures beyond what annotations convey, and they are consistent with the annotations (write-on-first-run aligns with readOnlyHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then organized into labeled sections (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence carries distinct information; there is no redundancy or filler, and the structure makes it scannable for an agent deciding whether to call it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with an output schema and annotations covering the safety profile, the description is highly complete: it covers purpose, selection criteria, alternatives, side effects, and engine fallback. The only minor gap is absence of any permissions/auth prerequisites, which is a small omission for a tool capable of writing baseline files.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies: the schema already documents url, threshold, and project_path clearly. The description adds only indirect context (baseline lifecycle, what the threshold measures) but no parameter-specific syntax or format details beyond the schema. This is adequate but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line 'Run visual regression test — screenshot vs stored baseline' uses a specific verb, names the exact resource, and defines the core mechanism in one sentence. The sibling-contrast section further pins down what this tool is not (delimit_screenshot is a single image without baseline; delimit_story_accessibility audits HTML), making it unmistakably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 exact CI-gate scenario, and gives two concrete alternatives with the conditions that select them: delimit_story_accessibility for a11y checks and delimit_screenshot for one-off screenshots. 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly/idempotent/non-destructive, and the description adds meaningful behavior beyond them: read-only backend, Pro license gate, internal backend call, and the exact unlicensed error/upgrade response. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well organized with scannable sections and front-loaded purpose; only minor redundancy remains ('Pro', 'gated by require_premium', and the prerequisite section all state the same requirement).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers use cases, exclusions, sibling contrast, side effects, licensing prerequisite, and unlicensed behavior; output schema exists so return-value detail is not required. Nothing needed to invoke correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single query parameter is fully documented by the schema (100% coverage), so the description need not repeat it. It adds only the high-level 'by query string' phrasing, which is adequate but no additional parameter detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete action on a defined resource: 'Search vault entries by query string'. It additionally scopes the target as long-lived vault content and names the exact sibling it is not for memory, so an agent can distinguish it easily.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 exact alternatives: delimit_memory_search for conversation memory and delimit_vault_snapshot for state capture. Sibling contrast explains different storage and semantics. No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explicitly discloses side effects: 'read-only scan' and 'Writes nothing.' Since readOnlyHint is false, this goes beyond the annotations and gives the agent concrete safety information that the structured metadata does 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every section earns its place: purpose, when to use, when not to use, sibling contrast, and side effects. The structure is scannable and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two simple parameters, a present output schema, and clear side-effect disclosure, the description is fully complete for an agent to select and invoke the tool correctly. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents project_path and output_format. The description adds no parameter-level detail, but none is needed; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Scan a project for React/Vue/Svelte components and emit a catalog.' It clearly differentiates from sibling tools by stating it lists existing components rather than generating new ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 alternative tools delimit_design_generate_component and delimit_story_generate. The sibling contrast sentence reinforces the selection boundary, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the minimal annotations, it discloses that the tool is read-only on inputs but writes a rendered HTML/JSON file when output_file is provided, plus a useful detail about inline CSS/no external dependencies. This is meaningful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured with labelled sections, front-loaded purpose, and every sentence adds value. The when-to-use, contrast, and side-effect notes are compact and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the annotations mark safety, the description covers the remaining operational context: use cases, alternatives, side effects, and output characteristics. Nothing needed for correct selection or invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds report-composition context (diff, policy, semver, spec health, migration guide) but does not materially enrich parameter-level semantics beyond that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Generate a shareable API diff report with full analysis.' It then distinguishes this tool from delimit_lint and delimit_diff, so an agent can select it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use scenarios (API review, PR comment, compliance record), a clear when-not-to-use section with named alternatives, and a sibling contrast line. An agent knows exactly when to choose this tool instead of delimit_lint or delimit_diff.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 well covered. The description adds 'Side effects: read-only' and the internal backend call 'backends.gateway_core.run_explain', which provides useful implementation transparency consistent with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, front-loading purpose before usage guidance and side effects. Every section earns its place, and the sibling contrast avoids redundant repetition while adding clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return-value explanation is unnecessary. The description covers purpose, use cases, exclusions, sibling alternatives, side effects, and an internal call reference, leaving no meaningful gaps for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by mapping template-oriented outputs to use cases like migration notes, PR comments, changelog entries, and Slack summaries, enriching the meaning of the template parameter beyond the schema's enum-like list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Render a human-readable explanation of API changes (7 templates).' It clearly identifies the tool's deliverable and explicitly contrasts it with delimit_diff and delimit_diff_report, making it easy to distinguish from the closest siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 listing concrete use cases, a 'When NOT to use' section naming sibling alternatives, and a 'Sibling contrast' section. This gives an agent complete routing guidance for when to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. The description adds valuable behavioral context beyond that: it is fail-closed, makes a network call, shells out to gh CLI via a named backend, and defines the exact duplicate condition (open PR or PR merged in last 30 days). This is far richer than the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear labels, front-loaded with the key instruction, and every sentence earns its place. It is detailed but not bloated, and the sibling contrast is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations and output schema, the description covers the trigger conditions, exclusions, side effects, backend implementation, fail-closed behavior, and the verdict threshold. An agent has enough context to decide to call this tool and to interpret its outcome correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters with defaults and examples. The description does not add much parameter-specific meaning, though it gives useful context about repo ownership and the duplicate verdict condition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: a pre-PR duplicate guard for external repos. It also explicitly distinguishes itself from delimit_gov_evaluate, so an agent can tell them apart 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('as the first step before drafting any PR against a repo you don't own'), explicit when-not-to-use guidance (internal repos or non-PR actions), and names the alternative tool to use instead (delimit_gov_evaluate).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses require_premium gating with unlicensed behavior, the backend invocation, the run record side effect, routing through _with_next_steps, and explicitly notes the tool records execution rather than performing work. This is substantial 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but highly structured with labeled sections: when to use, when NOT to use, sibling contrast, and side effects. Every section adds decision-relevant information with minimal redundancy. The key 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description does not need to explain return values, yet it still mentions the orchestrator hints in the response. It covers licensing, side effects, pipeline ordering, and the limitation that no underlying work is performed. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both repo and task_id. The narrative adds useful context such as task_id being required despite not being marked required in the schema, but it does not add much meaning beyond what the schema descriptions already convey. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource: 'Execute a previously created governance task under policy (Pro).' It clearly differentiates from siblings by naming the pipeline step and contrasts with delimit_gov_evaluate, new_task, and verify. The purpose is unambiguous even 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it (step two, after new_task, before verify), when NOT to use it (evaluate, new_task, verify), and provides a sibling contrast plus the full pipeline: new_task -> run -> verify. This gives the agent complete routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses concrete side effects beyond the annotations: writes an acknowledgement record via ai.handoff_receipts.acknowledge_receipt and flips receipt status from pending to acknowledged. This adds meaningful behavioral context and does not contradict readOnlyHint=false or destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose, usage, sibling contrast, and side effects. Every section earns its place, and the key operational guidance is front-loaded before the longer side-effect detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a handoff-acknowledgement tool: it explains when to use it, when not to, how it differs from siblings, and what state changes it causes. Since an output schema exists, the description does not need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already documents notes, receipt_id, and project_path. The description reinforces that a specific receipt is targeted but does not add new parameter-level meaning beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Acknowledge a pending handoff receipt before starting work.' It also distinguishes itself from sibling tools by noting delimit_handoff_create writes, delimit_handoff_list reads, and this tool 'closes the loop on a specific receipt.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a when-to-use condition ('at session start when delimit_handoff_list shows a pending receipt') and a when-NOT-to-use section that names the alternatives (delimit_handoff_create and delimit_handoff_list). 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing the concrete side effect: 'writes a new handoff receipt via ai.handoff_receipts.create_receipt.' It also documents the expected lifecycle next step, stating 'The receiving agent should later call delimit_handoff_acknowledge.' This is consistent with readOnlyHint=false and destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence earns its place, and the core purpose is front-loaded before the usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the description covers purpose, usage boundaries, sibling differentiation, side effects, and follow-up action, nothing essential is missing for an agent to invoke this tool correctly. It is complete for a write-oriented handoff tool with many optional fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for all 11 parameters, so the baseline is 3. The description adds only modest context by noting the 'explicit completed/not-completed/blockers/scope fields,' which is helpful but does not materially deepen parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Create a handoff receipt when transitioning between agents.' It clearly differentiates itself from sibling tools by naming delimit_session_handoff, delimit_soul_capture, and delimit_handoff_acknowledge in the sibling contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use ('at the end of a session or before passing work to another model'), when not to use ('for general session summary' or 'to acknowledge a receipt'), and names the exact alternative tools. This leaves no ambiguity for an agent deciding between related handoff tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses concrete side effects: writing a frozen marker to a specific backend path and causing subsequent writes to the dataset id to be rejected. This adds meaningful behavioral context beyond the annotations, which only indicate readOnlyHint=false and destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence followed by concise, purposeful sections for usage, non-usage, sibling contrast, and side effects. Every sentence adds relevant information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema, annotations, and clear sibling routing, the description is complete. It captures the action, rationale, exclusions, side effects, and consequences for future writes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with dataset_id already documented as the registry identifier and required. The description adds minimal new semantic detail about the parameter itself, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Freeze a dataset to make it immutable for replay integrity.' It clearly distinguishes this tool from siblings by contrasting list, register, and freeze behaviors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to use' and 'When NOT to use' sections, including a specific alternative for inspection (delimit_intel_dataset_list). It also explains that deletion is inappropriate because the registry is append-only, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description reinforces this with 'Side effects: read-only' and 'this reads metadata.' It also adds a concrete backend call and return shape, giving the agent useful behavioral context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections and front-loads the core purpose. Every section adds useful guidance: usage, exclusions, side effects, args, and returns, without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, zero-parameter inventory tool with an output schema present, the description fully covers what the tool does, when to use it, what it returns, and how it differs from siblings. Nothing an agent needs 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is 100% covered by an empty properties object. The description explicitly states 'Args: None,' which 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'List all datasets in the intel registry.' It also differentiates itself from siblings by contrasting read vs. write vs. lock behavior, so the agent can distinguish it from delimit_intel_dataset_register and delimit_intel_dataset_freeze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, including the exact sibling tools to use instead for registration and freezing. The sibling contrast reinforces the decision boundary, leaving no ambiguity about when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=false and destructiveHint=false, but the description adds useful behavioral detail: it writes a registry entry through a specific backend path and coerces schema from JSON string to dict. It does not fully describe duplicate-name behavior or error handling, but it goes beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with labeled sections for usage, non-usage, sibling contrast, and side effects. Every part adds decision-relevant information, and important content is front-loaded in the opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a registration tool with a small input schema and an output schema, this description is complete enough: it tells the agent when to use it, when not to, how it contrasts with siblings, and what side effects to expect. The presence of an output schema means return-value details are not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful parameter-related context by explicitly noting that the schema argument is coerced from a JSON string to a dict. This helps the agent understand how to supply the schema parameter beyond the schema's own type declaration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action 'Register a new dataset' and names the target resource ('file-based intel registry'). It further distinguishes the tool from siblings by stating 'this creates' relative to inventory and freeze operations, so there is no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 alternative tools for writing data (delimit_intel_snapshot_ingest) and inventorying datasets (delimit_intel_dataset_list). This gives an agent clear decision criteria and removes reliance on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds value by stating the backend call target and the parameter coercion behavior. This gives an agent concrete expectations about internal behavior beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and uses labeled sections for usage guidance and side effects. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema, complete parameter schema, clear annotations, and explicit sibling alternatives, nothing critical is missing. The description fully equips an agent to invoke the tool correctly and understand its side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already fully documents query, dataset_id, and parameters. The description adds a helpful high-level summary of search dimensions ('keyword, date, or dataset') but does not materially go beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search saved intel snapshots by keyword, date, or dataset.' It clearly differentiates from siblings by naming exactly what this tool is not (ingest, dataset listing) and contrasting it with delimit_intel_snapshot_ingest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 alternative tools for ingestion and dataset listing. This leaves no ambiguity about when to select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is not read-only and not destructive. The description goes beyond that by disclosing the side effect of writing a snapshot record via a specific backend and explaining that data and provenance are coerced from JSON strings to dicts via _coerce_dict_arg. This adds useful behavioral detail, though it does not fully address idempotency or failure semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence contributes useful information, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with full schema descriptions, an output schema, and safety annotations, the description covers purpose, usage boundaries, sibling relationships, side effects, and parameter coercion behavior. An agent has enough information to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters. The description adds meaningful value by mentioning the JSON-string-to-dict coercion behavior, which is not obvious from the schema alone and directly affects how callers can pass data and provenance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Store a research snapshot with provenance in the intel store.' It further distinguishes itself from the closely related siblings delimit_intel_dataset_register and delimit_intel_query, making the tool's purpose immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, names the alternative tools to use instead, and includes a sibling contrast ('register declares; query reads; this writes'). An agent can confidently decide whether 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining behavior. It clearly discloses that dry_run=False writes status/priority/tag changes, that per-item failures do not block the batch, and that callers must explicitly pass dry_run=False to apply. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections, front-loaded purpose, and minimal redundancy. It loses a point for the 'LED-1145 Phase 1 PR-B' ticket reference, which adds non-actionable noise for an agent, but overall each substantive section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers when to use the tool, when not to use it, alternative tools, side effects, default behavior, and failure semantics, and an output schema exists for return values. The main gap is that the set of valid action strings is not explicitly enumerated in the description, which would make invocation more robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds meaningful context by explaining dry_run semantics and the write side effects tied to status/priority/tag actions. It does not enumerate the exact action enum values, but related parameter descriptions partially compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb and object—'Apply one action to many ledger items in a single call'—making the tool's core function immediately clear. It also explicitly contrasts with delimit_ledger_update and delimit_ledger_groom, so an agent can distinguish this bulk-applier from its 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes dedicated 'When to use' and 'When NOT to use' guidance, plus a direct sibling contrast. It tells the agent to use single-item tools for one item and to reach for this tool only after a grooming/list step produces multiple IDs needing the same change.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark readOnlyHint=false and destructiveHint=false, leaving the mutation profile unspecified; the description fills this by stating it 'writes status="done"' and calls ai.ledger_manager.update_item. It also discloses the conditional side effect of attaching a ship_proof block with verified=True and mentions Phase 2 changes, which are exactly the behavioral traits an agent cannot infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the one-line purpose, then uses clear headings for usage, alternatives, and side effects. It is a few sentences longer than minimal, but each section earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a rich 100%-covered schema, an output schema, and non-conflicting annotations, so the main missing context was when to use it and what side effects it triggers, both covered. An agent has enough information to select it, call it with correct parameters, and anticipate the verified=True behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already documented (e.g., pr_url says it is parsed into pr_owner/pr_repo/pr_number and sets verified=True). The description cross-references the ship-proof behavior but does not need to add per-parameter detail; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Mark a ledger item as done (convenience wrapper).' It immediately positions itself against delimit_ledger_update ('this is the close-out shortcut'), so an agent can distinguish it from the large ledger sibling family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 state the condition for choosing this tool (single-call close-out) and direct other field edits to delimit_ledger_update and creations to delimit_ledger_add. Sibling contrast reinforces the distinction, so routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds useful context: it explicitly states 'Side effects: read-only', names the underlying implementation call, and explains the back-compat behavior of single-value status/priority. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by concise usage routing, sibling contrast, and side effects. Every sentence earns its place; the back-compat note is particularly valuable without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 18 parameters, a rich input schema, an output schema, and annotations, the description completes the picture by providing routing guidance, filter category summaries, and explicit read-only semantics. Nothing needed to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by grouping the 18 parameters into meaningful categories (status, priority, tags, text, time window, external link) and by flagging that single-value status/priority are back-compat, implying preference for the _in variants. This helps an agent navigate a large parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('List ledger items with rich filters, sort, and pagination'), and the sibling contrast explicitly names the nearby tools it is not — delimit_ledger_context and delimit_ledger_query. An agent can immediately distinguish this from similar ledger tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to use' and 'When NOT to use' sections, naming the alternatives (delimit_ledger_context for top-N summary, delimit_ledger_query for single item) and the conditions that select them. No inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already signal readOnlyHint=false and destructiveHint=true, the description adds valuable action-level behavior: 'add'/'remove' write config while 'list'/'detect' are read-only. It also discloses the premium prerequisite and the exact unlicensed error behavior, exceeding what the annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections (When to use, When NOT to use, Sibling contrast, Side effects, Prerequisite). Every section carries distinct information with no fluff, and the most important purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the mixed read/write behavior, the action-dependent side effects, the premium gating, and the presence of an output schema, the description covers everything an agent needs: what it does, when to use it, what side effects to expect, and how licensing failures behave. No material gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters and their roles. The description adds action-level side-effect context, but does not add new per-parameter semantics beyond the schema. A baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pairing: 'View and configure AI models for multi-model deliberation.' It then explicitly contrasts itself with delimit_deliberate: 'this manages which models the panel can call,' making differentiation from the key sibling immediate and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use scenarios (inventory providers, auto-detect keys, register/remove providers), explicit when-not-to-use scenarios (running deliberation, inspecting history), and points to the correct sibling tool. The sibling contrast sentence further reinforces routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite the annotations being minimal (readOnlyHint=false, destructiveHint=false), the description discloses the key side effect: it sends a network message via webhook JSON POST, Slack, or SMTP. It also explains the downstream founder-reply loop, the auto-trigger requirement, and content expectations. This goes well beyond what the annotations or schema alone convey, and there is no contradiction with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized with labeled sections and front-loading of the core action. There is some redundancy, such as repeating the founder-reply loop and channel listing, but the repetition reinforces genuinely important behavioral requirements. The structure makes it easy for an agent to scan and extract key rules.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 11 parameters and optional draft-related behaviors, the description covers the critical usage context, exclusions, side effects, and content formatting rules well. The output schema exists, so the description need not explain return values. It falls just short of a 5 because some operational details, such as how draft_kind interacts with the local SQLite registry, are only in the schema rather than the main description, though the schema does document them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful behavior beyond the schema by specifying email subject and body rules, including [ACTION TYPE] prefixes and the need for self-contained actionable content. However, several parameters like draft_target, draft_payload, and from_account are not elaborated in the prose description, though the schema covers them adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Send a notification (webhook / Slack / email).' It clearly differentiates itself from siblings by stating that delimit_notify_routing configures rules, delimit_notify_inbox reads inbound messages, and this tool sends one outbound notification. This makes the tool's role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use conditions ('requires owner action — outreach reply, deployment decision, approval needed'), an explicit when-not-to-use section with alternative tools (delimit_siem, delimit_notify_routing), and a mandatory auto-trigger rule instructing the agent to call immediately without asking. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that the operation is read-only on the OS backend, is gated by require_premium, and calls backends.os_bridge.check_gates. This adds meaningful behavioral context such as authorization requirements and backend coupling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently organized with clear sections: core purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence contributes useful decision-making information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations cover read-only/idempotent behavior, the schema covers the sole parameter, the output schema exists, and the description provides usage guidance plus authorization and side-effect context, the tool definition is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter is 100%, so the schema already documents plan_id. The description adds minimal semantic value beyond noting it checks a 'specific plan,' which is sufficient given the complete schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Check governance gates for an OS plan (Pro).' It clearly distinguishes the tool from siblings by noting it 'returns gate state for one plan' versus aggregate counts or engine health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use ('to check whether a specific plan is currently blocked by a governance gate before proceeding'), when-not-to-use, and names the specific alternatives (delimit_os_status, delimit_gov_health). This leaves 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful side effects beyond the annotations: reads ledger and network state, writes new intel-class LEDs, dispatches new substantive tasks, and honors DELIMIT_GITHUB_OUTREACH_DISABLED and ~/.delimit/outreach_pause as kill switches. Annotations only say readOnlyHint=false and destructiveHint=false, so this behavioral detail is valuable and consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: one-line summary, when-to-use, when-not-to-use, sibling contrast, and side effects. Every sentence carries distinct information, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with side effects and scheduling context, this description is complete. It covers invocation context, exclusions, sibling differentiation, side effects, and kill switches. The presence of an output schema means return-value details are not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter documentation with descriptions for venture, max_monitor, and max_dispatch. The description adds context about per-tick caps being intentional and the pattern of multiple ticks, but it does not add much parameter-specific meaning beyond what the schema already supplies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run one tick of the autonomous github-outreach loop.' It distinguishes itself from siblings by explicitly noting it is github-only, orchestrates over every open outreach LED, and uses the substantive-outreach path, unlike delimit_social_target and delimit_sensor_github_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states exactly when to use it (external scheduler, loop_daemon, or ad-hoc manual cycle) and when not to use it (backfill for thousands of stale items), even explaining the right pattern: multiple ticks at the scheduler interval. It names specific sibling alternatives and how they differ.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses concrete side effects: action='init' writes a new delimit.yml at project_path, while 'load' and 'model' are read-only. This goes beyond the annotations and clarifies the mixed read/write nature of the tool, which is essential for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, front-loads the core purpose, and every sentence adds useful guidance. It is compact despite covering usage, exclusions, sibling contrast, and side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's multi-action nature and conditional parameters, the description provides complete context: what the tool manages, when to use it, when not to, how it differs from the closest sibling, and what side effects to expect. An output schema exists, so return-value documentation is not required here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema: it confirms that 'init' writes to project_path and lists the modes, but the schema already documents parameter-specific constraints like 'only for init' and 'only for action=model'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Manage delimit.yml project configuration (load / init / model).' It names the exact file and modes of operation, and the sibling contrast explicitly distinguishes it from delimit_gov_status, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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_gov_status and delimit_playbook as alternatives for governance state and prompt management. This fully routes the 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations provide readOnlyHint=false and destructiveHint=false, the description goes beyond them by disclosing that action='record' writes to ai.prompt_drift.record_result, while 'check' and 'rank' are read-only. This is critical operational context an agent cannot derive from the structured fields alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and sectioned for scannability. Every sentence earns its place: purpose, usage, sibling contrast, and side effects are all covered without digression or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six optional parameters, an output schema, and clear annotations, the description provides the essential context: what drift tracking means, when to use it, when not to, how it differs from a related sibling, and which actions have side effects. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to re-explain each parameter. It adds some contextual meaning around the action parameter via side-effect information, but does not materially enrich the semantics of the individual parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Detect prompt drift across Claude / Codex / Gemini for the same task.' It clearly distinguishes itself from delimit_deliberate by noting deliberation is cross-model, whereas this tool tracks single-model drift.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 alternative delimit_deliberate and the condition that makes it inappropriate. The sibling contrast reinforces the routing decision with a concrete difference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses read-only network access via residential proxy, a 1 req/2sec rate limit, and a mandatory tool-chaining rule after scanning. This adds substantive behavioral context that annotations alone 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the core purpose appears first, followed by usage guidance, side effects, and the chaining rule. Every section earns its place and the text is dense without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is fully contextualized for an agent: clear purpose, explicit alternative routing, side-effect disclosures, rate limiting, and a mandatory follow-up chain. With an output schema present and annotations covering safety, nothing essential is missing for correct invocation and follow-through.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the sort and limit parameters. The description does not add new parameter-level semantics, but this is acceptable because the baseline of 3 applies when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: bulk scanning 25+ subreddits for outreach targets. It further distinguishes itself by stating it is venture-agnostic and returns ranked, categorized targets, which clearly separates it from sibling tools like delimit_social_target and delimit_reddit_fetch_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, names the alternative tools by name, and includes a sibling contrast section. An agent can confidently route to this tool versus the alternatives without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 valuable behavioral context beyond this: it states the call is read-only on git/repo state, gated by require_premium, invokes backends.tools_infra.release_plan, and returns an upgrade error without running when unlicensed. This is rich, concrete 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections, zero filler, and the core purpose front-loaded. Each sentence earns its place: purpose, usage, exclusions, sibling contrast, side effects, backend call, and prerequisite. The formatting makes it easy for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, all parameters are documented, and annotations cover safety, the description is fully complete for correct selection and invocation. It covers when to use, when not to use, the sibling distinction, side effects, backend call, and licensing prerequisite. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds context about surfacing the version to bump and multi-service release planning, but it does not need to explain individual parameters. Baseline 3 is appropriate because the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate a release plan from git history.' It clarifies the output is a multi-service release plan and explicitly contrasts with delimit_deploy_plan, so an agent can distinguish it from a similarly named sibling 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.
Usage Guidelines5/5
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_release_validate and delimit_deploy_publish as alternatives. It also contrasts with delimit_deploy_plan, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description clearly discloses the conditional side-effect behavior: no side effects on success, but on failure it auto-chains three specific actions (evidence collection, notification, ledger item). This is significant behavioral context the agent needs before invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every section adds distinct value, and the most important usage guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, the description does not need to explain return values. It covers purpose, usage boundaries, sibling differentiation, and side effects, which are the critical elements for correct invocation. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters version and environment are already fully documented in the input schema. The description adds no additional parameter-level detail, which is acceptable but not above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Validate that a release is safe to ship.' It explicitly distinguishes itself from delimit_release_plan, delimit_lint, and delimit_obs_status, making the tool's role clear relative to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use ('gate between delimit_release_plan and the actual rollout'), when-not-to-use (OpenAPI linting, runtime health), and a sibling contrast with delimit_release_plan. This leaves 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly/idempotent/non-destructive, and the description adds meaningful context: gated by require_premium, explicitly 'read-only on the repo', experimental output schema, and backend call name. The description is fully consistent with the annotations and adds non-redundant behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense: purpose, usage windows, exclusions, sibling contrast, side effects, gating, and experimental status are all covered in a few short labeled segments. No filler or tautology is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter, output-schema-backed tool with rich annotations, the description covers everything an agent needs to select and invoke it correctly: what it does, when to use it, when not to, safety profile, and access requirements. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'target' is already fully documented in the schema at 100% coverage, including default '.'. The description does not need to add more parameter detail, so baseline 3 applies. No contradiction or gap exists here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Diagnose repository health issues', and clarifies it is a 'quick health-check pass'. It explicitly contrasts with the deeper structural audit of delimit_repo_analyze, 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete trigger ('before a commit or push') and lists examples of detected problems. It also names when NOT to use it, pointing to delimit_repo_analyze and delimit_repo_config_validate as alternatives. This is explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by stating the underlying call (ai.data_plane.list_drivers) and clarifying the return shape, which goes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured with clear sections, front-loaded purpose, and no filler. Every section earns its place: when to use, when not to use, sibling contrast, side effects, args, and returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only inventory tool, the description is complete: it explains what the tool returns, how it differs from siblings, and what side effects to expect. The presence of an output schema also reduces the need to document return values further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics burden. The description explicitly states 'Args: None', which is consistent with the empty input schema and gives the agent certainty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List available data plane drivers and their resource schemas.' It also explicitly contrasts with sibling tools delimit_resource_list and delimit_resource_get, making it unambiguous which tool is which.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit 'When to use', 'When NOT to use', and names the exact alternative tools for reading data. This is ideal routing guidance for an agent deciding among many delimit_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses the side effect of read-only network calls, names the internal calls to ai.data_plane.get_driver and the driver's list_* method, and confirms no destructive behavior. This gives an agent a clear model of what executing the tool involves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose followed by tightly scoped sections for usage, contrast, and side effects. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is self-sufficient for selection and invocation: purpose, alternatives, side effects, and internal behavior are all covered. Parameter details and return shape are delegated to the input/output schemas, which is appropriate given the schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all six parameters with descriptions, so the description does not need to restate parameter semantics. It adds general context about driver-based enumeration but no parameter-specific detail beyond the schema. The baseline of 3 applies because schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List resources from a connected data-plane system' and clarifies that it enumerates items like repos, PRs, issues, and workflow runs. It distinguishes itself from peers by naming delimit_resource_get and delimit_resource_drivers as different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, including named alternatives. This leaves no ambiguity about when to choose this tool over delimit_resource_get or delimit_resource_drivers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects beyond the annotations: it appends an access log entry via ai.secrets_broker.get_secret and does not return secrets to scopes unauthorized at store time. This is valuable behavioral context that the readOnlyHint=false and destructiveHint=false annotations alone do not provide, and it does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence contributes actionable information, and the most important details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with an output schema present, the description is complete. It covers purpose, usage boundaries, side effects, and authorization scope, so an agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters. The description adds the conceptual framing of just-in-time scope checking, but it does not add parameter-level meaning beyond what the schema provides. The baseline of 3 is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Request just-in-time access to a stored secret.' It also explicitly contrasts with delimit_secret_store and delimit_secret_access_log, so an agent can distinguish it from sibling tools without needing to inspect their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states exactly when to use the tool ('when a tool or agent needs a credential at execution time') and when NOT to use it, naming the alternatives: delimit_secret_store for adding secrets and delimit_secret_access_log for examining audit logs. This gives the agent explicit routing criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 meaningful behavioral context beyond that: it emphasizes that secret values are never exposed, states side effects as read-only, and reveals the underlying call to ai.secrets_broker.list_secrets. This is strong but not exhaustive; a 4 reflects solid added value without needing to over-credit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: core purpose first, then usage guidance, sibling contrast, side effects, args, and returns. Every section earns its place and is concise; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, zero-parameter tool with an output schema, this description is complete. It explains what the tool returns, confirms there are no arguments, clarifies side effects, and gives enough selection guidance against relevant siblings. Nothing an agent needs 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description explicitly states 'Args: None,' which aligns with the empty input schema. With no parameters to document, the schema and description together fully disambiguate invocation requirements. The baseline for zero-parameter tools is 4, and nothing else is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'List secrets in the broker' and immediately clarifies the scope with 'metadata only — never values.' It distinguishes itself from delimit_secret_get and delimit_secret_store, making the tool's purpose unmistakable even within a very 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to use' and 'When NOT to use' sections, names the exact alternative tools for retrieving values and storing secrets, and adds a sibling contrast explaining the audited versus metadata-only difference. 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, it discloses the exact side effect: writes a revocation record via ai.secrets_broker.revoke_secret, subsequent get calls denied, and access log preserved. This is richer than the annotation and clarifies what destructive means here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, then organized into labeled sections (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence carries distinct information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool, the description covers use cases, exclusions, sibling relationship, side effects, and downstream behavior. An output schema exists, so return-value documentation is not required here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is fully described in the schema ('Secret name to revoke. Required.'), so the description does not need to repeat it. It adds no extra format or behavior details beyond the schema, matching the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource ('Revoke a secret to prevent any future access') and explicitly contrasts with delimit_secret_store ('creates; this disables'), which distinguishes it from the closest sibling. An agent knows exactly what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use conditions ('after a credential leak or when rotating away from an old secret name') and a when-NOT-to-use condition ('to delete metadata only') with a concrete consequence (blocks delimit_secret_get). It also names the creating sibling as the alternative, 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.
Behavior5/5
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: it calls multiple models via the deliberation panel and updates ledger items with triage verdicts. It also explains the Pro prerequisite and the exact unlicensed-call error behavior, which is valuable operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with clear labeled sections (When to use, When NOT to use, Sibling contrast, Side effects, Prerequisite) and no filler. Each sentence adds distinct value, from routing to side effects to failure behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no required parameters and an existing output schema, the description covers the pipeline context, safety/mutation effects, licensing constraint, and error behavior. An agent has enough to decide when to invoke it and what to expect from an unlicensed call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents repo, focus, and findings fully. The description does not add parameter-specific detail beyond the schema, which matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb phrase, 'Multi-model triage of security findings', and enumerates the classification outcomes (real risk / false positive / accepted risk / needs immediate action), so an agent knows exactly what the tool accomplishes. It also distinguishes the tool from delimit_security_ingest, delimit_security_scan, and delimit_deliberate, making it unambiguous among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 state the prerequisite pipeline step (after delimit_security_ingest) and route ingest and scan tasks to the correct siblings. The sibling contrast with delimit_deliberate further clarifies which variant to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces this by stating 'read-only network call via gh CLI.' It adds valuable context beyond the annotations: the regex repo-format validation (defense-in-depth) and the confused-deputy guard (_check_repo_allowlist) that can block the call before fetching. This is genuinely useful failure-mode disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and efficiently organized: one-line purpose, then labeled sections for when-to-use, when-not-to-use, sibling contrast, and side effects. Every sentence earns its place and the most decision-critical information (purpose, exclusions) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a monitored-read tool. An output schema exists to document return values, annotations cover the safety profile, and the description covers usage boundaries, side effects, validation behavior, and the allowlist guard. Nothing an agent needs to call or route this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's 'since the last sensor tick' framing gives conceptual meaning to since_comment_id (incremental monitoring), but it does not add concrete parameter-level detail beyond what the schema already documents for repo, issue_number, or since_comment_id. The schema carries the weight here, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope construction: 'Check a GitHub issue for new comments since the last sensor tick.' It names both alternatives it is not (delimit_github_scan for repo-wide scans, delimit_resource_get for one-shot fetch), making sibling differentiation explicit and immediate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 with concrete alternative tool names and the conditions that select them. Also adds a sibling contrast paragraph specifically distinguishing this tool from delimit_github_scan. No inference is required by the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds meaningful behavioral context: it is read-only via the GitHub API, enforces a per-repo allowlist with the LED-881 confused-deputy guard, refuses non-allowlisted repos, and calls ai.social_target.scan_github_migrations. This goes well beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with scannable sections: a front-loaded purpose sentence, explicit usage guidance, sibling contrast, and side effects. Every section earns its place and adds actionable context without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a high-coverage schema, an output schema, and only two parameters, the description is fully complete. It covers purpose, usage boundaries, sibling differentiation, side effects, allowlist constraints, and internal delegation, so an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents the repos and limit parameters fully. The description mentions scanning target repos and migration signals, but it does not add parameter-level detail beyond what the schema provides. Baseline 3 is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, resource, and scope: 'Scan GitHub issues/PRs for migration patterns across target repos.' It further distinguishes itself from sibling tools by name, so an agent can tell it apart from delimit_sensor_github_issue, delimit_github_scan, and delimit_sense 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.
Usage Guidelines5/5
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' conditions, including named alternatives such as delimit_sense, delimit_sensor_github_issue, and delimit_github_scan. This gives clear routing guidance and leaves 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses action-dependent side effects: configure/forward/test write to SIEM endpoints via network calls, while status is read-only. This adds behavior beyond the readOnlyHint=false annotation and gives the agent a clear safety/impact model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses labeled sections for use, exclusion, sibling contrast, and side effects. It is compact with no redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the rich schema descriptions for all 5 optional parameters, and the annotations, the description covers purpose, exclusions, alternative tools, and side effects. Nothing critical for an agent to select and invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter is already documented in the input schema. The description reinforces that actions have side effects but does not add new parameter-level semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: managing SIEM streaming for audit-event forwarding, naming Splunk/Datadog/EventBridge/webhooks. It also differentiates itself from delimit_notify and delimit_notify_inbox, so an agent can distinguish it from nearby siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit 'When to use' and 'When NOT to use' guidance with named alternatives (delimit_notify for one-shot notifications, delimit_notify_inbox for inbox handling). The sibling contrast further clarifies when this tool is the right choice: structured-log streaming vs human notifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds meaningful context beyond that: 'Calls ai.social.list_twitter_accounts, which scans ~/.delimit/secrets/twitter-<handle>.json files.' This discloses the data source and underlying implementation, letting the agent infer scope (only locally configured accounts) and potential failure modes (missing secret files). It doesn't dwell on edge cases, but it adds real value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses labeled sections (When to use, When NOT to use, Sibling contrast, Side effects, Args, Returns) that make it scannable and every section earns its place. The opening line states the core purpose, and nothing is redundant or padded. This is an exemplary structure for an MCP tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description covers everything an agent needs: purpose, usage timing, sibling routing, side effects, underlying data source, the fact that there are no arguments, and the return shape ('Dict with accounts list and count plus next_steps'). The output schema exists and the description confirms the return format. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which carries a baseline of 4 per the rubric. The description explicitly states 'Args: None,' which is genuinely useful — it prevents an agent from hallucinating optional parameters like a platform filter or handle argument that the tool does not accept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'List configured social media accounts' — and then explicitly differentiates itself from siblings: 'delimit_social_generate drafts; delimit_social_post publishes; this lists who can publish.' An agent can immediately tell exactly what this tool does and how it differs from its direct siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 ('to inventory which Twitter/X accounts have credentials available before drafting or scheduling a post') and a 'When NOT to use' section naming the exact alternatives (delimit_social_generate for drafting, delimit_social_post for publishing). This is textbook usage guidance — the condition and the routing are both explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing action-dependent side effects: approve performs a network write, reject discards the draft, and list is read-only. This is especially valuable because the tool-level annotations (readOnlyHint=false, destructiveHint=false) cannot express per-action behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, well-organized, and front-loaded with the core purpose before structured guidance sections. Each sentence earns its place: when to use, when not to use, sibling contrast, and side effects. The minor repetition about delimit_social_post reinforces rather than bloats the message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with mixed read/write/discard actions, the description covers all essential contexts: queue origin, alternative tools, per-action side effects, and the source of the required draft_id. Because an output schema exists, the absence of return-value details is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters, including that draft_id is required for approve/reject and is returned by delimit_social_post(draft=True). The tool description adds little parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-plus-resource statement: 'Manage social media drafts — list, approve, reject'. It enumerates the exact operations, making the tool's scope immediately clear. It also distinguishes itself from siblings by explicitly contrasting with delimit_social_post, which creates the drafts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance ('to clear the social drafts queue created by delimit_social_post(draft=True)') and when-not-to-use guidance by naming delimit_social_post and delimit_social_history as alternatives. This leaves no ambiguity about when the agent should select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the sparse annotations, the description discloses default read-only behavior, conditional writes to an internal backlog, delegation to delimit_social_post and delimit_ledger_add, deduplication, platform API limitations, and explicit 'NOT outbound' constraints. It fully informs the agent of side effects and policy boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is well-structured and front-loaded, but it is quite long and repeats the demand_signal preference and sibling comparisons in multiple places. Most content is valuable, but tighter editing would improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8-parameter surface, output schema presence, and complex policy context, the description covers modes, platform coverage, side effects, dedup behavior, and operating model thoroughly. Nothing an agent needs to call this safely and correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra value by explaining the behavioral significance of mode='demand_signal' and the side effects of draft_replies and create_ledger, going beyond the schema's field-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Scan platforms for demand signals / engagement opportunities.' It clearly distinguishes the two modes and contrasts the tool with delimit_x_fetch and delimit_social_target_config, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance for both modes, explicitly states when NOT to use the tool, names the alternatives to use instead, and adds a policy directive to prefer demand_signal mode. This is exemplary routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavior context: it notes the tool is read-only, calls backends.gateway_core.run_spec_health, and supports any valid OpenAPI 3.x or Swagger 2.0 spec, which goes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with distinct sections for purpose, usage, exclusions, sibling contrast, and side effects. It is front-loaded with the core behavior and contains no redundant or filler content; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage criteria, exclusions, alternatives, side effects, internal backend call, and supported spec versions. With an output schema present and annotations covering safety, nothing essential is missing for an agent to select and call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the single 'spec' parameter. The description adds meaning by defining what 'valid spec' means — OpenAPI 3.x or Swagger 2.0 — which helps clarify acceptable input values beyond the schema's 'Path to an OpenAPI spec file'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Score an OpenAPI spec on quality dimensions (0-100, A-F grade).' It clearly distinguishes this tool from delimit_lint by explaining that delimit_lint compares two specs while this one scores a single spec on its own merits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 ('quick spec quality checks during onboarding or review') and when NOT to use it, naming delimit_lint for breaking-change gates and delimit_diff for raw diffs. This gives an agent clear routing guidance among nearby siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by disclosing concrete side effects: writes status to the ledger, updates session metrics (cost, errors), and returns the next task. It also explains the loop-continuation semantics, which is important behavioral context not available from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headers, front-loads the core purpose, and every sentence earns its place. It is concise but information-dense, covering usage, exclusions, sibling contrast, and side effects without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, existing annotations, and presence of an output schema, the description covers all essential decision points: when to call, when not to call, what side effects occur, and how the loop progresses. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds context about task_id being the 'current loop task' but does not need to explain each parameter further; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Mark current loop task done and get the next one.' It also explicitly contrasts itself with delimit_ledger_done and delimit_next_task, making the tool's unique role immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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_ledger_done, delimit_next_task) and the condition that selects this tool. This leaves no ambiguity for an agent deciding between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing that it invokes the project's test runner via backends.ui_bridge.test_smoke as a subprocess, and that it is read-only on the filesystem apart from the test runner's own outputs. This adds meaningful operational context that the annotations do not fully convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for use cases, non-use cases, sibling contrast, and side effects. Each section earns its place 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage timing, alternatives, framework detection, side effects, and filesystem impact. With an output schema present and all parameters fully described in the schema, nothing essential is missing for an agent 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.
Parameters3/5
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 and their defaults. The description adds general context like framework auto-detection but does not add much per-parameter meaning beyond what the schema provides, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run smoke tests for a project.' It further differentiates from siblings by stating delimit_test_generate writes, delimit_test_coverage measures, and this tool 'runs and parses,' leaving no ambiguity about its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: 'as a pre-commit / pre-deploy gate to confirm tests pass.' It also includes clear when-not-to-use instructions with named alternatives for scaffolding tests and measuring coverage, making the routing decision unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only say readOnlyHint=false and destructiveHint=false, but the description adds important nuance: it is read-only on GitHub, makes network calls via gh CLI, writes context entries into the ledger, and does not push back. This precisely clarifies the mixed read/write behavior beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into clear labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence adds useful information, and the structure makes it easy for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage, an output schema, and clear annotations, the description fully covers the behavioral and selection context. It explains side effects, sibling differentiation, and usage boundaries, leaving no critical gap for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents repo, limit, and labels with defaults and examples. The description does not add parameter-level detail, but it does not need to because the schema carries the burden effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Pull open GitHub issues into the Delimit ledger as context.' It clearly identifies what the tool does and distinguishes it from the sibling delimit_sensor_github_issue, which watches a single issue rather than syncing many.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it ('to enrich the ledger with external issue context'), when NOT to use it ('to write back to GitHub' or 'to monitor a single issue'), and names the alternative tool. This gives an agent unambiguous routing logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds value by disclosing the underlying implementation call (ai.ledger_manager.list_ventures) and the data-provenance mechanism (auto-registration when any Delimit tool runs in a project directory). 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.
Conciseness5/5
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, Args, Returns). Front-loaded with a one-sentence purpose, and every section contributes non-redundant information. The 'Side effects' and 'Note' lines are economical and earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only list tool with full annotation coverage and an output schema, the description is complete: purpose, routing guidance, side effects, data provenance, args, and return shape are all covered. The only absent details (ordering, staleness) are negligible for a simple inventory tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the description explicitly states 'Args: None,' confirming the empty schema. Per the baseline for 0-param tools, no parameter documentation is needed; the description even goes beyond by outlining the return shape ('Dict with the venture list (each entry has name, path, etc.)').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource statement: 'List all registered ventures (auto-registered project directories).' The parenthetical defines the key term, and the sibling contrast ('delimit_context_list inventories artifacts inside one venture; this lists the ventures themselves') explicitly distinguishes it from the closest sibling without requiring the agent to open either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 that name the alternatives (delimit_context_list, delimit_memory_recent) and the routing condition ('before routing a ledger query or context operation'). The sibling contrast reinforces the 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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing local git mutation plus a network Vercel deploy, pre-validation of the Vercel binding, timeout behavior returning status=pending with an SHA, the absence of rollback, and the staged_only safety semantics. It also correctly aligns with destructiveHint=true and readOnlyHint=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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections and front-loaded purpose, but it repeats the ChatOps env-var injection detail in two separate paragraphs and is somewhat longer than necessary. Minor trimming would make it more concise while preserving all the valuable context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, network-triggering 7-parameter tool, the description covers prerequisites, when-not-to-use, side effects, timeout fallback behavior, and the rollback alternative. Since an output schema exists, the return-value details do not need to be restated here, making this description complete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the description adds meaningful constraints: repo_path must be an explicit worktree root, project_path must remain inside repo_path, and staged_only=false requires explicit paths and never uses git add -A. This adds value beyond the schema, though some parameter-specific details are still left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a concrete action ('Ship a static / Next.js site via git push to the Vercel pipeline') and the sibling contrast explicitly distinguishes it from delimit_deploy_publish and delimit_deploy_npm. This gives the agent an unambiguous model of what the tool does and how it differs from nearby deploy tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contains explicit 'When to use' and 'When NOT to use' sections, names the correct siblings for npm, container, and rollback flows, and tells the agent to pair with delimit_deploy_verify on the resulting URL. This leaves 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the destructiveHint annotation by disclosing precise side effects: writes exactly ONE file under target/, path sanitization that short-circuits on escape, feature-string coercion, absence of license/ledger/notification side effects, and the critical overwrite-or-error ambiguity on existing files. For a destructive tool, this is exactly the behavioral disclosure an agent needs before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections (When to use, When NOT to use, Sibling contrast, Side effects) and front-loads the core purpose. It is verbose, and the sibling contrast section partially restates the when-not-to-use routing, but for a destructive multi-parameter tool the density of information justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Everything an agent needs before invoking a 5-parameter file-writing tool is present: purpose, routing conditions, side effects, overwrite risk, internal behavior details, and what it does NOT do. The output schema covers return values, so no description burden there. The only conceivable addition would be an example, which is not required for correctness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 with the schema doing the heavy lifting. The description adds genuine value by revealing two parameters' runtime behavior: target undergoes _sanitize_path with workspace-escape errors, and features is coerced from comma string to list. This is non-obvious information an agent couldn't infer from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line states a specific verb-resource pair ('Write a single file from a code template into an existing project') that immediately distinguishes it from bulk-generation or design-token tools. The sibling contrast confirms the exact boundaries: scaffold writes a full tree, design consumes tokens, test writes tests — leaving no ambiguity about 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.
Usage Guidelines5/5
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 alternatives (delimit_generate_scaffold, delimit_design_generate_component, delimit_test_generate) and the conditions that select them. It even handles the bulk-generation edge case by instructing one call per file. 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects ('read-only network') and, importantly, the mandatory chaining behavior: high-score findings must be auto-ledgered via delimit_ledger_add and pain threads notified via delimit_notify. It even warns 'Never just return findings and stop.' This goes well beyond the sparse annotations and gives the agent critical operational context. While readOnlyHint is false in annotations, the description's 'read-only network' refers to network side effects, and the chain rule clarifies downstream mutations happen via separate tools, so there is no direct contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well-structured with clear headers and front-loaded purpose. Every section earns its place: cadence usage, sibling contrast, side effects, and chaining rule. Minor redundancy exists in the chain rule section ('Never just return findings and stop' restates the earlier rule), but overall it remains efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 2 parameters with 100% schema coverage, an existing output schema, and a detailed description covering cadences, sibling distinctions, side effects, and mandatory downstream actions, nothing essential is missing. An agent has enough information to select, invoke, and follow up on this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds real semantic value beyond the schema by explaining each cadence option: 'pulse (own repo health), hunter (engagement signals, hourly), deep (full ecosystem, daily).' It does not restate limit, but the schema already documents the default and max, so the description does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Scan GitHub for adoption leads, competitive intel, repo health (Pro).' It clearly states what the tool does and distinguishes itself from siblings: 'delimit_sensor_github_issue is single-issue; delimit_tracker_sync ingests issues to ledger; this is the broad GitHub corpus scanner.' An agent can immediately tell this apart 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance by cadence: 'pulse (own repo health), hunter (engagement signals, hourly), deep (full ecosystem, daily).' It also provides a direct when-NOT-to-use section with named alternatives: 'use delimit_sensor_github_issue or delimit_tracker_sync.' 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal, so the description carries the full burden of behavioral disclosure. It clearly lists side effects: creates .delimit/policies.yml, ledger directory, chmod 755/600 changes, and optional .claude/settings.json writes. It also discloses that permission configuration can be skipped with no_permissions=True, giving the agent a complete picture of the tool's footprint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear 'When to use', 'When NOT to use', and 'Side effects' sections, and the most important information is front-loaded. There is minor redundancy: the creation of .delimit/policies.yml and ledger directory appears in both the 'When to use' paragraph and the 'Side effects' section, but this is a small cost for the clarity gained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters and meaningful side effects, the description is complete: it names prerequisites, alternatives, exact filesystem effects, permission behavior, and how to opt out of the permission step. Because an output schema exists, no return-value explanation is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful meaning by tying no_permissions to the permission step and to the optional .claude/settings.json allowlist, which goes slightly beyond the schema's short parameter description. Preset and project_path rely on the schema, which is acceptable given full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Initialize Delimit governance scaffolding for a project.' It also contrasts itself with delimit_project_config ('manages the config after init') and delimit_scan ('inspects what could be governed'), making it easy for an agent to distinguish this one-time initializer from nearby siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: 'When to use: once per project, the first time you adopt Delimit' and 'When NOT to use' names both the alternative tools and the conditions that route to them. This leaves no ambiguity about when the tool is the correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnlyHint and idempotentHint, and the description adds important behavioral context beyond them: the call is gated by require_premium, unlicensed calls return an upgrade error without executing, and it invokes backends.os_bridge.get_status. This fully discloses 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with labeled sections and front-loads the core purpose. It is slightly longer than strictly necessary because the sibling contrast partially repeats the when-not-to-use guidance and the backend call detail is extra, but every section is still informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema, the description covers everything an agent needs: purpose, usage timing, alternatives, exclusions, side effects, license prerequisite, failure behavior, and return type. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is nothing to document. The description explicitly states 'Args: None', which is correct and sufficient. Baseline 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Report overall Delimit platform status (plans, tasks, tokens)'. It also explicitly differentiates this tool from delimit_gov_health and delimit_os_gates, so an agent can distinguish it from the most confusable siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to use' (session start/status dashboard) and 'When NOT to use' conditions with named alternatives (delimit_gov_health, delimit_os_gates). This is direct, actionable routing guidance that removes ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint=false and destructiveHint=true, the description adds precise side effects: save/delete mutate the specific path ~/.delimit/playbooks/, run calls the configured model (a non-obvious external effect with cost implications), and list is explicitly read-only. This contextualizes the annotation flags rather than merely restating them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with the core purpose front-loaded, then compact labeled sections for routing and side effects. Every sentence earns its place; the minor overlap between 'When NOT to use' and 'Sibling contrast' is acceptable since one handles routing and the other conceptual differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, 4-action tool, the description covers purpose, routing, substitution mechanics, and per-action side effects, and the output schema handles return values. The only gap is that action-to-required-parameter mapping isn't spelled out in prose, but the schema documents this fully at 100% coverage, so the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the per-parameter baseline is 3. The description elevates this by explaining cross-parameter semantics the schema can't: how {{variable}} placeholders flow from save (template creation) to run (substitution), and how each action maps to side effects. Per-parameter detail is fully in the schema, so the description appropriately focuses on the interaction between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line 'Manage reusable prompt templates — save / run / list / delete' names a specific resource (prompt templates) and enumerates its four operations. The sibling contrast explicitly differentiates it from delimit_memory_store ('records info') and delimit_project_config, making it cleanly distinguishable from related tools without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 that name exact alternative tools (delimit_project_config for config, delimit_memory_store for memories) and the conditions that route to each. The sibling contrast adds a further conceptual distinction, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description goes further by disclosing the license gate, naming the internal endpoints (ai.release_sync.audit and ai.release_sync.get_release_config), and specifying the unlicensed response shape. This adds meaningful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections and front-loaded purpose. There is minor redundancy between the initial '(Pro)' marker and the later prerequisite line, but otherwise every section contributes useful information without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only audit tool with an output schema and comprehensive annotations, the description covers scope, exclusions, sibling distinction, licensing, side effects, and error behavior. Nothing an agent needs to decide whether to call this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the lone parameter's description already documents the 'audit' and 'config' values. The description adds extra meaning by mapping each action to a specific internal endpoint and reinforcing the default behavior, which helps the agent anticipate what happens for each value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Audit or report config of public surfaces for consistency.' It explicitly names the surfaces (CLI, action, npm, site) and contrasts with delimit_release_status, 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.
Usage Guidelines5/5
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, plus a direct sibling contrast: delimit_release_status reports deployed state, while this tool audits config drift. It also states the prerequisite (Delimit Pro) and the unlicensed error behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context: read-only on the resolved local path, remote inputs are shallow-cloned into a tempdir, and the underlying call path is disclosed. This goes well 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and front-loaded purpose. Every sentence contributes useful guidance, though the final implementation-detail sentence about backends.repo_bridge.analyze is slightly lower-value for an agent deciding whether to call the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, rich annotations, and an output schema, the description covers intent, usage boundaries, side effects, accepted input forms, and remote behavior. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the target parameter is already well documented. The description adds value by explaining the remote-clone behavior for non-local targets and reinforcing the accepted input formats. This is more than the baseline, though the schema already carries most of the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Analyze repository structure and quality,' and clarifies it is a 'deep audit' covering code structure, language mix, and quality signals. It also distinguishes itself from the sibling delimit_repo_diagnose, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, directly naming alternatives delimit_repo_diagnose and delimit_repo_config_audit. The sibling contrast further clarifies when this tool is the right choice versus a quick smoke test.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful context beyond this: read-only on the resolved local path, remote inputs are shallow-cloned into a tempdir, and it names the internal code path. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections and the core purpose front-loaded. The final sentence about internal backend calls is a marginal implementation detail, but it does not significantly harm readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, an output schema, and safety annotations, the description covers purpose, usage boundaries, sibling differentiation, side effects, and input semantics. No critical information for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single target parameter, so the baseline is 3. The description adds value by reinforcing accepted input forms (local path, owner/repo, GitHub URL) and explaining the behavioral difference for remote inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: 'Validate repository configuration files.' It clarifies that this checks structural validity and self-consistency, and explicitly contrasts itself with delimit_repo_config_audit and delimit_repo_analyze, so an agent can tell it apart from relevant siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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_repo_config_audit for compliance, delimit_repo_analyze for full repo analysis). The sibling contrast further removes ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (title only), so the description carries the full burden. It discloses per-action side effects, silent overwrites, no version history, revoke-not-delete behavior, read-only guarantees for list/access_log, audit-log behavior, scope enforcement at read time, cleartext return, filesystem trust boundary, and deterministic error handling. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is well-structured with clear sections and every section contributes necessary detail for a five-action dispatcher. It is slightly repetitive around the alias relationship and unified entry point, but the density of useful information justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — seven parameters, five actions, minimal annotations, and an output schema — the description covers everything an agent needs: storage location, access control model, audit behavior, side effects, limitations, error shape, and what each action returns. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by mapping parameters to actions: name is required for store/get/revoke but only filters access_log, scope is enforced at read time, value is never echoed, and action is case-insensitive. This enriches the parameter semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb-and-resource relationship: a unified secrets-broker entry point that dispatches to five named actions (store, get, list, revoke, access_log). It clearly distinguishes itself from the delimit_secret_* aliases and from the delimit_context_* / delimit_memory_* families, so an agent can 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is an explicit 'When to use' and 'When NOT to use' section. It names the preferred alternatives (delimit_secret_store, delimit_secret_get, etc.) and the condition that selects them, and it warns against using the broker as a general key/value store. This is unambiguous routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations, explaining that the call persists to an at-rest store, enforces scope on later reads, overwrites on re-store with no append-only history, has no network egress or ledger write, and records a WRITE event in the access log. This fully discloses side effects and gives the agent an accurate model of the operation's consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into clear labeled sections (When to use, When NOT to use, Sibling contrast, Side effects) and front-loads the core purpose. There is some redundancy between the 'When to use' section and the 'Sibling contrast' paragraph, but every section still adds useful decision-relevant content, and the length is appropriate for a credential-writing tool with side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to document return values. It covers purpose, usage boundaries, sibling routing, parameter behavior, side effects, persistence semantics, and audit implications. An agent has everything needed to decide when to call this tool and what to expect from invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all four parameters at 100%, so no parameter documentation burden falls on the description. The description still adds useful meaning by emphasizing that 'value' holds the actual credential, that 'name' acts as the key subject to overwrite on re-store, and that 'scope' is persisted and enforced on subsequent delimit_secret_get calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Write a credential into the Delimit secrets broker store.' It clearly distinguishes this write tool from its siblings by naming what each sibling does, e.g., delimit_secret_get reads, delimit_secret_list shows metadata only, and delimit_secret_revoke disables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
This is exemplary: it provides explicit 'When to use' context, a typical pairing pattern with delimit_secret_get, and a thorough 'When NOT to use' list naming each alternative tool. It even warns against using the broker as a general-purpose key/value store, which an agent otherwise might assume.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the sparse annotations (readOnlyHint=false, destructiveHint=false) by disclosing concrete side effects: always writes an evidence bundle (best-effort), and on critical findings creates a governance task and sends a webhook notification. It also reveals the LED-1278 default behavior (skipping test dirs, suppressing dummy values) and the optional SNYK_TOKEN/Trivy enhancement. No contradiction with annotations — readOnlyHint=false correctly matches the disclosed 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but earns its length with clear section headers (When to use, When NOT to use, Sibling contrast, Side effects) and front-loading of the core purpose. Minor redundancy exists between the 'When NOT to use' list and the 'Sibling contrast' paragraph, but the structure keeps it scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with side effects and a deploy-gate role, the description covers everything needed for correct invocation: purpose, routing, default behavior quirks, side-effect conditions, and optional environment enhancements. The output schema exists, so return-value documentation is already covered by structured data, and the two parameters are fully described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the LED-1278 rationale for include_tests and giving guidance on when passing include_tests=True is legitimate (repos shipping real secrets in fixtures). This contextualizes both parameters beyond their raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource and the defining differentiator: 'Audit security and auto-chain evidence + governance on critical findings.' It enumerates the concrete checks performed (dependency scanning, secret detection, dangerous-pattern checks, .env-in-git) and explicitly contrasts with siblings, so an agent can identify it immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Has dedicated 'When to use' and 'When NOT to use' sections that name exact alternatives (delimit_security_scan, delimit_security_ingest, delimit_security_deliberate) and the conditions that select each. The sibling-contrast paragraph reinforces the routing decision. This is the ideal level of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=false and idempotentHint=true, and description adds matching detail: start/stop mutate state, idempotent start, circuit-breakered stop, environment-pause behavior, and mode chaining. It also mentions config path. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well structured with labeled sections and front-loaded purpose; all sentences contribute, but it is denser/longer than strictly necessary and could be trimmed without losing key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a one-parameter control tool: covers when, when not, alternatives, side effects, env var, and config path; output schema exists so return values need no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers action with 100% coverage; description adds operational consequences for parameter values: start/stop mutate daemon state, idempotent start, circuit-breakered stop. This is beyond schema's 'begin polling'/'halt polling', though status output is only in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb+resource: control the self-repair watcher daemon, with explicit actions start/stop/inspect and object (KPI watcher emitting founder alerts on breaches). It distinguishes from siblings by naming delimit_daemon_status, inbox/social daemons and noting different processes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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; names alternative tools (delimit_daemon_status, delimit_inbox_daemon, delimit_social_daemon) and clarifies the sibling contrast. No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnlyHint=false and destructiveHint=false, which is generic. The description adds precise behavioral detail: actions 'update' and 'add_subreddits' write to the config, while 'status' and 'detect' are read-only. This is exactly the kind of side-effect transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, well-organized into labeled sections, and every sentence earns its place. It front-loads the core purpose before moving to usage, exclusions, sibling contrast, and side effects without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 optional parameters, full schema coverage, and an output schema, the description covers the essential decision points: when to use, when not to use, sibling relationships, and side effects. A small gap is that the 'detect' action's exact behavior is not elaborated, but the schema and output schema cover enough for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by mapping action values to behavior (write vs read-only) and clarifying the purpose of subreddit configuration. It does not fully describe every parameter interaction, but it meaningfully supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Configure social target scanning platforms' and elaborates with inspect/update platforms and add subreddits. It explicitly distinguishes this tool from delimit_social_target, which runs scans, so an agent can immediately tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('to inspect / update which platforms...'), when-not-to-use guidance ('to run a scan...'), and names the correct alternative tools. The sibling contrast line reinforces the routing decision without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) already signal this is a mutating operation, and the description goes well beyond them: it discloses premium gating (require_premium), the end-to-end pipeline stages (rate cap, source-fit pre-filter, generator, capability validator, fit floor, queue insert), and the subtle dry_run behavior where validators still run and the 24h rate cap is still consulted. This is rich behavioral context that materially changes how an agent should call the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses labeled sections (When to use, When NOT to use, Sibling contrast, Side effects) that make the content scannable, and the core purpose is front-loaded in the first sentence. It is slightly verbose — the internal task reference 'LED-1253' and the long pipeline enumeration could be trimmed — but every section earns its place with non-redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with an output schema, full schema coverage, and annotations present, the description covers everything an agent needs: purpose, selection criteria, exclusions, named alternatives, side effects, gating, and dry_run specifics. Return values are handled by the output schema, so the absence of that detail is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful value beyond the schema by clarifying that dry_run suppresses only the queue insert while still running validators and consulting the rate cap, and by flagging tweet_id as 'Required' — important guidance since the schema shows an empty default but the tool is useless without it. A minor mismatch exists between the schema's default '' and the description's 'Required', but the net guidance is helpful rather than misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb ('Draft'), resource (Delimit-POV riff), and source (specific X tweet), plus the concrete use case of vendor-news surfacing. It also explicitly contrasts with named siblings: 'delimit_x_fetch fetches; delimit_vendor_news_health inspects subsystem health; this drafts a riff into the queue.' An agent can distinguish this from its 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains dedicated 'When to use' and 'When NOT to use' sections that name exact alternatives: use delimit_x_fetch to fetch without drafting, and delimit_social_generate for general social drafting. The sibling contrast paragraph reinforces routing decisions. This is explicit, actionable guidance with nothing left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects per action: add/remove mutate ~/.delimit/webhooks.json, test sends a test notification, and list is read-only. This meaningfully supplements the annotations (readOnlyHint=false, destructiveHint=true) with operation-specific behavior and file-level impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into focused sections and front-loads the core purpose. There is minor redundancy between the 'When NOT to use' section and the 'Sibling contrast' paragraph, but overall every section earns its place and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full parameter documentation in the schema, an output schema present, and annotations provided, the description covers what remains: when to use, when not to use, side effects, and sibling differentiation. An agent has everything needed to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents url, action, and events. The description adds extra semantic value by tying actions to side effects and clarifying test behavior, which goes beyond a bare schema listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Manage webhook notifications for governance events') and immediately clarifies what registering a Slack/Discord/HTTP webhook does. It explicitly contrasts itself with delimit_siem and delimit_notify, so an agent can distinguish this tool from 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.
Usage Guidelines5/5
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_siem for streaming, delimit_notify for one-shot notifications). This gives clear decision rules and removes ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral context beyond those: it performs read-only static CSS analysis, may run a dynamic browser check if URL is provided, calls a backend bridge, and coerces check_types. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence contributes useful guidance, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with a full output schema and read-only annotations, the description covers the use case, exclusions, side effects, and a parameter conversion nuance. Nothing critical is missing for an agent to decide whether and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by disclosing that check_types is coerced from a comma string to a list via _coerce_list_arg, which affects how the agent can pass parameters. It reinforces the url-based dynamic testing behavior but does not enumerate all valid check_type values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Validate responsive design patterns via static CSS analysis and optional dynamic Playwright testing.' The sibling contrast explicitly distinguishes it from delimit_story_accessibility, so an agent can tell what this tool does 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states exactly when to use it ('as a CI check after editing UI/CSS'), when NOT to use it ('for accessibility audits' or 'component scaffolding'), and names the alternative tools. This is explicit 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing side effects: normal mode can fix configuration drift, writes a doctor-manifest.json for reversibility, dry_run=True is read-only, and undo=True reverts the last run. This is exactly the behavioral context an agent needs for a mutating diagnostic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence carries information, and the most important purpose statement is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with multiple modes and side effects, the description covers scope, alternatives, behavior, reversibility, and read-only mode. An output schema exists, so return-value documentation is not the description's responsibility. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds useful meaning by explaining that dry_run is read-only and previews changes, and that undo uses the saved manifest to revert. It does not add detail about project_path beyond the schema, but the schema already documents it clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Comprehensive health check of the Delimit installation (delimit doctor).' It also explicitly distinguishes itself from delimit_repo_diagnose, which checks one repo, so an agent can tell them apart immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit 'When to use' section naming the universal first-step diagnostic context, plus a 'When NOT to use' section naming two alternatives (delimit_repo_diagnose and delimit_quickstart). This gives clear decision rules with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses concrete side effects: action='run' writes markdown and JSON to ~/.delimit/digest/, email requires DELIMIT_DIGEST_EMAIL=true as a pipeline gate, and action='latest' is read-only. This is exactly the behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with clear sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence carries useful information, and the most important purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four optional parameters, a full input schema, an output schema, and rich annotations, the description covers all non-obvious runtime behavior: file writes, email gating, read-only actions, and route selection against sibling tools. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all four parameters at 100%, so the baseline is 3. The description adds meaningful semantics by explaining the action='run' vs 'latest' behavior, the email env gate, and the windowed-rollup nature that relates to window_hours. This pushes it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Generate a structured daily digest of loop activity') and explicitly contrasts it with delimit_notify and delimit_notify_inbox. This makes the tool's identity unmistakable even among a very large sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit 'When to use' and 'When NOT to use' guidance, names the exact alternative tools, and adds a sibling contrast sentence. An agent can reliably select this tool versus delimit_notify without further inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint=false and destructiveHint=false, the description adds substantial behavioral context: it reveals that live run/poll actions fire whitelisted GitHub side effects, that every invocation is logged, that touching a pause file halts execution, and that unlicensed calls return an error without running. This goes well 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely organized with labeled sections, front-loads the core purpose, and every sentence adds operational value. It is longer than average, but the length is justified by the critical side-effect, logging, pause, and licensing details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no required fields, the description covers invocation conditions, exclusions, side effects, audit trail, pause mechanism, and licensing prerequisite. The presence of an output schema means return values need no further explanation, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying the live/action interaction ('run'/'poll' with live=True fire side effects) and noting that wo_id is required for action='run', which enriches the otherwise already-documented parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Run approved work orders from the dashboard inbox.' It also differentiates from sibling tools by naming delimit_agent_dispatch and delimit_work_orders, making the executor's role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 invocation context and point to the correct alternatives. The sibling contrast further clarifies the boundary between reading/closing work orders and executing them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining mutation behavior. It does this thoroughly: writes MANY files, uses backends.generate_bridge.scaffold, coerces packages via _coerce_list_arg with short-circuit on malformed values, has no license gate, no ledger write, no notification, and leaves collision behavior to the backend. This is exactly the operational context an agent needs 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: purpose, when to use, when not to use, sibling contrast, and side effects. The labeled sections make it easy to scan, and the critical caveat about collision behavior is placed at the end as a warning. No filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that writes many files and has minimal annotations, the description is fully complete: it specifies target state, exact non-uses, sibling alternative, side effects, follow-up step, and collision caveat. Since an output schema is present, the lack of return-value documentation is acceptable. The agent can safely decide whether and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter descriptions, so the baseline is 3. The description adds genuine extra meaning: packages is coerced from a comma string into a list and malformed values short-circuit, which is not stated in the schema. It also reinforces that name becomes the root directory and gives concrete example values for project_type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Lay out a fresh project tree with framework-conformant skeleton.' It clearly distinguishes this tool from its closest sibling, delimit_generate_template, by contrasting 'writes a NEW project tree' with 'writes a single file into an existing project.' The intended project types (Next.js app, API service, library) are named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 alternative tools and strategies: delimit_generate_template for single-file scaffolds, the shell for duplicating projects, and the project's own package manager for adding packages. It also identifies the typical follow-up tool, delimit_init, so an agent knows the surrounding workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (not read-only, not destructive), so the description carries the burden and delivers richly: licensing gating with unlicensed callers receiving a license payload and no task creation, backend write to backends.governance_bridge.new_task, persisted fields, and routing through _with_next_steps. This goes well beyond what annotations provide and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into clear labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. It is longer than average but every section adds decision-relevant information, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a governance task-creation tool with an output schema present, the description covers the trigger condition, pipeline position, license gating, persistence side effects, and response routing. Nothing an agent needs to decide whether and how to invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: risk_level drives approval requirements, and title/scope are semantically required despite empty defaults being rejected. This extra behavioral meaning justifies above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'Create a governance-classed task with risk tier and scope'. It distinguishes itself from delimit_ledger_add, delimit_gov_evaluate, delimit_gov_run, and delimit_gov_verify, so an agent can immediately tell what this tool does relative to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use ('immediately after delimit_gov_evaluate returns a gating required verdict'), when NOT to use, and names the alternative tools for each excluded case. It also places the tool as step one of a three-step pipeline, leaving no ambiguity about placement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the sparse annotations by disclosing side effects: it writes a verification record, is gated by require_premium, behaves differently for unlicensed callers, invokes a specific backend method, and does not perform additional work. It also explains the unlicensed response shape and prerequisite, giving full transparency about what happens when the tool is called.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections for when to use, when not to use, sibling contrast, side effects, and prerequisites. Every section provides actionable information, and the most important usage guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 pipeline, prerequisites, licensing behavior, side effects, backend invocation, and relationship to sibling tools. With an output schema already present, the description does not need to explain return values, and 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.
Parameters4/5
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 meaningful context by clarifying that task_id is required despite having a default empty string, and that it comes from delimit_gov_new_task / delimit_gov_run. This resolves a potential ambiguity in the input schema where no parameters are marked required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Attest that a governance task completed under policy.' It clearly defines the tool's role as the closing verification step in the governance pipeline and distinguishes it from related siblings by explaining that it flips a task from 'ran' to 'verified' and produces an attestation entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 ('step three, immediately after delimit_gov_run'), when NOT to use it (for minting tasks or recording execution), and names the exact alternatives (delimit_gov_new_task, delimit_gov_run, delimit_evidence_verify). This gives an agent clear 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses mutation semantics: action 'start'/'stop' mutate daemon process state. It adds rich context beyond annotations by describing polling frequency, classification behavior, draft approval handling, auto-posting being disabled, and the gateway-only 'not_available' payload behavior. This does not contradict the readOnlyHint=false or destructiveHint=false annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: what it does, when to use, when not to use, sibling contrast, and side effects. Every section adds distinct value, and the most decision-critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully orients an agent for a one-parameter control tool: session-start ritual usage, daemon behavior, side effects, integration constraints, and graceful degradation in the npm bundle. An output schema exists, so return-value details are not required here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the single 'action' parameter. The description adds operational meaning beyond the schema by specifying that start/stop mutate daemon state and status is the default inspection mode, reinforcing how the parameter values behave.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Control the inbox polling daemon for email governance (Pro).' It clearly distinguishes itself from siblings by noting that delimit_notify_inbox reads while this tool controls the daemon process that fills the inbox.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('at session start... to ensure the daemon is up; or to stop/inspect it') and when-not-to-use guidance with named alternatives ('use delimit_notify_inbox' or 'delimit_notify'). It also provides a sibling contrast, leaving no ambiguity about role boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the tool writes via ai.ledger_manager.link_items and that 'blocks'/'blocked_by' auto-create the reverse direction. This gives the agent important side-effect knowledge not visible in readOnlyHint/destructiveHint alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, usage, exclusions, sibling contrast, and side effects. Every sentence serves a distinct purpose, 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters and an output schema, the description covers when to use it, when not to use it, alternatives, side effects, and reverse-direction behavior. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context by explaining the relationship semantics, giving example link types, and clarifying that certain link types produce reverse-direction entries, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a typed relationship between two ledger items.' It explicitly contrasts itself with delimit_ledger_links and delimit_ledger_update, making its unique role immediately clear 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.
Usage Guidelines5/5
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 exact alternatives for reading links and updating fields. The sibling contrast section reinforces which tool does what, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait: 'writes to the ledger via ai.ledger_manager.' It also explains the label coercion behavior through _coerce_list_arg. This adds meaningful context beyond the annotations, which only say readOnlyHint=false and destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized with clear sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich 100%-covered input schema and the presence of an output schema, the description covers everything needed: purpose, selection criteria, alternatives, side effects, and partial-update semantics. No critical information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents all 13 parameters. The description adds important usage semantics beyond the schema: 'Pass only the fields you want to change' clarifies partial-update behavior, and the label coercion note explains how the labels parameter is normalized.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Update any field on an existing ledger item.' It clearly distinguishes the tool from delimit_ledger_add and delimit_ledger_done, making its role as the general-purpose updater unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('to change state on a ledger item'), when-not-to-use guidance ('to create a new item... or to mark one done'), and names the exact sibling 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint/destructiveHint annotations by disclosing real side effects: writes evidence on breaking findings, auto-chains semver and governance evaluation, and explains that dry_run=True suppresses these behaviors. It also discloses non-obvious URL fetching behavior including tempfile use, size cap, and SSRF guard.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly organized with labeled sections: purpose, when to use, when not to use, sibling contrast, side effects, and argument behavior. Every sentence carries distinct operational information, with 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that combines diff and policy evaluation, the description covers selection criteria, side effects, dry-run semantics, input formats, and safety behavior around URL fetching. Given the presence of an output schema, the description does not need to enumerate return fields, and everything an agent needs to invoke this tool correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter coverage, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining that spec arguments accept local paths or HTTP(S) URLs and are fetched into a tempfile with safeguards, and by clarifying what dry_run=True actually returns versus suppresses.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource combination: 'Lint two OpenAPI specs for breaking changes and policy violations.' It also explicitly contrasts itself with delimit_diff and delimit_diff_report, making the tool's role unambiguous even within 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.
Usage Guidelines5/5
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, identifies the primary CI-gate context, and names concrete alternatives for raw diff data and quality scoring. This leaves no ambiguity about when an agent should select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this tool writes loop session config via ai.loop_engine.loop_config and reveals the partial-update behavior: only non-zero/non-empty values are applied. This adds meaningful behavioral context beyond the readOnlyHint/destructiveHint annotations, especially the pass-only-what-you-want-to-change rule.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, scannable, and front-loaded with the core purpose. Every section earns its place: purpose, usage timing, exclusions, sibling contrast, and side effects. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the seven optional parameters, the rich schema descriptions, and an output schema, the description covers everything an agent needs: what the tool does, when to use it, what it writes, and how the config update behaves. The partial-update caveat is especially valuable and not inferable from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds important cross-cutting semantics by explaining that non-zero/non-empty values are applied and only changed fields need to be passed, which clarifies the optional/default param behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Configure') and resource ('autonomous build loop safeguards'), and distinguishes itself from delimit_loop_status (reads metrics) and delimit_build_loop (runs the loop). An agent can immediately tell 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.
Usage Guidelines5/5
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 alternative tools and the condition that selects between them. The instruction to call this BEFORE starting a loop session provides clear timing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description adds meaningful context: it is gated by require_premium, calls backends.memory_bridge.search, and documents the unlicensed error/upgrade response. This goes well beyond the structured annotation data and correctly aligns with it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections and front-loaded purpose. Every sentence earns its place: usage guidance, sibling contrast, side effects, and prerequisite are all covered without redundant repetition of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for an agent to select and invoke the tool correctly: it explains when to use it, when not to, what backend behavior to expect, the Pro prerequisite, and the unlicensed failure mode. An output schema exists, so return-value details are not needed here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are already documented, so the baseline is 3. The description adds value by clarifying that 'query' is natural-language and meaning-based rather than recency-based, with a concrete example, which helps the agent phrase queries appropriately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search conversation memory semantically.' It clearly distinguishes itself from siblings by naming delimit_memory_recent and delimit_memory_store and explaining what each is for, so an agent can immediately tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 give concrete guidance with an example query and name the alternative tools for chronological tail and memory writing. This leaves no ambiguity about when the agent should choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that create/update/delete perform writes while list performs reads, routes through backends.ops_bridge.obs_alerts, and is marked EXPERIMENTAL with a backend-specific alert_rule schema that may evolve. It also notes the absence of a license gate. These are meaningful behavioral disclosures that annotations alone 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with clear section headers — 'When to use', 'When NOT to use', 'Sibling contrast', 'Side effects' — and the core purpose is front-loaded in the first sentence. Despite its length, every section earns its place by addressing a distinct decision or behavior relevant to safe invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's multi-action nature, the description covers purpose, usage boundaries, sibling differentiation, side effects, experimental risk, and parameter semantics. The output schema is noted as present, so describing return values is unnecessary. No critical information needed to select or invoke the tool correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the role of each sub-action in plain terms, noting that rule_id is required for delete/update and alert_rule is required for create/update, and warning that alert_rule is backend-specific. This goes beyond the schema's terse property descriptions, though it does not provide concrete example payloads.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Manage alerting rules' — and enumerates the exact sub-actions (list, create, update, delete). It clearly distinguishes this tool from observability siblings like delimit_obs_metrics, delimit_obs_logs, and delimit_obs_status, so an agent can tell them apart 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.
Usage Guidelines5/5
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 the alternative tools for one-shot metric queries, log search, and health rollups. It also warns against misusing 'create' as a delivery retry mechanism, which is exactly the kind of contextual guidance that prevents incorrect invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses substantial behavior beyond annotations: require_premium gating, license-payload responses for unlicensed callers, coercion of parameters from string to dict, malformed-payload error short-circuiting, the underlying backend call backends.os_bridge.create_plan, writing a plan record keyed by generated plan_id, wrapping via _with_next_steps, and the explicit statement that no deploy is executed. This far exceeds the minimal readOnlyHint/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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place: scoping, workflow, exclusions, sibling contrast, side effects, and internal behavior are each in clearly separated sections. The most important identifying sentence is front-loaded, and the structure makes scanning easy despite the volume.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the return-value burden is reduced, yet the description still covers the write path, license gate, error behavior, and the absence of deployment execution. Context signals confirm low structured annotation coverage, so the description fully compensates by giving the agent everything needed to select and safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters and their defaults. The description adds meaningful extra semantics for `parameters` specifically, explaining string-to-dict coercion and malformed-payload failure behavior. It does not significantly enrich `target`, `operation`, or `require_approval`, but the schema already covers those adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Mint an OS-level execution plan against a target component (Pro).' It differentiates from siblings by naming delimit_os_gates, delimit_os_status, delimit_deploy_*, delimit_gov_new_task, and delimit_ledger_add, making it unmistakable what this tool does versus alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is an explicit 'When to use' paragraph laying out the plan -> gate check -> execute workflow, and an explicit 'When NOT to use' list naming concrete sibling tools. It also provides a sibling-contrast paragraph that clarifies the exact boundaries against related OS and governance tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds valuable specifics: 'read-only on policy + spec files' and 'action="simulate" runs lint internally without writing evidence.' This goes beyond the annotations and clarifies the practical safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then organized into clear when/when-not, sibling contrast, and side effects sections. Every sentence adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, a rich annotation set, an output schema, and many siblings, the description covers purpose, usage boundaries, side effects, and alternatives. Nothing crucial 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.
Parameters4/5
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 adds meaning beyond the schema by explaining that action='simulate' runs lint internally, which clarifies what the action parameter actually does in practice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Inspect or simulate governance policy configuration,' a specific verb+resource statement. It also distinguishes itself from delimit_gov_policy and delimit_lint via explicit sibling contrast, so an agent can tell exactly what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides 'When to use' and 'When NOT to use' sections, naming the exact alternative tools (delimit_lint, delimit_gov_policy) and the conditions that select them. No inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint/destructiveHint annotations, the description adds valuable behavioral details: it is read-only on input text, produces a sanitized copy, calls internal PII redaction services, keeps the token map local, and states that the original cannot be recovered through this tool. This gives an agent a clear safety and privacy model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each section earns its place: when-to-use, sibling contrast, side effects, detection scope, and token-map caveat. It is front-loaded with purpose and clearly structured, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full input schema, output schema presence, and annotations, the description is complete for correct invocation. It covers purpose, routing to alternatives, side effects, parameter behavior, and limitations such as the unrecoverable original text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents text, action, and categories. The description adds meaning by enumerating detected sensitive-data types (API keys, passwords, emails, SSNs, etc.) and clarifying action='redact' behavior. It does not fully map the detected types to the category enum values, so a 5 is not warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first line states a specific verb ('scan or redact') and resource ('sensitive data from text'), making the core function immediately clear. The sibling contrast explicitly distinguishes it from delimit_secret_* tools, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it (before sending text to external LLMs or publishing output) and when NOT to use it (for managing stored secrets, use delimit_secret_store family). It also provides the sibling contrast explaining that delimit_secret_* manages credentials at rest while this tool scrubs arbitrary text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations' destructiveHint, explaining that the tool invokes backends.ops_bridge.release_rollback, mutates the live environment, may return partial results on backends without rollback automation, and does not write to the ledger or notify automatically. It also tells the agent to verify with delimit_release_status afterwards. This is thorough 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but highly structured with clear sections: summary, when to use, when not to use, sibling contrast, and side effects. Every sentence earns its place, especially given the destructive and experimental nature of the operation. The main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, experimental environment-wide rollback, the description covers the full workflow, selection criteria, alternatives, side effects, failure modes, verification step, and missing automatic behaviors. The output schema exists, so return-value documentation is not the description's responsibility. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the three required parameters. The description adds operational meaning by explaining that 'version' is the current failing release, 'to_version' is the prior known-good target, and that delimit_release_history should be used to choose it. This enriches the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Revert a whole environment to a prior release version.' It clearly distinguishes this from sibling tools by explicitly stating it reverts an entire environment in lockstep, not a single app at the SHA level. The experimental marker adds an important scoping note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section names concrete triggers (delimit_release_validate/delimit_obs_alerts indicating a cross-service regression) and gives a typical sequence with adjacent tools. 'When NOT to use' explicitly excludes single-app rollbacks, npm publish rollbacks, and roll-forwards, naming the correct alternatives. This is exemplary routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations' readOnlyHint=false and destructiveHint=false, the description discloses side effects: calls multiple models via ai.multi_review, may write a saved review record, and when pr_url is provided returns a comment body without auto-posting. This materially clarifies what invoking the tool can do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then logically organized into usage, non-usage, sibling contrast, and side effects. Each section adds distinct information without fluff or repetition that wastes tokens.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no required parameters and an output schema present, the description covers all essential selection and invocation context: what it does, when to use it, when to avoid it, which siblings are alternatives, and what side effects to expect. An agent can confidently choose and call this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra semantic value for pr_url by explaining the post-as-comment behavior is caller-driven and that the tool returns the comment body rather than auto-posting, which goes beyond the schema's 'GitHub PR URL for linking the review.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run a multi-model code review on a diff or file,' naming a specific action, resource, and input. It further distinguishes itself from delimit_audit and delimit_deliberate, making its scope immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'When to use' and 'When NOT to use,' naming the exact sibling tools that should replace it in other scenarios. The sibling contrast section reinforces the decision boundary with concrete lens/debate vs. single-prompt review distinctions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false and destructiveHint=false, but the description adds substantive behavioral context: start/stop mutate daemon state, the daemon autonomously scans/deduplicates and emits HTML draft emails, and it maps to ai.social_daemon.{start_daemon, stop_daemon, get_daemon_status}. This goes well beyond the annotation flags and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every labeled section earns its place: when-to-use, when-not-to-use, sibling contrast, side effects, and internal method mapping. Despite being detailed, the description is scannable, front-loaded, and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, this is complete: action semantics are clear, exclusions are explicit, side effects are disclosed, and sibling tools are referenced. An agent has everything needed to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the action parameter is already documented; the description still adds value by tying 'status' to inspection and noting that 'start'/'stop' mutate daemon state. The internal method mapping provides extra semantic grounding for the parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource, 'Control the social sensing daemon (Pro)', and enumerates the supported start/stop/inspect operations within an explicit every-15-min scanning scope. It also differentiates itself from delimit_social_target as the one-shot alternative, so an agent can tell them apart 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.
Usage Guidelines5/5
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 that name delimit_social_target for one-shot scans and delimit_notify_inbox for inbox reads. The sibling-contrast line further reinforces the long-running daemon versus one-shot boundary, leaving no ambiguity about when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint=false and destructiveHint=false already permitting writes, the description adds critical behavioral detail: it writes a soul record via ai.session_phoenix.capture_soul, auto-detects git state and current model, and splits comma-string inputs into lists. These are non-obvious behaviors that meaningfully exceed annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear section headers, front-loaded purpose, and zero filler. Every sentence provides actionable information: when to use, when not to use, sibling contrast, and side effects. It is longer than minimal but each part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 optional parameters and an output schema, the description covers the essential decision-making context: trigger conditions, exclusions, alternative tools, side effects, and internal transformations. An agent can correctly select and invoke this tool based solely on this description plus the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explicitly stating that comma-string inputs are split into lists internally, which clarifies the semantics of blockers, decisions, next_steps, and key_context beyond their schema descriptions. It also notes auto-detection behavior for project_path, aligning with the schema's 'Empty = auto-detect' note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Capture session state as a soul', and clarifies the cross-model resurrection purpose. It explicitly contrasts with delimit_session_handoff and names delimit_revive as the consumer, making sibling differentiation clear without needing to open schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, including concrete alternative tools: delimit_memory_store for general memory writes and delimit_session_handoff for structured handoffs. This leaves no ambiguity about when an agent should select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses the side effect: when Storybook is configured, it invokes backends.ui_bridge.story_build via subprocess and writes the static site under output_dir. It also reveals the conditional behavior of returning setup guidance when not configured, going well beyond the sparse readOnlyHint/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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and front-loads the core purpose in the first sentence. Every section — when to use, when not, sibling contrast, side effects — adds necessary decision and behavior information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a build tool with two parameters, an output schema, and simple annotations, the description covers the essential context: prerequisites, alternative tools, side effects, and fallback behavior. Nothing an agent needs 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.
Parameters4/5
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 context by tying output_dir to the subprocess write destination and implying project_path refers to an existing Storybook project, which is more than the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Build a Storybook static site'. It also covers the conditional fallback ('or return setup guidance') and explicitly contrasts itself with delimit_story_generate and delimit_story_accessibility, making its 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.
Usage Guidelines5/5
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, a 'When NOT to use' section naming the alternative tools, and a direct sibling contrast. An agent knows exactly when to pick this tool over the closely related delimit_story_generate and delimit_story_accessibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by disclosing read-only side effects on the vault backend, the require_premium gating, the exact unlicensed response shape, and the underlying backend call. It also aligns with annotations (readOnlyHint, idempotentHint, destructiveHint), adding implementation-level detail without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear labeled sections: purpose, when to use, when not to use, side effects, prerequisite, args, and returns. Every sentence adds value, 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter health-check tool, the description is complete: it covers usage context, exclusions, side effects, licensing prerequisite, error behavior, and return contents. The presence of an output schema also removes the need to heavily describe return structure, and the description still gives a useful summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is no parameter semantics to document. The description explicitly states 'Args: None,' confirming the schema. With no parameters, the baseline of 4 applies and the description handles it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Report vault subsystem health (Pro).' It clearly distinguishes this from sibling tools by stating that delimit_vault_search reads content and delimit_vault_snapshot captures state, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: use at session start or as a CI smoke test to confirm vault backend reachability and index integrity. It also states when NOT to use it and names the correct alternatives, making the routing decision unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the call is gated by require_premium, invokes backends.vault_bridge.snapshot, and writes a snapshot record on the vault backend. This alerts the agent that the operation is state-changing despite destructiveHint=false, adding significant behavioral context the annotations alone 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.
Conciseness5/5
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, args, and returns. The most important information is front-loaded, and each section earns its place by adding actionable guidance rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description covers all necessary context: what it does, when to use it, alternatives, side effects, and return shape. The output schema presumably details the snapshot structure, so the description's high-level 'Dict with snapshot data and next_steps' is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema confirms this with empty properties. The description explicitly states 'Args: None,' which is redundant with the schema but harmless. With 0 params, there is no parameter semantics burden, so the baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Capture a snapshot of vault state (Pro).' It distinguishes the tool from siblings by explicitly contrasting it with delimit_vault_health, which reports only up/down status, while this tool returns a structured snapshot. An agent can immediately tell what this tool does and how it differs from adjacent tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance ('before a risky vault edit, to have a rollback point') and when-not-to-use guidance with named alternatives ('searching content (use delimit_vault_search) or checking health only (delimit_vault_health)'). 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent, but the description adds meaningful behavioral context: it counts registered tools, detects API keys/CLIs/security tools, and reports environment-detection results. This goes beyond the annotations and helps the agent anticipate side effects and capabilities without manual configuration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: purpose, usage, exclusions, sibling contrast, side effects, args, and returns. Every section earns its place and contributes directly to correct invocation, without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument read-only tool with a returned dict described at a high level and an output schema present, the description is complete. It covers when to use it, when not to, what it reports, and its side-effect profile. Nothing essential is missing for an agent to call it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty input schema is self-explanatory. The description explicitly states 'Args: None' and clarifies what the tool returns, which is sufficient for a parameterless tool. Baseline 4 is appropriate since there is nothing more to add about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Return Delimit server version, tool count, and environment status.' It distinguishes itself from delimit_help, delimit_gov_health, and delimit_os_status by scope, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit 'When to use' guidance for session start, dashboards, and diagnostics. It also provides 'When NOT to use' exclusions with named alternatives, which is exactly the level of routing clarity an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only provide tool-level readOnlyHint=false and destructiveHint=false. The description adds genuinely useful per-action behavioral disclosure: action='list'/'show' are read-only while action='complete' writes to the work-order store via ai.work_order.complete_work_order. This goes beyond the annotations and tells the agent exactly which invocations have 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.
Conciseness5/5
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, side effects) and front-loads the core purpose. Every sentence earns its place; the sibling contrast slightly overlaps with 'when NOT to use', but it adds concrete named alternatives rather than pure repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present (return values are covered), zero required parameters, and a description covering purpose, usage boundaries, sibling differentiation, and per-action side effects, there is nothing an agent needs to invoke the tool correctly that is missing. The reference to STR-177 is minor noise but not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 — the schema already documents all four parameters well. The description adds value by mapping action values to side-effect behavior (read-only vs write) and connecting note/wo_id to the 'complete' action, which is beyond the schema. It doesn't elaborate on status filter nuances or wo_id format, so it doesn't reach 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair — 'Manage work orders' — and immediately elaborates the concrete actions: 'to list, read, or close work orders'. It frames work orders as 'structured task artifacts for the founder' and explicitly contrasts with ledger and governance tools, so an agent can distinguish it from siblings 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.
Usage Guidelines5/5
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 concrete alternatives (delimit_ledger_* for ledger items, delimit_gov_new_task / run / verify for governance tasks) and explains the boundary. This is exactly the kind of routing guidance that lets an agent pick the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by detailing side effects: require_premium gating, wrapped function calls, JSONL log writes, queue behavior, and rate-cap consumption. It also explains exactly what dry_run does and does not do, which is valuable behavioral context not present in the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with clear labeled sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence contributes useful decision-making information, and the most critical scoping information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, explicit sibling differentiation, detailed side-effect disclosure, and an output schema available, this description is complete. There are no obvious gaps an agent would need to resolve elsewhere before invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaning beyond the dry_run schema description by clarifying that dry_run=True is cache-friendly, skips the JSONL log write, and skips the drafter entirely with no queue or rate-cap consumption. This materially improves an agent's ability to choose the right value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Scan watchlisted vendor accounts and auto-draft riffs') and clearly distinguishes this tool from its closest siblings by naming exactly what each sibling does. This makes the tool's identity unambiguous even among a large family of delimit_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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, a 'When NOT to use' section, and names the alternative tools for each exclusion case. An agent can confidently decide between scan, draft, and health without needing to inspect their schemas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![delimit-mcp-server MCP server](https://glama.ai/mcp/servers/delimit-ai/delimit-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/delimit-ai/delimit-mcp-server)

Score Badge

Copy to your README.md:

[![delimit-mcp-server MCP server](https://glama.ai/mcp/servers/delimit-ai/delimit-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/delimit-ai/delimit-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/delimit-ai/delimit-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server