delimit
OfficialServer Quality Checklist
Latest release: v4.13.1
- 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/5The 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/5209 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/5Given 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
- 72 commits in the last 12 weeks
- Last stable release on
- 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.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses side effects (write operations for create/delete/toggle, read-only for list) but lacks details on other behaviors like reversibility or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured with separate sections for usage and side effects; no unnecessary words, but could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, side effects, and sibling differentiation. Output schema exists so return values not needed. Lacks some detail on action behavior specifics but sufficient for a CRUD tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% so baseline is 3. Description adds no extra parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it manages cost alert rules with CRUD operations. Distinguishes from siblings explicitly by specifying when to use and when not, and provides sibling contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (configure ongoing spend thresholds) and when not (one-shot analysis or optimizations), referencing specific sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently discloses side effects: license gating (require_premium), local disk and CPU consumption via docker buildx, and no network push. It also mentions response routing. Lacks details on error behavior or build timeouts, but otherwise thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into logical sections (purpose, when to use, when not to use, sibling contrast, side effects). It is front-loaded with the core purpose. While comprehensive, it could be slightly more concise; the sibling contrast section, though helpful, is somewhat lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (build step with side effects) and the presence of an output schema (mentioned in context), the description adequately covers purpose, usage, side effects, and relationships to siblings. It does not detail the output format but that is handled by the output schema. Minor gaps: no mention of required permissions or error recovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (app and git_ref) are fully described in the schema (100% coverage). The description adds only boilerplate context (e.g., 'git ref (Pro)') but does not provide additional semantic guidance beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Build container images for an app at a specific git ref', identifies the resource (container images), and distinguishes from siblings by positioning itself as the second step in the deploy chain. The title implies this is the build step, and the description reinforces that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections provide clear context for when this tool is appropriate, including the full chain (plan -> build -> publish -> verify -> rollback) and specific sibling alternatives for when not to use (e.g., delimit_deploy_publish, delimit_deploy_site).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses side effects: writes via ai.ledger_manager.add_item and coerces comma strings to lists for certain parameters. This goes beyond basic operation description, though it omits details like error behavior or idempotency. Still, it provides meaningful behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (action, use cases, sibling contrast, side effects) and is front-loaded with the primary action. It is not overly verbose, though it could be slightly more concise. Overall, it balances completeness and brevity effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters) and the presence of an output schema (context signals indicate has output schema: true), the description does not need to detail return values. It covers purpose, usage guidelines, and behavioral traits. It lacks details on error handling or prerequisites, but it is sufficient for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, so baseline is 3. The description adds value by noting that tags, acceptance_criteria, and tools_needed are coerced from comma strings to lists, but it does not explain other parameters beyond schema descriptions. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a new item to a project's ledger.' It further distinguishes from sibling tools by specifying when to use (capture work that outlives the session) and when not to use (governance-classed work or quick memory). It explicitly contrasts with delimit_ledger_update and delimit_ledger_done, providing a clear identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 specific alternatives (delimit_gov_new_task, delimit_memory_store). It also gives a sibling contrast explaining how this create operation differs from update and close. This gives the agent precise guidance on 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?
No annotations provided, so description carries full burden. It clearly states side effects: mutation for save/delete (~/.delimit/playbooks/), model call for run, read-only for list. It also mentions variable substitution and cross-assistant sharing. However, it doesn't mention auth needs, overwrite behavior, or error conditions, which would push to 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: summary line, then usage guidelines, sibling contrast, side effects. All sentences are relevant. Could be slightly tighter, but no extraneous content. Front-loaded with purpose, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, multiple actions, variable substitution), the description covers key aspects: purpose, usage guidance, side effects, and sibling differentiation. It does not detail output format, but an output schema exists. A minor gap is no mention of required conditions for save/run/delete (e.g., name required), but schema provides that. Overall adequate and helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description adds high-level context (grouping actions, variable format) but does not add detailed semantics beyond schema. Baseline 3 is appropriate as the description complements but does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'Manage reusable prompt templates — save / run / list / delete.' It immediately conveys the tool's purpose and distinguishes it from siblings like delimit_memory_store and delimit_project_config, which are explicitly mentioned in 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('save your best prompts as named commands and run them later') and when-not-to-use ('manage project config' or 'memories'), with specific alternative tool names. Also includes sibling contrast sentence. This exceeds the typical 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?
Despite no annotations, the description discloses its role as a dispatcher, lists the six actions, notes that invalid actions return a deterministic error, and explains the sync_action sub-action. It could be more explicit about potential destructive behaviors (e.g., rollback) or side effects, but it provides sufficient transparency for a dispatch function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when to use/not use, sibling contrast) and each sentence adds value. It could be slightly more concise, but it remains efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 optional parameters, presence of output schema, and a large sibling set, the description adequately explains its role as the dispatch core and its relationship with aliases and other tools. It doesn't cover every detail of each action, but it provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter, including defaults and usage scope per action. The description adds no extra parameter information beyond the schema, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'unified release-management entry point' that dispatches to six specific actions. It distinguishes itself from sibling aliases (e.g., delimit_release_plan) and from deploy-tier tools (delimit_deploy_*), making its purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (as the single MCP surface for release operations by name) and when NOT to use (prefer specific aliases in internal code). Also contrasts with related tools like delimit_deploy_status and delimit_lint, offering comprehensive 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?
With no annotations, description carries full burden. It discloses side effect (appends access log entry) and behavioral constraint (does not return secrets to unauthorized scopes). Could mention failure modes, but transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and front-loaded with main action. Each sentence adds value (when-to-use, sibling contrast, side effects). Could combine some sentences, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage context, side effects, and authorization constraints. Does not describe return structure, but output schema exists. Could mention error scenarios (e.g., missing secret), but still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions. The description does not add extra meaning beyond what schema already provides (e.g., required status, broker scope check). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Request just-in-time access to a stored secret.' It uses specific verb 'request' and resource 'stored secret', and distinguishes itself from siblings (delimit_secret_store writes, delimit_secret_access_log shows audit trail).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' (credential needs at execution time) and 'When NOT to use' (to add a secret or examine audit log), with direct references to alternate tools. Also includes sibling contrast.
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?
No annotations provided, but description discloses side effect of writing a link. Lacks details on idempotency or error conditions, but sufficient given tool simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, when to use/not, sibling contrast, and side effects. No unnecessary words. Front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, side effects, and sibling contrast. Output schema exists so return details not needed. Could mention prerequisite that items exist, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented there. Description does not add additional meaning beyond what's in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool links an agent task to a ledger item, with specific verb and resources. It distinguishes from sibling tools like delimit_agent_dispatch and delimit_ledger_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after dispatch to show relationship) and when not to use (for new dispatch or close). Provides clear sibling contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses side effects: gated by require_premium, calls ai.cross_model_audit.audit, and no ledger write. This is good coverage, though it could additionally mention output format or cost implications. Still, it provides significant transparency beyond minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence serves a purpose, no redundancy, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, output schema exists, no annotations), the description covers purpose, usage, alternatives, and key side effects. It does not explain the output format in plain language (but schema covers it) and omits potential costs, but the level of detail is sufficient for confident agent invocation. Minor room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 3 parameters are described in the schema with 100% coverage. The description adds context about the three lenses (security, correctness, governance) and the cross-model nature, but does not materially extend the schema's semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb (audit) and resource (code change), specifying it uses 3 models and 3 lenses (security, correctness, governance). It distinguishes itself from siblings delimit_review and delimit_deliberate by highlighting the cross-model structured audit approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' and 'When NOT to use' with concrete alternatives (delimit_deliberate for debate, delimit_review for single-model review). The 'Sibling contrast' section further clarifies the differentiation, leaving no ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses side effects: writes policy file, optionally writes workflow file, sanitizes project_path. However, it does not specify overwrite behavior, permissions needed, or error cases, slightly reducing completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with separate sections for core action, usage guidance, and side effects. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, output schema exists, no annotations), the description covers purpose, usage, side effects, and sibling relationships. It lacks details on error handling and prerequisites, but output schema covers return values. Overall, fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about config_json origin and write_workflow purpose, but does not significantly enhance parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports a governance config from a JSON bundle into a project, using a specific verb and resource. It distinguishes from siblings by mentioning the round-trip counterpart (delimit_config_export) and contrasting with init and project_config loading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections provide clear guidance, naming alternative tools for different scenarios (delimit_init, delimit_project_config). The sibling contrast further clarifies the tool's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lists side effects: actions 'set' and 'reset' mutate state, 'status' and 'quota' are read-only. Since no annotations exist, description carries full burden; it covers the key behavioral distinction among actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when to use, when not, sibling contrast, side effects). Every sentence adds value; no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, side effects, and sibling differentiation. No annotations provided, but description sufficiently guides selection and invocation. Output schema exists but isn't needed to explain returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description mentions actions and that tool_name is required for certain actions, but adds minimal extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Manage MCP rate limits and session cost controls' with specific verb and resource. Differentiates from siblings like delimit_cost_analyze and delimit_cost_alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (inspect/adjust), when not to use (project-cost analysis, alert configuration), and names alternative tools (delimit_cost_analyze, delimit_cost_alert).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature and premium gating. No annotations exist, so description bears full burden. Could mention the output structure, but the presence of an output schema reduces need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs with front-loaded purpose, clear usage guidance, and behavioral notes. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, side effects, and gating. With an output schema, return values are implicitly handled. One could argue it's complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'target' has full schema coverage with default and description. The description does not add extra meaning beyond schema, which is acceptable for a simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds cost optimization opportunities, specifies the context (after delimit_cost_analyze), and distinguishes from siblings like delimit_cost_alert. The verb-resource pair is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use and when-not-to-use guidance with concrete sibling tool names. The sibling contrast further clarifies differentiation, making it easy for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It declares read-only side effects and lists underlying API calls, providing good but not exhaustive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise, front-loads purpose, then usage guidelines, sibling contrast, and side effects in a clear, structured format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, side effects, and sibling differentiation. Output schema exists, so return values need not be explained. Minor gap: does not elaborate on risk tier or tool details, but these are likely in output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description repeats similar info about item_id meaning without adding new details beyond what schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Classify' and resource 'ledger item's risk tier and suggested automation tool'. It explicitly distinguishes from siblings by stating it previews daemon action versus run or status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use (preview classification), when NOT to use (run or check health), and direct alternatives (delimit_daemon_run, delimit_daemon_status).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the burden. It describes side effects: dry_run vs live mode, the internal call to ai.daemon.run_loop, and the 5-second interval. This is good but could mention permissions or the nature of 'automatable actions'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and effectively front-loaded. Each sentence provides essential information without redundancy. Three short paragraphs and a bullet-like list cover purpose, usage, and side effects efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two simple parameters and an output schema, the description covers purpose, usage, differentiation, and side effects. It mentions the 5-second interval, which is valuable. Minor gaps: no mention of error cases or permission requirements, but overall sufficient for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. The description does not add significant new information about parameters beyond what the schema already provides (defaults, infinite loop). It mentions dry_run in side effects but doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Advance the autonomous daemon by N iterations (Pro).' It specifies the verb and resource, and distinguishes from siblings (delimit_daemon_status, delimit_daemon_classify).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (testing, cron-style execution) and when not to use (inspection, classification), with direct references to alternative tools. Sibling contrast is clearly explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Side effects: read-only inspection.' and 'Calls backends.tools_data.data_migrate.' Clearly indicates no destructive actions. Lacks details on permissions, error handling, or output format, but output schema may cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-organized: one-sentence purpose, then bullet-like sections for usage, contrast, and side effects. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage guidelines, side effects, and parameter meaning. With an output schema, return values do not need to be described. Slightly lacking in detailing what the inspection output looks like, but overall sufficient for a simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage for the single parameter 'target', with description 'Project path to scan for migration files. Default "." (cwd).' The description does not add additional semantic value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Starts with 'Inspect migration files (alembic / Django / Prisma / Knex) for status.' Clearly states verb (inspect) and resource (migration files) with specific types. Distinguishes from siblings by contrasting with delimit_data_validate and delimit_data_backup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('audit pending and applied migrations before a deploy, or as a CI gate'), when not to use ('to actually apply migrations' or 'back up data first'), and mentions alternative tool (delimit_data_backup). Includes sibling contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects: requires premium, mutates environment via backend call. Lacks details on error conditions or authorization beyond premium, but adequate for a mutation tool without 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with clear sections (purpose, when to use, when not, sibling contrast, side effects). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential aspects given presence of output schema (not needing return value explanation). Could include more on failure modes or idempotency, but sufficient for a rollback operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds no new meaning beyond schema; 'to_sha' is already described. No extra guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Roll back an environment to a previous SHA' and distinguishes from sibling delimit_deploy_publish, which moves forward. Specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (after delimit_deploy_verify shows regression) and when NOT to use (for deploying new version). Also contrasts with sibling 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?
Despite no annotations, the description details read-only nature, license gating, backend call, and no side effects. It could be slightly more explicit about the output format but overall covers behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, but slightly verbose. The main point is front-loaded, and every sentence adds value, though some redundancy exists between 'When to use' and 'Sibling contrast'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 simple params, no annotations, and an output schema, the description covers purpose, usage, behavioral details, and licensing; sufficient for correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal meaning beyond the schema. It reinforces the app/env context but does not provide additional constraints or format hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads rollout metadata for an app/env, with a specific verb and resource. It distinguishes from siblings like delimit_deploy_verify (runtime probes) and delimit_release_status (release tracking).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with specific alternative tool names, providing clear guidance on when to choose this tool over others.
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 annotations, the description carries full burden. It discloses side effects: writes a .tsx file, default path, and Tailwind config detection. Could mention potential overwrite behavior, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose, and well-structured with clear sections for usage, contrast, and side effects. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity, presence of output schema (not shown but indicated), and coverage of purpose and side effects, the description is fairly complete. Lacks error handling info but adequate for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. Description adds little beyond schema, e.g., mentioning 'props interface' but not elaborating parameter specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a React/Next.js component skeleton with Tailwind support, distinguishing it from sibling tools like delimit_story_generate and delimit_design_extract_tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (scaffold new component) and when not to use (generate stories or extract tokens), with references to alternative tools. Also provides sibling contrast.
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?
Transparently states 'read-only' and discloses the underlying API call (ai.drift_monitor.get_drift_history). Since no annotations are provided, the description carries the full burden; while it could mention rate limits or caching, the key behavioral trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action. Uses bullet points effectively for usage guidance and side effects. Minor redundancy between 'When NOT to use' and sibling contrast but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an output schema, the description covers purpose, usage scenarios, alternatives, and behavior comprehensively, leaving no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (limit) with schema description coverage of 100%. The description does not add additional meaning beyond the schema's explanation of 'Max entries to return. Default 20.' Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent drift-check results from the drift monitor, with a specific verb ('list') and resource ('drift-check results'). It distinguishes from the sibling tool delimit_drift_check by noting it reads historical results rather than running a check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (investigate last detected drift and changes) and when not to use (perform a fresh drift check), with a named alternative tool (delimit_drift_check). This gives clear guidance for an AI agent to select 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?
Discloses side effects ('writes a new handoff receipt via ai.handoff_receipts.create_receipt') and expected follow-up (receiving agent should call delimit_handoff_acknowledge). No annotations provided, so description carries full burden. Lacks specifics on authorization or impacts on other systems, but adequate for a creation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with clear sections (when to use, when not, sibling contrast, side effects). Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 optional parameters, no annotations, and an output schema (not shown), the description covers usage, exclusions, side effects, and sibling distinctions well. Does not explain return values, but output schema covers that. Minor gap: no mention of default behavior when no params provided, but defaults are in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes each parameter. The description only mentions fields like completed/not_completed/blockers/scope in passing, adding no new semantic depth. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a handoff receipt when transitioning between agents.' It also explicitly distinguishes from siblings (delimit_session_handoff, delimit_soul_capture) by highlighting structural differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('at the end of a session or before passing work to another model') and when-not-to-use ('use delimit_session_handoff for general summary, delimit_handoff_acknowledge to acknowledge'). Also contrasts with siblings via bullet points.
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?
Discloses side effects: 'writes a registry entry via backends.tools_data.intel_dataset_register' and schema coercion via '_coerce_dict_arg'. With no annotations, this adds good transparency. Minor omission: no mention of whether duplicate names are allowed or overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise: 4 sentences covering purpose, usage, contrasts, and side effects. Front-loaded with primary action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and side effects. Output schema exists, so return values need no explanation. Might benefit from mentioning prerequisite (e.g., registry existence) or error cases, but not essential for a simple registration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value only for the schema parameter (coercion detail). Not enough to raise to 4, but not lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Register a new dataset in the file-based intel registry.' It uses a specific verb (Register) and resource (dataset), and distinguishes from siblings by explicitly contrasting with list and freeze 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('at the start of an intel collection effort') and when not to use ('to write data into an existing dataset' or 'to inventory datasets'), with clear alternatives (delimit_intel_snapshot_ingest, delimit_intel_dataset_list).
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 annotations, the description carries the full burden. It declares 'Side effects: read-only' and 'Calls ai.ledger_manager.get_context', which is useful. However, it doesn't detail error conditions or the exact return structure (though output schema exists). A 4 is appropriate for adding good behavioral context beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the core purpose. Every sentence adds value, including separate sections for usage guidelines, sibling contrast, and side effects. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, clear purpose), the description covers purpose, usage, exclusions, side effects, and implementation. It is complete enough for an agent to know when and how to use it. Minor omission: no mention of error handling or empty state, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already fully describes the single optional parameter `venture` with default and auto-detection. The description does not add additional meaning or constraints beyond what the schema provides, so a baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'Quick summary of what's open in the ledger (top 5 by priority)', providing a specific verb, resource, and scope. It also distinguishes from siblings by contrasting with delimit_ledger_list (full list) and delimit_ledger_query (specific item).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('at session start as part of the orchestrator session ritual') and when NOT to use ('for the full list... or to fetch a specific item'), including alternative sibling tools. This provides excellent 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?
No annotations provided, so description carries full burden. Clearly declares read-only nature and return of proposals. Warns about risky operations and mentions that each proposal includes a copy-pasteable ready_to_apply invocation. Could be slightly more specific about what constitutes stale/duplicate/garbage, but overall good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections and front-loaded with main purpose. However, it repeats the risky operations warning twice, which slightly reduces conciseness. Otherwise efficient use of sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and rich schema, description provides complete context: purpose, usage, side effects, sibling contrast, and even references a project ticket. It fully explains the tool's role in the ledger family and the review-then-apply workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 4 parameters with descriptions (100% coverage). Description adds minimal extra value beyond schema, only noting that venture auto-detects. Baseline 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a read-only grooming proposal that flags stale/duplicate/garbage items. It distinguishes from siblings delimit_ledger_bulk (applies changes) and delimit_ledger_health (composes checks). Verb 'proposes' and resource 'ledger items' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (periodic review) and when not to use (to apply changes). Provides alternative tool 'delimit_ledger_bulk' and warns that risky operations must go through bulk after review. Clear guidance on appropriate usage 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?
No annotations are provided, so the description carries the full burden. It explicitly states 'Side effects: read-only' and the underlying call ('Calls ai.ledger_manager.get_links'), which is good. However, it could elaborate on error handling or pagination, though the output schema likely covers return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concisely structured with sections, front-loaded with the purpose, and every sentence adds value. No fluff or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 2 parameters and an output schema, the description is fairly complete: it covers purpose, usage, side effects, and sibling contrast. Minor gap: it does not mention behavior when the item_id is missing or invalid, but that is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description restates parameter meanings (e.g., 'Item id to look up links for') without adding significant new information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'List relationships / dependencies for a ledger item.' It uses a specific verb ('list') and resource, and distinguishes itself from siblings like 'delimit_ledger_link' (adds links) and 'delimit_ledger_update' (updates fields).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections are provided, with clear examples of what to inspect (blocks, depends, parent/child, related, duplicates) and alternatives (use delimit_ledger_link to add, delimit_ledger_update to update).
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?
Declares 'Side effects: read-only' and notes internal calls to list/context queries. While no annotations exist, the description covers the key behavioral trait of being non-destructive. Could further detail error handling or latency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a one-line summary followed by usage guidance, sibling contrast, and side effects. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, alternatives, and read-only nature. With an output schema present, the description is adequate for an agent to decide when to invoke the tool. Minor gap: no mention of answer format, but schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal parameter meaning beyond the schema. The tool-level context ('Ask natural-language questions') provides some value but doesn't elaborate on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Ask natural-language questions about the ledger' and contrasts with sibling tools delimit_ledger_list and delimit_ledger_context, making the purpose clear and 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/5Does 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, directing operators to alternative tools for structured queries and top-N summaries, with sibling contrast.
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?
No annotations provided, so description carries full burden. It discloses side effects (writes to ledger via ai.ledger_manager, coerces labels list via _coerce_list_arg). Could mention error handling or response format, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with core action, then organized into clear sections (when to use, when not, sibling contrast, side effects). Every sentence serves a purpose, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity (13 params, output schema exists), description covers purpose, usage, side effects, and differentiation. Lacks details on return values or error behavior, but output schema exists to cover returns. Good overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. Description adds value with the hint 'Pass only the fields you want to change', but does not substantially extend schema info. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'existing ledger item', and distinguishes from siblings like delimit_ledger_add (create) and delimit_ledger_done (close). It specifies scope as 'any field' with examples, making 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with specific alternatives (delimit_ledger_add, delimit_ledger_done). Also includes sibling contrast, providing clear context 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?
With no annotations provided, the description carries full burden. It discloses that actions are gated by require_premium and distinguishes between read-only (list/detect) and write (add/remove) operations. However, it does not detail error conditions or what happens if premium is lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with clear sections for purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and an output schema, the description covers purpose, usage, and side effects adequately. The output schema presumably handles return value details, so the description is sufficiently complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema; it mentions possible actions but that is already in the schema. No additional parameter-level guidance is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'View and configure AI models for multi-model deliberation (Pro).' It lists specific actions (inventory, auto-detect, register/remove) and distinguishes from sibling delimit_deliberate by stating that this manages which models the panel can call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 alternatives like using delimit_deliberate for running a deliberation. The sibling contrast further clarifies the tool's role versus delimit_deliberate.
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?
No annotations provided, so description carries full burden. It details side effects: license gating, parameter coercion, plan record creation, and clarifies no execution. Could mention rate limits or idempotency, but covers core behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long but well-structured with sections; front-loaded with purpose. Every sentence adds value. Minor redundancy could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return values need no explanation. Description covers purpose, usage, side effects, and sibling differentiation. Complete for a complex tool with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description does not add extra meaning beyond schema descriptions; it focuses on usage rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'mint' and resource 'OS-level execution plan against a target component'. It distinguishes from siblings like delimit_os_gates and delimit_os_status through explicit 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with fully named sibling tools (e.g., delimit_os_gates, delimit_deploy_*, delimit_ledger_add) provide clear guidance on appropriate contexts.
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?
No annotations are provided, so the description carries the full burden. It discloses side effects for different actions: 'record' writes to a store, while 'check' and 'rank' are read-only. This adds important behavioral context beyond the schema, though it does not cover error conditions or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with distinct sections for purpose, usage guidelines, sibling contrast, and side effects. Every sentence adds value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, output schema exists), the description covers purpose, usage guidelines, side effects, and sibling comparison. The output schema likely documents return values, so the description is adequate and complete for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal parameter-level detail beyond the schema, but does mention that 'model' is required for the 'record' action, which is a nuance not captured in the schema's required field (none). This adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects prompt drift across models for the same task. It uses the specific verb 'Detect' and resource 'prompt drift', and distinguishes from the sibling tool delimit_deliberate by noting it tracks single-model behaviour rather than cross-model deliberation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 tool (delimit_deliberate) and a sibling contrast that clarifies the difference. This gives clear guidance on when to use 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It declares read-only nature and indicates cross-model compatibility. While it doesn't detail error handling or prerequisites, the side-effect disclosure is adequate for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the key action, and every sentence serves a purpose. No redundant or superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description is complete—it covers purpose, usage guidelines, side effects, and sibling differentiation. Minor gaps in behavioral details are acceptable due to the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters well. The description adds minimal additional context beyond parameter defaults and usage hints, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Revive' with resource 'soul' and clearly distinguishes from sibling tools delimit_soul_capture (writes) and delimit_memory_recent (reads memories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('at session start, to load the prior session's soul'), when not to use (for capture or memory read), and contrasts with siblings. Provides clear decision 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?
Discloses key behaviors: gated by require_premium, calls multiple models via deliberation panel, updates ledger items with verdicts. No annotations exist, so description carries the burden; it does so well, though lacks mention of idempotency or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and well-organized: single sentence purpose, then structured sections for when to use, when not to, sibling contrast, and side effects. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites (after ingest), side effects, premium requirement, and output schema exists. Adequately complete for an agent to decide correct usage and invocation, though minor details like error conditions are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is already described in the schema. The description adds minimal extra meaning beyond what the schema provides, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it performs multi-model triage of security findings, classifying them into categories like real risk, false positive, etc. Distinguishes from sibling delimit_deliberate as the security-class variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (after delimit_security_ingest), when not to use (for ingestion or scanning from scratch), and contrasts with sibling tool. Provides clear, actionable 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?
No annotations provided, so description carries full burden. Discloses side effects: gated by require_premium, writes to ledger, creates/updates findings, computes fingerprints. Could elaborate on error conditions but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when to use/not use, sibling contrast, side effects). No redundant sentences, all information earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, side effects, and contrasts. Output schema exists so return format not needed. Minor gap: no error handling details, but overall complete for a tool with good schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds little beyond schema descriptions. It mentions auto-detect for defaults, which is helpful but not transformative. Baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Ingest external security scan output and normalize into ledger findings (Pro).' This is a specific verb+resource+outcome. Sibling contrast explicitly differentiates from delimit_security_scan and delimit_security_deliberate, so purpose is clear and 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/5Does 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. Lists supported scanners (Trivy, Semgrep, etc.) and when to use alternatives. Provides clear decision 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?
With no annotations, the description fully bears the burden. It discloses read-only side effects, allowlist enforcement (LED-881 guard), and the underlying function call. Missing details like rate limits or error handling, but covers key behavioral traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (purpose, when to use/not use, sibling contrast, side effects). It is informative without being verbose. Could be slightly more streamlined, but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context signals say true), the description does not need to explain return values. It covers purpose, usage guidance, sibling differentiation, side effects, and internal calls—complete for a 2-param tool with good sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. The description does not add significant semantics beyond the schema's descriptions of 'repos' and 'limit'. It mentions 'per repo' in limit context but no extra detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans GitHub issues/PRs for migration patterns. It distinguishes itself from siblings by specifying that it detects migration-pattern language, while delimit_sensor_github_issue tracks a specific issue's state and delimit_github_scan does broad public-repo polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' (competitive intelligence) and 'When NOT to use' (general sensing, single-issue intel, broad polling), naming alternative tools like delimit_sense, delimit_sensor_github_issue, and delimit_github_scan.
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 annotations, the description provides adequate behavioral detail: it discloses that configure/forward/test actions involve network writes, while status is read-only. This goes beyond basic purpose but could be more exhaustive (e.g., mention idempotency or error 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five concise sentences, no redundancy. Front-loaded with purpose, then usage guidelines, sibling contrast, and side effects. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description adequately covers purpose, usage, side effects, and parameter context. It could include a brief example of a typical usage flow, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal parameter-level detail beyond what the schema already provides (e.g., example integrations), but doesn't significantly enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages SIEM streaming for audit-event forwarding, specifies supported endpoints (Splunk, Datadog, etc.), and distinguishes from sibling tools like delimit_notify and delimit_notify_inbox by contrasting 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (inspect/configure streaming) and when not to use (one-shot notifications, inbox handling), with direct references to alternative tools. The sibling contrast further clarifies usage boundaries.
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 annotations, the description carries full burden. It identifies which actions mutate state ('register', 'create_tool', etc.) and which are read-only. Discloses that each venture gets 5 agent roles with namespace isolation and model binding. Lacks details on authorization or failure modes but is fairly comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence adds value, no redundant information. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, multiple actions, output schema exists), the description covers usage, exclusions, side effects, and high-level structure. It doesn't explain all possible actions exhaustively but provides sufficient guidance. Output schema existence is noted but not described, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by grouping actions but does not significantly elaborate on individual parameters beyond the schema's minimal descriptions. The action parameter's default and purpose are clarified via examples, but other parameters (repo_path, target_path) remain somewhat ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages the cross-venture agent swarm, listing specific actions like register venture, create tools, hot-reload modules. It distinguishes from sibling tools by contrasting with delimit_agent_dispatch (per-task) and delimit_agent_status/dashboard (read state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with named alternatives (delimit_agent_dispatch, delimit_agent_status/dashboard). Also provides sibling contrast, making it clear when this 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?
No annotations exist, so description carries full burden. It lists side effects for each action (mutating vs read-only), but does not cover error conditions or authorization needs. Still strong for a cache management 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, followed by well-organized sections for usage, sibling contrast, and side effects. No superfluous sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, side effects, and alternative. Output schema exists to handle return values. Lacks prerequisites (e.g., need to register before other actions?) but default action is safe. Good overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description groups actions by side effect (mutating vs read-only), adding some context beyond schema, but does not add meaning for tool_schemas or tool_names beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages a tool-schema cache to reduce token waste, specifies the resource and action, and distinguishes from sibling delimit_help by saying 'this caches tool schemas; delimit_help describes individual tools at runtime.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections, with a clear alternative (delimit_help) and context (cache side-channel, not runtime dispatcher).
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?
No annotations provided, so description carries full burden. Discloses side effects: applies license key, auto-configures permissions (writes settings.json). Notes skipped checks don't affect score. Could mention reversibility but still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, well-organized with clear sections. Front-loaded with main purpose. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers activation, readiness checklist, side effects, and sibling distinction. Output schema exists so return values are handled. Complete for an activation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. Description adds context about free-tier readiness for license_key but doesn't provide new semantic meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Describes the tool as 'Activate Delimit and run a readiness checklist.' Clearly distinguishes from siblings by contrasting with delimit_diagnose (diagnostic debugging) and delimit_quickstart (first-run discovery).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (post-install confirmation) and when not to use (diagnostic debugging, first-run discovery). Provides sibling contrast for alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects ('read-only on the policy store') and the underlying call. No annotations exist, so the description carries full burden. It covers the main behavioral trait (read-only) but could mention return value or error handling; however, output schema likely covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with clear sections (purpose, when to use, when not to use, sibling contrast, side effects). Every sentence adds value, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description covers purpose, usage guidelines, side effects, and sibling differentiation comprehensively. No gaps for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes both parameters (model, action) with clear descriptions, and coverage is 100%. The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if a model is allowed to perform an action under agent policy.' It uses specific verb-resource pairing and contrasts with siblings (delimit_agent_policy, delimit_gov_evaluate), making its role distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('as a per-action gate before executing sensitive operations from a non-orchestrator model') and when not to use (setting policies or runtime governance), with alternative tool names provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses side effects: 'writes a handoff record' and 'updates assignee on the task.' This is good but does not cover potential error states or idempotency. Nonetheless, it is transparent about key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-sentence summary, followed by clear bullet-like sections for when to use, when not to use, sibling contrast, and side effects. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which explains return values) and the detailed description covering purpose, usage, and side effects, the description is complete for this tool's complexity. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant extra meaning beyond what the schema already provides for each parameter (task_id, to_model, context).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Hand off an agent task to a different AI model') and distinguishes it from siblings in the 'Sibling contrast' section, specifically contrasting with delimit_agent_complete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' conditions are provided, naming specific alternatives (delimit_agent_complete, delimit_agent_dispatch) and contexts (blocked executor, cross-model review). This gives unambiguous guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States read-only nature and underlying function call. No annotations exist, so description carries the burden; it adequately covers safety but lacks detail on error conditions or rate limits. Still strong given the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise and well-structured: purpose sentence, usage sections, sibling contrast, side effects. Every sentence earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, output schema present), the description covers all necessary aspects: purpose, usage, exclusions, side effects. Complete for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats the schema's parameter description (task_id optional, empty for all) without adding new semantics. No enhancement over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Check status of dispatched agent tasks' with a specific verb and resource. Distinguishes from sibling delimit_agent_dashboard by contrasting raw status records vs aggregate view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (monitor open/closed tasks) and when NOT to use (dispatch or complete tasks), naming specific sibling tools as alternatives. The sibling contrast further clarifies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses side effects (daemon thread spawn/halt, JSONL logging, config safeguards, premium gating). While comprehensive, it lacks details on error handling or concurrency behavior, but overall adds valuable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (purpose, when to use, when not, sibling contrast, side effects). Every sentence is informative and free of fluff, making it easy for an AI to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (daemon lifecycle, multiple parameters, safeguards) and the presence of an output schema for return values, the description covers all necessary aspects: spawning, stopping, logging, and respecting configuration. It is self-contained for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds marginal context (e.g., default interval of 15 minutes, loop_type options) but does not significantly enhance understanding beyond the schema's own descriptions. The side effects section links action values to behavior, which is helpful but not novel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool as a 'Background auto-pull daemon' for governed loops, which is specific and distinct from the one-shot 'delimit_build_loop' sibling. It uses strong verbs ('spawns', 'ticks') and defines the resource (governed build/social/deploy loops).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections are provided, with direct alternatives: 'delimit_build_loop' for one-shot and 'delimit_loop_status' for metrics. Sibling contrast further clarifies the choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool is read-only ('read-only on the project'), sanitizes the project path via _sanitize_path, and returns the bundle in response without writing to a file. While it could mention error handling or additional side effects, it provides key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, concise sentences, and no redundancy. Every sentence adds value, and the main purpose is front-loaded. It achieves maximum efficiency in communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, good schema coverage, and an output schema, the description covers all necessary aspects: purpose, usage, side effects, and return behavior. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter, project_path, is well-described in the schema with a default and explanation. Schema coverage is 100%, so the description adds minimal additional meaning beyond what the schema provides. No further elaboration is given, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Export the current governance config as a shareable JSON bundle.' It also distinguishes from siblings by explicitly naming delimit_config_import as the round-trip counterpart and delimit_gov_policy for reading live policy, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes dedicated 'When to use' and 'When NOT to use' sections, giving explicit scenarios: use for packaging config for sharing/import, not for reading live policy or initializing a project. It also contrasts with sibling tools, providing comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses side effects (creates venture directory and metadata files) and idempotency. It adds behavioral context beyond the schema, though it could mention error handling or output format, but output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single-sentence function statement followed by clearly labeled sections (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, no required), high schema coverage, and presence of output schema, the description covers purpose, usage, side effects, and idempotency. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the only parameter 'venture', so the baseline is 3. The description does not add meaning beyond the schema (it essentially repeats the schema's description). With high coverage, this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool initializes a context filesystem namespace for a venture, using specific verb and resource. It distinguishes from siblings by contrasting scope (venture vs conversation) and versioning (snapshot/branch).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('once per venture, the first time you want to persist cross-session/cross-model context') and when not to use, providing specific alternative tools (delimit_memory_store for single-session memory; delimit_context_read for reading artifacts). Also contrasts with sibling memory tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects as read-only and the internal call to ai.context_fs. With no annotations, the description does a fair job, though it could mention permissions or error handling. Still, it transparently describes behavior beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with structured sections (purpose, when to use, when not to, sibling contrast, side effects). Every sentence adds unique value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description covers all essential aspects: purpose, usage context, alternatives, side effects, and basic behavior. It is fully sufficient for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single required parameter 'venture' described as 'Venture namespace key. Required.' The description does not add additional semantic detail beyond what the schema already provides, which is adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all artifacts in a venture's context filesystem' with a specific verb and resource. It distinguishes from siblings like delimit_context_read (reads content) and delimit_memory_recent (scans memories), leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('to inventory what artifacts have been written') and when-NOT-to-use sections directly name alternative tools (delimit_context_read, delimit_memory_recent), providing clear decision guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It declares read-only side effects, gating by require_premium, and backend call. Lacks specifics like rate limits or response size, but output schema covers return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (when to use, not to use, sibling contrast, side effects). Every sentence is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and output schema, the description covers usage, behavior, and context adequately. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'target', including description. Description adds no extra meaning beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes projects for cost drivers, listing specific scans (Dockerfile, deps, cloud configs). It distinguishes itself from siblings delimit_cost_optimize and delimit_cost_alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' (investigating spend) and 'When NOT to use' (enacting reductions or managing alerts), with clear references to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the side effect: writing timestamped copies to a specific directory via a backend function. Could mention if it overwrites or is safe to run multiple times, but overall good transparency given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive: two sentences for the main action, followed by structured bullet points for usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with complete schema and existing output schema, the description covers purpose, when to use, and side effects, making it fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'target' is fully described in the schema. The description adds no extra semantics beyond the schema's explanation of the default and meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool backs up SQLite and JSON data files to a specific directory, distinguishing it from sibling tools that validate or migrate data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use (before risky migrations/refactors) and when not to use (for validation or migration), and names alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses 'Side effects: read-only on the target' and mentions the backend call, addressing the key behavioral trait. Output schema covers return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: 3 sentence blocks covering purpose, usage guidelines, sibling contrast, and side effects. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, no required fields, and presence of output schema, description fully covers purpose, when/how to use, and read-only behavior. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers the single parameter with description and default. Description adds context ('Directory or file path') but doesn't add meaning beyond schema. Baseline 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Validate data files: JSON parse, CSV shape, SQLite integrity.' It specifies the resource (data files) and actions (validate, parse, check integrity), distinguishing from siblings like delimit_data_migrate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' (smoke check before relying on data files) and 'When NOT to use' (for migration status or backups), naming alternatives delimit_data_migrate and delimit_data_backup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description details side effects: premium gating, network writes to container registry via backend. Lacks mention of reversibility but still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with headings (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence adds value; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, prerequisites, exclusions, sibling differentiation, side effects. Output schema exists, so return values are handled externally. Complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully (100%). Description only repeats schema text without adding new context about usage or defaults. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with clear 'Publish previously built images to the registry (Pro).' Then distinguishes from siblings deploy_build and deploy_verify, making the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after delimit_deploy_build) and when not to (building images or starting deploy chain). Also names sibling alternatives.
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 that it is a read-only scan with no writes, and mentions the backend used. Since no annotations are provided, this is crucial. However, it does not detail the exact return format beyond "catalog" or mention any performance/error behavior. Still, it is sufficiently transparent for a scanning 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and well-structured with four short, clear sections: main action, when to use, when not to use, sibling contrast, and side effects. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It adequately covers purpose, usage, side effects, and sibling differentiation. The only minor gap is not specifying file extension or prerequisites, but it is overall complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already fully describes both parameters (project_path and output_format). The tool description does not add any extra semantic meaning beyond what is in the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans a project for React/Vue/Svelte components and emits a catalog, which is a specific verb and resource. It distinguishes from siblings like delimit_design_generate_component (which creates one component) and delimit_story_generate (which generates stories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (inventory UI components for review, docs, design-system curation) and when NOT to use (to generate a single component or stories). Also names specific sibling alternatives, offering clear guidance on 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?
States 'Side effects: read-only' and mentions the backend call. Since no annotations exist, the description carries full burden. It is clear and honest, but could add more detail on error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections: purpose, usage guidelines, sibling contrast, side effects. Every sentence adds value and is front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two simple parameters, complete schema coverage, and an output schema, the description fully covers the tool's behavior, usage boundaries, and side effects. Nothing missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are already described in the input schema. The description does not add additional 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Diff two OpenAPI specs and list all changes (pure diff, no policy).' It uses a specific verb and resource, and distinguishes from siblings like delimit_lint and delimit_diff_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with alternative tools (delimit_lint for CI gate, delimit_diff_report for HTML report). Also provides sibling contrast.
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?
Discloses that the tool is read-only on inputs and only writes to disk when output_file is provided, plus details about HTML output. With no annotations, this covers key behavioral traits well, though rate limits or auth requirements not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise and well-structured with clear sections (purpose, when to use/not, sibling contrast, side effects). No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers all necessary context: usage, side effects, input spec types, and report contents. Complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds minimal extra semantics beyond the schema, but the side effects note provides useful context for output_file. Adequate for baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates a shareable API diff report with full analysis, and explicitly distinguishes from siblings delimit_lint and delimit_diff, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 specific alternative tools (delimit_lint for CI gate, delimit_diff for raw data), making it easy for the agent to select correctly.
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?
No annotations provided, but description discloses side effects: 'writes a markdown reference file via backends.ui_bridge.docs_generate.' It also clarifies that generation does not validate. Slightly lacks details on overwrite behavior or file location, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five concise sentences with clear sections (overall purpose, when to use, when not, sibling contrast, side effects). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with one parameter, no required fields, and presence of output schema, the description sufficiently covers purpose, usage, and side effects. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'target' with description in schema (100% coverage). The description does not add 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate a markdown API reference from source docstrings/JSDoc.' It specifies the verb (generate), resource (markdown API reference), and distinguishes from sibling delimit_docs_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' and 'When NOT to use' sections, contrasting with delimit_docs_validate for doc-quality validation. Also mentions sibling contrast.
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?
No annotations exist, so description carries full burden. It states 'read-only inspection' and mentions the backend call, revealing nondestructive behavior. Could add more detail on output format but output schema exists, so this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus structured sections (when to use, when NOT, sibling contrast, side effects). Every section earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, existing output schema, and no annotations, the description covers usage guidelines, side effects, sibling distinction, and internal call. It is complete for a simple validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (target) with full schema description (100% coverage). The description does not add new context beyond what the schema provides; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it validates documentation quality and completeness, listing specific examples (missing READMEs, undocumented functions, broken links) and directly contrasts with sibling delimit_docs_generate which writes. The verb 'validate' and resource 'docs' are clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (CI gate for surfacing issues) and when-not-to-use (avoid for generating API reference, recommending delimit_docs_generate). Also includes sibling contrast, making usage context very 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?
No annotations provided, but description states side effects are read-only on spec and governance state, and mentions underlying API call. Lacks detail on return format or error conditions, but sufficient for a non-destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured with clear sections for purpose, usage, exclusions, sibling contrast, and side effects. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 optional params, output schema exists), the description covers purpose, usage, side effects, and alternatives adequately for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with descriptions and defaults. Description adds minimal extra meaning beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks for API spec drift since last governance review. It uses a specific verb (check) and resource (drift). It also distinguishes from siblings by explicitly contrasting with delimit_lint and delimit_drift_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: when to use (scheduled cron compliance monitor) and when not (one-shot lint or historical drift). Names alternatives: delimit_lint and delimit_drift_history.
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 effects ('read-only on the evidence store'), access gating ('gated by require_premium'), and backend calls. However, it lacks details on the verification process (e.g., what happens on tamper detection) and any potential error states. Without annotations, it carries full burden but does a solid job.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (6 lines) and well-structured with clear sections: purpose, when to use/not use, sibling contrast, and side effects. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a verification tool with an output schema, the description adequately covers purpose, usage, side effects, and sibling relationships. It leaves no major gaps given the existing schema and tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 does not add extra meaning beyond the schema's parameter descriptions. It mentions bundle_id and bundle_path in the usage context but does not clarify semantics like format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Verify the integrity of an evidence bundle.' It specifies the verb (verify), the resource (evidence bundle), and distinguishes it from siblings like delimit_evidence_collect and delimit_ledger, ensuring the agent knows exactly what the tool does and how it differs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('replay or audit') and when not to use ('to capture new evidence' or 'to query the contract ledger'), with specific alternatives provided (delimit_evidence_collect, delimit_ledger). This gives clear guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It details side effects: writes many new files, coerces packages from comma string to list, no license gate, no ledger write, no notification, and backend-determined collision behavior. This is thorough, though it could explicitly state that it's a write operation (implicitly clear).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when to use, when not to use, sibling contrast, side effects) and is concise at around 100 words. Each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (project scaffold with side effects) and the presence of an output schema (so return details are covered), the description provides sufficient context: side effects, error conditions (malformed packages), collision behavior, and prerequisites. It is complete for an agent's decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context beyond the schema: explains the coercion of the `packages` parameter from comma string to list and that malformed values short-circuit, and clarifies that `name` becomes the root directory. This adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Lay out a fresh project tree with framework-conformant skeleton.' It clearly identifies the verb (lay out) and resource (fresh project tree), and distinguishes from sibling tools like delimit_generate_template by specifying that this writes a new project tree rather than a single file into an existing project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance (project zero, new app/service/library) and when-not-to-use guidance (adding files to existing project, duplicating, adding packages). It lists alternative tools (delimit_generate_template, shell, package manager) and mentions a typical follow-up (delimit_init).
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 no annotations, the description thoroughly explains side effects: licensing gating (require_premium), backend invocation, writing a task record with specific fields, and response routing. It also notes the record carries title, scope, risk_level, repo path, and timestamp. This is full disclosure beyond what annotations would 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when to use, when not, side effects). It is longer than minimal but every sentence adds value, providing necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and parameter descriptions are complete, the description covers the pipeline context, licensing, and side effects. It is sufficiently complete for an agent to understand the tool's role and effects, though the output schema details are not repeated (not required).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 context for the pipeline but does not significantly enhance parameter meaning beyond what the schema already describes (e.g., 'scope: Description of what the task covers'). It meets the baseline without exceeding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Create a governance-classed task with risk tier and scope (Pro).' This provides a specific verb (create), resource (governance-classed task), and key differentiating attributes (risk tier, scope). It distinguishes from siblings like delimit_ledger_add and delimit_gov_evaluate, earning a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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, stating the exact condition (after delimit_gov_evaluate returns 'gating required') and listing alternatives for free-form work (delimit_ledger_add) and other pipeline steps (delimit_gov_run, delimit_gov_verify). This provides comprehensive 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?
No annotations provided, so description alone must disclose behavior. It explicitly states 'Side effects: read-only' and names the backend call. This is clear and useful, though it does not describe output format or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with front-loaded purpose, then clear usage sections, sibling contrast, and side effects. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, description need not explain returns. It covers purpose, usage, side effects, and sibling differentiation completely for a simple 1-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the input schema already defines the 'repo' parameter well. The description only reiterates 'for a given repo' without adding new semantics or constraints. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Report governance state (open tasks, decisions) for a repo,' using a specific verb and resource. It clearly distinguishes itself from sibling delimit_gov_health by stating that this tool reports per-repo workload, while health reports the engine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with direct alternatives (delimit_gov_health, delimit_gov_evaluate). Also provides sibling contrast in a dedicated line.
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?
States 'Side effects: read-only' and even mentions the underlying API call 'ai.handoff_receipts.get_receipts', which provides transparency beyond the lack of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise and well-structured: purpose first, then usage guidelines, sibling contrast, and side effects. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the context (output schema exists, parameters fully described in schema), the description covers all essential aspects: purpose, usage, side effects, and parameter guidance. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter descriptions (status with default and possible values). Description adds no extra semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'session handoff receipts'. It distinguishes itself from siblings by contrasting with create and acknowledge 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use (at session start to see pending handoffs, audit acknowledged ones) and when not to use (create or acknowledge), with specific sibling tool names.
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?
Since no annotations are provided, the description fully discloses side effects: writes a frozen marker and causes subsequent writes to be rejected. While it could mention prerequisites like dataset existence, the provided behavior is clear and sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: purpose, usage guidelines, sibling contrast, and side effects. Every sentence adds value and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema, the description covers purpose, usage, side effects, and sibling differentiation comprehensively. No missing information that would hinder correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description does not add extra meaning beyond the schema for the single parameter dataset_id, which is already well documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'freeze' and the resource 'dataset', and explains the purpose of making it immutable for replay integrity. It also distinguishes from siblings by contrasting with delimit_intel_dataset_list and delimit_intel_dataset_register.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use (evidence or signed attestation) and when-not-to-use (delete or inspect), including alternative tool recommendations. This offers strong guidance for correct invocation.
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?
No annotations provided, so the description carries full burden. It states 'read-only' and 'Calls backends.gateway_core.query_ledger,' which is good. It also mentions integrity verification. However, it does not cover potential rate limits or authorization requirements, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: main purpose first, then usage guidelines, sibling contrast, and side effects. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and presence of an output schema, the description covers all needed aspects: purpose, usage boundaries, side effects, parameter hints, and integrity check. It is complete for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds little beyond the schema; it mentions 'filter by API name' and integrity verification related to validate_chain. The added value is minimal, hence a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool queries the append-only contract ledger (hash-chained JSONL). It differentiates from sibling tools like delimit_ledger_list (reads work items) and delimit_audit (reads audit logs), 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (read/audit contract ledger) and when NOT to use (project work ledger, use delimit_ledger_list/query). Also provides sibling contrast, helping the agent choose correctly.
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?
No annotations are provided, so the description carries full burden. It discloses side effects (writes config via ai.loop_engine.loop_config) and behavior (only applies non-zero/non-empty values). Lacks details on error handling or auth, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with structured sections (When to use, When NOT, sibling contrast, side effects). Front-loaded with purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no required fields, and presence of output schema, the description provides sufficient context for correct usage. Covers usage context, alternatives, side effects, and key parameter behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description summarizes key parameters (max iterations, cost cap, etc.) but does not add meaning beyond what schema descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Configure') and resource ('autonomous build loop safeguards'). It explicitly distinguishes from siblings by naming delimit_loop_status and delimit_build_loop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use ('BEFORE starting a loop session') and when-not-to-use (for metrics or driving the loop), with explicit alternative tool names.
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?
Discloses side effects as 'read-only on the ledger' and mentions possible return actions (BUILD, CONSENSUS, STOP) including safeguard tripping. With no annotations, this provides good behavioral context, though could detail more about caching or concurrency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headings (When to use, When NOT to use, Sibling contrast, Side effects), front-loaded with the main purpose, and concise without superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage context for a loop fetch, mentions return actions (covered by output schema), and with 0 required parameters, the description is comprehensive enough 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions are adequate. The description doesn't add extra parameter-specific details beyond the schema, so it meets the baseline but doesn't exceed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get the next task to work on with safeguard checks' and contrasts with siblings delimit_task_complete (mark done) and delimit_ledger_list (list all), making the purpose specific 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('inside a loop session') and when NOT to use ('to mark a task done' or 'list all tasks'), along with sibling contrasts, giving clear usage boundaries.
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?
No annotations provided, so description carries full burden. It discloses read-only nature, gating requirement (require_premium), and the backend call (backends.os_bridge.check_gates). While very informative, it could mention potential latency or error handling; still above average.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured, with clear sections (purpose, when to use, not to use, sibling contrast, side effects). Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values need not be described), the description covers purpose, usage context, behavioral traits, and backend details comprehensively for a check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (plan_id) already described. Description adds no extra semantic detail beyond reinforcing it's for a specific plan. Baseline 3 applies as description doesn't significantly enhance schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks governance gates for an OS plan (Pro). It uses a specific verb "Check" and identifies the resource. It explicitly distinguishes from siblings delimit_os_status and delimit_gov_health, earning a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 with named sibling alternatives for when not to use, offering clear decision support for the agent.
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 annotations provided, the description fully carries the burden. It discloses that the tool triggers init (writes .delimit/) and runs a scan (read-only), and detects the environment. This reveals both write and read side effects. It lacks details on auth or rate limits, but these are less critical for a quickstart 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and well-structured with labeled sections for purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence adds value, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter with schema 100% coverage, output schema exists), the description is complete. It covers purpose, usage guidelines, side effects, and distinguishes from siblings. The agent has all necessary context 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, project_path, is fully documented in the schema with default and description (100% schema coverage). The tool description does not add meaningful semantics beyond the schema; it only implies the path is for the project to quickstart. Thus 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose as a '60-second guided quickstart for a new install' that combines init, scan, and environment detection. It clearly distinguishes itself from sibling tools delimit_init, delimit_scan, and delimit_activate by contrasting their narrower scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to use' (immediately after install) and 'When NOT to use' (for activation or diagnostics) guidance, and even names alternative tools delimit_activate and delimit_diagnose. This gives the agent clear decision 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?
Discloses side effects as 'read-only on git/repo state', gated by require_premium, and internal call to backends.tools_infra.release_plan. With no annotations provided, this adds necessary behavioral context, though could elaborate on 'read-only' implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise single paragraph with front-loaded purpose, clear usage guidelines, and transparency info. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 optional params, output schema present), the description covers purpose, usage, side effects, and access requirements comprehensively. Completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds no extra parameter info beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Generate a release plan from git history (Pro)', with a specific verb and resource. It contrasts with siblings (delimit_release_validate, delimit_deploy_publish, delimit_deploy_plan) to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use ('ahead of cutting a release') and when not to use ('to validate readiness' or 'to ship code'), naming alternative tools. Also contrasts with delimit_deploy_plan for single-app deploys.
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?
Discloses side effects: 'read-only network call via the driver'. Since no annotations are provided, the description carries the full burden and provides useful behavioral context. Could be improved by mentioning error handling or rate limits, but still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with intro, usage guidelines, sibling contrast, and side effects. Every sentence is informative and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers purpose, usage, side effects, and sibling differentiation completely. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, only contextualizing that identifier fetches a single item.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a specific resource from a connected data-plane system'. It distinguishes from siblings by noting delimit_resource_list returns many and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (fetch single item by identifier per driver for repo/PR/issue/workflow run) and when not to use (listing, inventory drivers), with specific alternative tools named.
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?
Discloses side effects: gated by require_premium, launches headless Chromium, writes PNG to specific path. No annotations provided, so description carries full burden; lacks mention of rate limits but addresses key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief, well-structured with labeled sections (when to use, when not, sibling contrast, side effects). Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema existence, description covers purpose, usage boundaries, side effects, and sibling contrast. Sufficient for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description does not add extra meaning beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Take a screenshot of a URL using headless Chromium (Pro)', specifies the action, resource, and technology. Contrasts effectively with sibling delimit_screen_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use (audit evidence, visual regression, documentation) and when NOT to use (time-based recordings, rendered HTML), naming the alternative sibling 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?
No annotations are provided, so the description carries the full burden. It states 'Side effects: read-only' and 'Calls ai.secrets_broker.get_access_log,' which explicitly discloses read-only nature and internal call. However, it does not mention authentication or rate limits, but the read-only and internal call details are sufficient for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with six sentences. It is well-structured: purpose first, then usage guidelines, sibling contrast, and side effects. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description fully covers purpose, usage, contrast, and side effects. It provides sufficient context 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described. The schema already states 'Optional secret name to filter the log. Empty = all secrets.' The description does not add additional meaning beyond this, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Show the audit log of secret accesses.' It explicitly distinguishes from siblings by stating what not to use it for (reading secret values or inventorying secrets) and contrasting with delimit_secret_get which appends to the log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios (compliance review, incident investigation, seeing who fetched a credential) and when-not-to-use with alternative tool names (delimit_secret_get, delimit_secret_list). Also includes sibling contrast for additional clarity.
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 declares 'Side effects: read-only' and mentions the backend call 'backends.gateway_core.run_semver'. This provides key behavioral insight beyond what is in the schema or annotations. However, it does not detail error conditions or rate limits, but given the simplicity, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first sentence states purpose, followed by usage guidelines, sibling contrast, and side effects. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's straightforward nature, the description covers purpose, usage, side effects, and backend dependency. It is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents parameters well. The description adds minimal extra context (e.g., 'optionally computing the next version string' for current_version), which does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Classify a spec change's semver bump (MAJOR/MINOR/PATCH/NONE).' It also distinguishes from siblings like delimit_diff and delimit_lint by specifying that this tool only maps the diff to a semver verdict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 alternative tool names (delimit_lint, delimit_diff). It also explains the optional computation of the next version string.
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 annotations provided, the description fully carries the burden. It declares the tool is read-only and specifies the underlying call (ai.ledger_manager.session_history). It does not cover auth or rate limits, but for a simple read operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with each sentence providing value. It uses clear sections (When to use, When NOT to use, Sibling contrast, Side effects) and front-loads the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only), the description covers purpose, usage guidance, sibling differentiation, and side effects. An output schema exists, so return value details are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional parameter details beyond what the schema already provides (limit with default 5).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads recent session handoffs for context recovery, using a specific verb and resource. It distinguishes from siblings like delimit_session_handoff (writes) and delimit_revive (reads soul state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 to review previous sessions) and when not to use (for writing handoffs or richer cross-model state), with direct sibling alternatives. This provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes side effects (action='start'/'stop' mutate daemon state) and internal calls to ai.social_daemon.* methods. With no annotations, additional details about daemon behavior (scans, deduplicates, emits emails) provide good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Multi-paragraph but every sentence adds value; front-loaded with purpose, then usage, then contrast, then side effects. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single simple parameter, presence of output schema, and rich behavioral context in description, all necessary information is covered (purpose, usage, side effects, internal calls).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description already documents the action parameter. Description adds no new meaning beyond enumerating values already in schema directive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool controls the social sensing daemon (start/stop/status) and distinguishes from sibling delimit_social_target (one-shot scan). Verb+resource with specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use and when NOT to use, naming alternatives (delimit_social_target, delimit_notify_inbox). Includes sibling contrast.
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?
No annotations provided, so description carries full burden. It states 'read-only / draft' and calls 'ai.social.generate_post', explaining side effects. Slightly brief but sufficient for this simple 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: purpose first, then usage guidelines, sibling contrast, side effects. Concise at 3-4 sentences with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an existing output schema, the description covers all necessary aspects: purpose, usage, side effects, and sibling differentiation. Complete for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (category) with 100% schema coverage. The schema already describes it well, and the description adds no extra 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/5Does 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 and explicitly says 'no posting'. It distinguishes from siblings like delimit_social_post (publishes) and delimit_social_target_config (manages targets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('to draft a tweet for review') and when not to use ('to actually publish'), with direct tool alternatives (delimit_social_post, delimit_content_publish). Sibling contrast further clarifies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It declares read-only side effects and mentions the underlying API call (ai.social.get_post_history). It also notes that Reddit entries include thread context. This is sufficient for a read operation, though more detail on rate limits or authentication could improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with clear sections for purpose, usage, sibling contrast, and side effects. Every sentence adds value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and high schema coverage, the description provides adequate context: use cases, alternatives, side effects, and a behavioral detail about Reddit thread context. It is complete for a read-only tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented. The description adds some context by mentioning that Reddit entries include thread context, but does not detail individual parameters beyond what's in 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it views recent social media post history, specifying the verb 'view' and resource 'recent social media post history'. It distinguishes from sibling tools like delimit_social_generate and delimit_social_post, making the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections provide clear guidance, including specific alternatives (delimit_social_generate for drafting, delimit_social_target for scanning). The sibling contrast further clarifies when to use this tool versus others.
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 annotations provided, the description carries the full burden. It discloses being read-only, calls a specific backend, and works on OpenAPI 3.x or Swagger 2.0. It does not mention potential limitations like file size or timeout, but given the simplicity of the operation, these are minor omissions. Overall, it provides sufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: main action, when to use, when not to use, sibling contrast, side effects, and compatibility. Every sentence is meaningful and contributes to the agent's understanding. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers all necessary aspects: purpose, usage context, parameter specification, side effects, and compatibility. The presence of an output schema reduces the need to describe return values. The description is fully sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter 'spec' with a schema description that already explains it as a path to an OpenAPI spec file. The description does not add new information beyond confirming it's a file path in YAML or JSON. Since schema coverage is 100%, the baseline is 3, and the description adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scores an OpenAPI spec on quality dimensions with a grade (0-100, A-F). It explicitly distinguishes from siblings: delimit_lint compares two specs, delimit_diff gives raw diff, while this tool scores one spec on its own merits. This leaves no ambiguity about the tool's 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (quick spec quality checks during onboarding or review for completeness, security, etc.) and when-not-to-use (as a breaking-change gate or raw diff, with specific alternatives delimit_lint and delimit_diff). This gives the agent clear decision 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?
No annotations are provided, so the description carries full burden. It declares 'read-only static analysis' and specifies the backend call, making the behavioral intent clear. Lacks mention of permissions or rate limits, but the core safety is well-communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, separate sections for usage, exclusions, sibling contrast, and side effects. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, output schema exists), the description is complete: it provides purpose, explicit usage boundaries, sibling differentiation, behavioral side effects (read-only), and backend reference. The output schema covers return values, so no need for that here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no further detail on project_path or standards beyond what the schema provides, though it lists example issues checked, which indirectly informs parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans HTML/JSX/TSX for WCAG accessibility issues, using a specific verb ('Scan') and resource. It distinguishes itself from siblings delimit_design_validate_responsive (layout) and delimit_story_visual_test (visual regression).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (as a CI gate or pre-merge check for common a11y problems) and when not to use (responsive layout, visual regression), naming specific sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects (invokes test runner via subprocess, read-only on filesystem) and auto-detection of frameworks. Lacks some detail on failure handling or output format, but given no annotations, this 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise and well-structured with separate sections for usage, exclusions, sibling contrast, and side effects. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: purpose, when/not to use, side effects, and sibling distinction. Output schema exists, so return format explanation is not needed, making the description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and parameter descriptions are sufficient. The description adds value with the auto-detection note but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Run smoke tests for a project' with specific verb-run and resource-tests. Differentiates from siblings by naming delimit_test_generate and delimit_test_coverage, providing a precise 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly defines when to use (pre-commit/pre-deploy gate) and when not to use (scaffolding tests, measuring coverage) with sibling alternatives. Offers unambiguous 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?
Since no annotations exist, the description carries the full burden. It discloses side effects: read-only on GitHub (network calls via gh CLI) and writes context entries into the ledger without pushing back. This covers key behaviors. A minor gap is lack of detail on failure modes or response format, but output schema handles return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly structured with clear sections: main purpose, when to use, when not to use, sibling contrast, side effects. Every sentence adds value, no fluff. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (none required), no annotations, but an output schema, the description fully covers purpose, usage guidelines, behavioral side effects, and sibling differentiation. No additional information seems necessary 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters have descriptions in the schema. The tool description does not add extra meaning beyond the schema, consistent with the baseline of 3 for high coverage. No additional context is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pulls open GitHub issues into the Delimit ledger as context. It uses a specific verb ('Pull'), resource ('open GitHub issues'), and outcome ('into the Delimit ledger as context'). The sibling contrast with delimit_sensor_github_issue further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections are provided, with clear guidance: use to enrich ledger with external issue context, avoid for write-back to GitHub or monitoring a single issue (use sibling instead). This directly addresses selection among 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?
No annotations provided, but description discloses read-only nature and potential Python subprocess invocation. Lacks details on error cases or performance, but covers key 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded purpose, with clear sections for usage, contrast, and side effects. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers purpose, usage, side effects, and sibling distinction. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description does not add meaning beyond schema; parameters are already well-documented in input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Extract' and resource 'OpenAPI spec from framework source code'. It distinguishes from siblings by contrasting with delimit_lint and delimit_diff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' (no checked-in spec) and 'When NOT to use' (spec exists, use alternatives). Also lists supported frameworks and future plans.
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?
Given no annotations, the description carries full burden. It discloses side effects (writes via ai.agent_policy.set_agent_policy, empty/no-changes is read-only) and explains access level values. However, it does not mention rate limits, auth requirements, or output format, but for a config tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when to use, when not to use, sibling contrast, side effects, parameter details). It is front-loaded with the main purpose and concise without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, side effects, and parameter semantics. With an output schema present, return values need not be detailed. The description adequately addresses the tool's complexity and provides sufficient context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters (ledger/memory/evidence as access levels with 'read-only', 'read-write', 'none'; deploy/secrets as boolean flags; custom_constraints as comma-separated) and clarifying allowed values beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set or view per-model governance permissions' with a specific verb and resource. It distinguishes itself from sibling tools like delimit_gov_evaluate and delimit_project_config by explaining their different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (inspect or modify per-model policy) and when not to use (runtime evaluation or session policy), with specific alternative tool names (delimit_gov_evaluate, delimit_project_config).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses side effect (file creation under ~/.delimit/context/<venture>/) and notes that artifact_type only affects render hints. Could mention overwrite behavior or size limits for a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence serves a purpose: action, when-to, when-not-to, sibling contrast, side effects. No extraneous words; front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, side effects, and sibling differentiation. Output schema exists but is not shown; description does not need to return values. Missing concurrency or error details, but sufficient for a write tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds value by explaining that artifact_type affects render hints but not storage format, and implies name is the file key. Adequately complements schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Write' and resource 'artifact to a venture's context filesystem', clearly distinguishing from siblings like delimit_context_read, delimit_context_list, and delimit_context_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (persist plans/decisions/code for future sessions) and when not to (ephemeral context, snapshot all), with named alternatives: delimit_memory_store and delimit_context_snapshot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully addresses behavior: license check, local version bump, prepublishOnly hook, pack, network publish, irreversibility, and dry_run effects. Mentions a known regression.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headings and bullet points, front-loaded purpose, and minimal redundancy. Slightly long but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (4 params, output schema present, no annotations), description thoroughly covers all aspects: purpose, usage guidelines, behavioral side effects, parameter effects, and output context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, so baseline is 3. Description adds context about dry_run suppressing only publish step, but does not significantly extend beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Publish an npm package: version bump, pack, and push to registry' with specific verb and resource. Distinguishes from siblings like delimit_deploy_site and delimit_deploy_publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly defines when to use (ship new npm package version), when not to use (deploy site, push containers, dry-run locally), and provides alternatives. Also specifies prerequisite chain and founder approval requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses all key behaviors: license gating, path sanitization, local git operations, network trigger, ChatOps env injection, and that no rollback is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when to use, siblings, side effects). Slightly verbose but front-loaded. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and moderate complexity, description covers all necessary context: purpose, usage, side effects, alternatives, and safety checks. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions. Description adds no new meaning beyond schema: path sanitization detail is already in schema description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ships static/Next.js sites via git push to Vercel, with specific verb and resource. It distinguishes from sibling deploy tools (npm, publish, rollback).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (deploy UI/site changes) and when NOT to use, listing alternatives. Also pairs with delimit_deploy_verify for post-deploy health check.
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?
Details side effects: read-only scan, auto-activation of Figma API based on token presence, calls backend function, and coercion of token_types via _coerce_list_arg. Since no annotations exist, the description fully discloses 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four main sections: action, when to use, when not to use, and side effects. 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context indicates true), the description does not need to explain return values. It covers purpose, usage, and side effects adequately. Minor gap: no mention of error handling or empty results, but the output schema likely addresses this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about token_types values and coercion, but does not significantly extend meaning beyond the schema for figma_file_key or project_path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Extract design tokens from a project's CSS/SCSS/Tailwind config.' This is a specific verb (extract) and resource (design tokens from specific file types), and it later distinguishes from sibling tools like delimit_design_generate_tailwind.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' and 'When NOT to use' sections, naming alternatives such as delimit_design_generate_component and delimit_design_generate_tailwind. Also includes a 'Sibling contrast' paragraph for differentiation.
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?
No annotations are provided, so the description carries full burden. It discloses 'Side effects: read-only network' and details a required tool chaining rule after scanning, which gives clear behavioral expectations for the AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage, siblings, side effects, tool chain). It is somewhat verbose but 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-cadence scanning, post-processing requirements) and presence of an output schema, the description covers all necessary context: purpose, when/not to use, sibling differentiation, side effects, and mandatory chaining instructions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (cadence and limit). The description does not add substantial new meaning beyond the schema, but it does mention cadence values briefly. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Scan GitHub for adoption leads, competitive intel, repo health'. It uses a specific verb (scan) and resource (GitHub), and differentiates from siblings by naming delimit_sensor_github_issue and delimit_tracker_sync.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance (at configured cadence: pulse, hunter, deep) and when-NOT-to-use (monitor one issue or pull issues), with references to alternative tools. The sibling contrast section further clarifies usage 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?
In absence of annotations, the description fully discloses side effects (read-only vs gated actions), error determinism, short-circuit behavior, and backend routing with premium licensing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, each sentence adds value, though length is justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, 7 actions, no annotations, and presence of output schema, the description covers all aspects: action mapping, licensing, error behavior, and parameter usage conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter's usage condition already described; description adds grouping context but does not significantly enhance beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this is a unified governance entry point dispatching to seven actions, and distinguishes itself from sibling aliases by explaining they are thin wrappers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (single MCP surface, pick action by name) and when not to use (internal code paths, prefer specific alias), with clear 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?
With no annotations, description fully discloses side effects: require_premium gating, writes verification record (verdict, timestamp, repo, policy snapshot), and that it does not perform additional work. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear headings and front-loaded purpose. Slightly lengthy due to detailed side effects, but every sentence earns its place. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in a governance pipeline, the description covers prerequisites (pipeline step, license), side effects, and contrast with alternatives. Output schema exists, so no need to describe return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description does not add extra meaning beyond what the schema already provides for task_id and repo.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Starts with a specific verb+resource: 'Attest that a governance task completed under policy'. Clearly distinguishes from siblings like delimit_gov_new_task, delimit_gov_run, and delimit_evidence_verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 alternatives and provides contrast with sibling tools, including a sibling outside the gov family (delimit_evidence_verify).
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?
No annotations provided, but description fully discloses it is READ-ONLY, inspects specific files/env, has no side effects, and details the verdict structure and checks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, though slightly verbose. Every sentence adds value, but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a pre-flight tool: describes checks, verdict, side effects, and usage context. Output schema exists to provide further detail on return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (project_path) with 100% schema coverage; description does not add extra 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/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it validates cross-agent handoff invariants before switching coding agents. Distinguishes from siblings like delimit_revive, delimit_gov_health, and delimit_repo_diagnose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' and 'When NOT to use' sections with alternatives and context (Phase-1, not wired into live handoff).
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?
No annotations exist, so the description fully covers behavioral traits. It details side effects (start/stop mutate daemon state), daemon polling interval (5 minutes), classification, forwarding, draft approval handling, auto-posting being disabled, and gateway-only backing module behavior. This is comprehensive and exceeds minimal requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, usage guidelines, sibling contrast, side effects, and daemon behavior. Each sentence adds value, though the initial 'Pro' qualification is slightly redundant. Overall, it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter, no annotations, and an output schema, the description provides complete context: purpose, usage guidelines, behavioral details, and daemon internals. The output schema exists and is not described, which is acceptable per rubric. The description fully compensates for lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'action' that has a clear description and default. The description mentions action values in the side effects section but does not add substantial meaning beyond the schema. Baseline of 3 is appropriate as schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Control the inbox polling daemon for email governance (Pro).' It specifies the verb 'control' and the resource 'inbox polling daemon.' It distinguishes from sibling 'delimit_notify_inbox' which reads inbox items, establishing a clear, distinct 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections are provided. Use is advised at session start or to stop/inspect; explicitly warns against using for reading inbound items (directing to delimit_notify_inbox) or sending notifications (delimit_notify). This provides clear, actionable 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?
No annotations provided, so description must carry full burden. Discloses side effects (writes snapshot record) and internal coercion behavior (_coerce_dict_arg). Could add more detail on idempotency or error handling, but current detail is above average.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Structured into clear, labeled sections: purpose, when to use, when not to use, sibling contrast, side effects. No redundant sentences; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and only 2 parameters, description covers purpose, usage, side effects, and input behavior. Sufficient for agent to use correctly without additional clarification needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining coercion from JSON strings to dicts, which is not in schema descriptions. Enhances understanding of flexibility for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'store'/'ingest' and resource 'research snapshot with provenance'. Explicitly contrasts with sibling tools: 'delimit_intel_dataset_register declares; delimit_intel_query reads; this writes new snapshots.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' (ingest research/signal data) and 'When NOT to use' (register dataset or query), with direct references to alternative tools. Excellent 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?
Given no annotations, the description fully compensates by detailing side effects: with dry_run=False archives items via bulk_action(archive), never hard-deletes (JSONL log retains record), and dry_run=True returns plan only. This covers safety, idempotency, and data retention 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and front-loaded purpose. While thorough, it is slightly longer than necessary; a bit more compaction could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, an output schema, and no annotations, the description covers usage, side effects, sibling contrasts, and default behaviors comprehensively. Nothing critical is missing for an automation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters. The description adds minimal extra value beyond the schema, mainly clarifying default threshold source and dry_run behavior. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource statement: 'Auto-archive open ledger items dormant past the stale-TTL threshold.' It then differentiates from siblings like delimit_ledger_groom, delimit_ledger_auto_close_external, and delimit_ledger_bulk, making the tool's specific 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/5Does 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 highlight appropriate scenarios, such as nightly automation, and warn against using it for inspection or external repo items. Sibling contrast further clarifies the distinction between propose-only, close-external, and raw bulk action 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?
Despite no annotations, the description thoroughly explains side effects: writes status/priority/tag changes when dry_run=False, per-item failures don't block batch, default dry_run=True returns would_change, and callers must explicitly pass dry_run=False to apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, well-structured with clear sections (When to use, When NOT, Sibling contrast, Side effects), and front-loads the core purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, dry_run behavior, batch resilience, and output format (would_change vs changed). Minor gap: the 'action' parameter values are referenced as 'the actions above' but no list is provided, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented in the schema. The description adds little per-parameter detail beyond reinforcing dry_run and action semantics, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Apply', the resource 'ledger items', and the scope 'bulk', distinguishing it from siblings like delimit_ledger_update (single item) and delimit_ledger_groom (proposes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections, with alternatives named (delimit_ledger_update, delimit_ledger_done), providing clear context 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?
With no annotations provided, the description bears full burden for behavioral disclosure. It states 'Side effects: read-only' and references the internal call (ai.ledger_manager.list_items). While it mentions back-compat for single-value filters, it lacks details on pagination behavior or rate limits. Nonetheless, it is largely transparent about the tool's non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections ('When to use', 'When NOT to use', 'Sibling contrast', 'Side effects'). Every sentence adds value without redundancy, achieving high efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, many optional) and the presence of an output schema, the description adequately covers the core purpose, filtering richness, and sibling relationships. It could mention pagination cursor behavior, but overall it provides sufficient context for an agent to make an informed selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, setting a baseline of 3. The description adds value by summarizing filter capabilities (by status, priority, tags, text, time window, external link) and noting that single-value status/priority are kept for back-compat, improving understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List ledger items with rich filters, sort, and pagination', providing a specific verb and resource. It distinguishes from siblings by explicitly naming alternatives (delimit_ledger_context for top-5 summary, delimit_ledger_query for single item), establishing a unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to use' with examples of filters (status, priority, tags, etc.) and 'When NOT to use' with alternative tool names. This provides clear guidance on appropriate contexts, satisfying the dimension.
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?
No annotations provided, so description carries full burden. Explicitly declares side effects: 'read-only analysis (does NOT auto-create ledger items)', making the non-mutating behavior clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with separate sections for purpose, when to use/not use, sibling contrast, and side effects. Every sentence is informative and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, description covers when to use, side effects, and differentiators. Could be more specific about what 'signals, completed work, and gaps' means, but otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description mentions 'suggest 3-5 next items' which loosely aligns with max_items default, but adds no additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb ('Propose'), resource ('new ledger items'), and context ('based on signals, completed work, and gaps'). Distinguishes from sibling delimit_ledger_add by noting that this proposes while the sibling commits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('at the end of a build loop or when the queue is empty') and when NOT to use ('to add a known item' or 'list current items'), with clear sibling alternatives named.
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?
No annotations provided, but the description discloses side effects (writes via backends.memory_bridge.store), free tier status, and hot_load behavior, fully compensating for lack of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the core function, but includes some technical detail (e.g., 'backends.memory_bridge.store') that could be slightly trimmed. Still clear and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers purpose, usage guidelines, side effects, and sibling contrast, making it complete for a store operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions, so the description does not add additional meaning beyond what the schema already provides. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Store a memory entry for future cross-session retrieval (Free tier)', providing a specific verb and resource. It distinguishes from siblings delimit_memory_search and delimit_memory_recent, achieving high purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists 'When to use' and 'When NOT to use' scenarios, including alternatives like git for routine code changes and delimit_context_write for venture-scoped artifacts, offering excellent 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?
With no annotations, the description carries full burden. It discloses side effects: 'sends a network message via webhook (JSON POST), Slack webhook, or email (SMTP).' It explains the email reply flow and that replies are consumed by sibling tools. However, it does not mention error handling, rate limits, or permissions, which would raise transparency to a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings and bullet points, front-loading the core purpose. It is verbose but necessary given the complexity (11 parameters, multiple channels, draft system). Minor redundancy exists (e.g., channels listed twice), preventing a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, output schema exists), the description covers all essential aspects: purpose, usage guidelines, side effects, auto-trigger rule, channel specifics, email context rules, and draft system. It references sibling tools and provides enough detail for an AI agent to decide when and how to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant context beyond schema parameter descriptions, such as email formatting rules ('Subject: lead with [ACTION TYPE] bracket'), auto-trigger instructions, and draft registration behavior. It does not, however, provide detailed syntax for every parameter, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Send a notification (webhook / Slack / email).' It specifies the verb 'send' and the resource 'notification', and contrasts with sibling tools delimit_notify_routing (configures rules) and delimit_notify_inbox (reads inbound), providing strong differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when the orchestrator identifies something that requires owner action — outreach reply, deployment decision, approval needed.' It also specifies when not to use: 'for SIEM-class structured streaming (use delimit_siem) or multi-routing config (delimit_notify_routing).' The auto-trigger rule instructs to 'call immediately, never ask,' providing clear decision 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?
No annotations provided, so description carries full burden. Discloses side effects: calls ai.multi_review, may write saved record, returns comment body (no auto-post). Could mention failure modes or permissions, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: first sentence states purpose, then bullet-like sections for usage, sibling contrast, side effects. Concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, side effects, and parameter context. Output schema exists, so return details not needed. Lacks prerequisites or error handling, but adequate for a review tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by clarifying that diff takes priority over file_path, which is not in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Run a multi-model code review') and the resource ('a diff or file'). It distinguishes from siblings by naming delimit_audit for structured lenses and delimit_deliberate for debate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 clear alternative tools (delimit_audit, delimit_deliberate) and context for PR comments.
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?
No annotations provided, so the description bears full burden. It discloses side effects (writes a handoff record via ai.ledger_manager.session_handoff) and behavioral details (coerces list inputs from comma strings). While it doesn't cover auth needs or rate limits, it provides significant context beyond the schema. A score of 4 is appropriate for missing some details like overwrite 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only a few sentences to convey purpose, usage, sibling contrast, and side effects. It is well-structured with clear headings (When to use, When NOT to use, Sibling contrast, Side effects) and front-loaded with the primary action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, output schema exists, no annotations), the description covers purpose, usage guidelines, sibling distinction, and a behavioral quirk (coercion). It does not explain persistence details or if it overwrites previous handoffs, but the output schema likely fills gaps. Overall, it is quite complete for an AI agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that list parameters are coerced from comma strings via _coerce_list_arg, which helps the agent understand input flexibility. This goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The tool clearly states it saves a session summary for cross-session continuity. It distinguishes itself from siblings (delimit_soul_capture and delimit_memory_store) by specifying it writes a structured handoff with explicit fields, while soul_capture writes a richer soul with git state and memory_store handles single-line memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (at the end of a productive session) and when not to use (for richer cross-model state or single-line memory), with clear alternatives (delimit_soul_capture and delimit_memory_store). This is exemplary guidance for an AI agent.
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?
Discloses side effects: read-only by default, conditional calls to other tools when flags are set, and deduplication across runs. Also details tool chaining requirements. While no annotations exist, this provides sufficient behavioral insight for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for purpose, usage, contrast, side effects, and chaining rules. Minor repetition of '/loop' guidance, but overall efficient and front-loaded with key purpose and usage guidelines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: purpose, when to use/not, sibling differentiation, side effects, required follow-up actions, and output classification. Given the complexity (7 parameters, output schema exists), the description leaves no significant gaps 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by explaining target classification (reply, strategic, both) and how parameters like draft_replies and create_ledger trigger side effects. Context about platform enumeration and NamePros limitations is helpful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool discovers engagement opportunities across platforms (Pro). It distinguishes itself from siblings delimit_social_target_config and delimit_x_fetch by specifying it is a multi-platform scanner, while the former configures platforms and the latter fetches single tweets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (to find posts for engagement, run in /loop) and when NOT to use (for single tweet or drafts, with named alternatives). The 'Sibling contrast' section further clarifies differentiation.
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?
No annotations provided, so description alone must disclose side effects. It lists writes to ledger, updates session metrics (cost, errors), returns next task. Also notes loop continues until STOP signal. This is thorough 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when to use/not use, sibling contrast, side effects). Every sentence adds value. No redundancy. Front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (1 required), output schema exists (context says true), the description covers purpose, usage, side effects, and sibling differentiation. Could mention authorization requirements or failure handling, but overall complete for a loop-related tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters documented in input schema). Description adds no additional parameter-specific meaning beyond the schema's own descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Mark current loop task done and get the next one' with specific verb and resource. Distinguishes from siblings (delimit_ledger_done, delimit_next_task) directly in the sibling contrast section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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. Provides clear context and names alternative tools (delimit_ledger_done, delimit_next_task), making it easy for an AI to decide 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?
Discloses side effect of writing new test files and mentions internal implementation (AST for Python, regex for JS/TS). Could be more thorough about overwrite behavior or prerequisites, but given no annotations, this is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with clear sections. Each sentence serves a purpose without redundancy. Efficiently communicates purpose, usage, and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main aspects: purpose, usage, side effects, sibling contrast. Output schema handles return values. Minor omission of prerequisites (e.g., project path must exist), but overall complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds context for parameters (e.g., source_files default behavior, framework options). Blends schema and description well, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates test skeletons for specific frameworks (Jest, pytest, vitest) and distinguishes from siblings by explicitly contrasting with 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections provide clear guidance, including alternative tools for different scenarios, and sibling contrast clarifies the unique role of 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?
Without annotations, the description fully discloses side effects: gated by require_premium, end-to-end pipeline steps, rate cap, dry_run behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for purpose, usage, sibling contrast, and side effects. The reference 'LED-1253' is slightly extraneous, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all needed aspects: purpose, usage, side effects, parameters, siblings. With an output schema present, the description is fully complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description restates parameter purposes but adds minimal new meaning beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drafts a brand-voice Delimit-POV riff for a specific X tweet. It distinguishes itself from siblings like delimit_x_fetch and delimit_social_generate by name and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections provide clear context, including specific alternative tools (delimit_x_fetch, delimit_social_generate) and conditions.
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?
Describes side effects: list/show are read-only, complete writes to the work-order store. No annotations exist, so description carries full burden. Could mention more about completion behavior but is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when to use, when not, sibling contrast, side effects). Front-loaded with main purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers scope, actions, side effects, and usage guidance. Output schema exists so return values are not needed. Minor inconsistency: 'close' in description vs 'complete' in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds behavioral context for action parameter (read vs write) and notes that wo_id is required for show/complete. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages work orders for listing, reading, or closing. It explicitly distinguishes itself from sibling tools like delimit_ledger_add and delimit_gov_new_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 specific alternative tools (delimit_ledger_*, delimit_gov_new_task/run/verify).
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?
No annotations provided, so the description carries the full burden. It details side effects for each loop_type (e.g., cycle dispatches swarm work, social drafts replies, deploy runs gates) and mentions writing to the session record. However, it does not discuss idempotency, error behavior, or permission requirements, which would elevate it to a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings for usage, side effects, and loop types. It is concise—every sentence adds value—and front-loaded with the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, output schema exists), the description is thorough. It covers when to use, side effects, and loop type details. The output schema likely explains return values, so the description does not need to repeat that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the semantics of loop_type and cycle_mode beyond the schema's simple type descriptions, such as what each loop type does and the cycle_mode options. This complements the schema well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'execute[s] one iteration of a governed continuous loop'. It specifies the verb 'execute', the resource 'governed continuous loop', and distinguishes from siblings like delimit_loop_status and delimit_loop_config. The inclusion of loop types adds further clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('advance the autonomous build / social / deploy loop one step') and when NOT to use (for status use delimit_loop_status, for configuration use delimit_loop_config). Also contrasts with sibling tools, offering clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects: claim/release mutate lock state, check is read-only. No annotations provided, so description fully handles behavioral disclosure with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise three-section structure (purpose, usage, side effects) with no wasted words. Front-loaded with core purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (4 params, no annotations, output schema exists), description covers purpose, usage, side effects, and sibling contrast. Output format not needed due to output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so description adds little beyond what schema already provides. Description repeats schema text for file_path but does not significantly enhance parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool detects/prevents multi-model file edit collisions, with specific verb and resource. Explicitly differentiates from sibling delimit_swarm by stating it tracks per-file edit ownership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' (cross-model workflows, claim before edit, release after commit) and 'When NOT to use' (single-model sessions, general filesystem locking). Clear guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses side effects: writes to backends, posts tweet, generates/upload video. This informs the agent of mutating behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with labeled sections. Every sentence adds value. Front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers purpose, usage, side effects, and sibling relationships. Complete enough for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no additional parameter meaning beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('manually trigger a content publish') and resource ('tweet or YouTube video'). Distinguishes from siblings by naming delimit_content_schedule and delimit_content_queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections, plus sibling contrast listing specific alternatives. Guidance is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits such as side effects for each action (seed populates, add appends, status read-only) and states that the tool mutates the queue. While no annotations exist, the description covers key behaviors, though could mention potential limits or additional side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using short bullet points under clear headings. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description does not need to cover return values. It fully covers purpose, usage, side effects, and sibling contrasts, making it a complete and self-contained description for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with 100% coverage, but the description adds valuable behavioral context by mapping each action value to its side effect. This enhances understanding beyond the schema's raw descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool manages tweet and video content queues, and distinguishes it from siblings by noting that delimit_content_publish drains and delimit_content_schedule reads, while this tool mutates. The verb 'manage' plus specific actions (view, seed, add) make the purpose very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (view, seed, add) and when-not-to-use (publish or read schedule) guidance, including specific sibling tool names for alternatives. This leaves no ambiguity about context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description details side effects for each action: 'list' is read-only, 'create' writes new branch namespace, 'merge' mutates main namespace and closes branch. States no code repo, git state, license gate, notification, or ledger write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (when to use, not to use, sibling contrast, side effects). Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity (multiple actions, 3 params, existing output schema), the description covers usage, side effects, and contrasts completely. No missing aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds behavioral context for actions but does not provide additional parameter details beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages mutable working branches of a venture's context, using specific verbs like 'manage' and resource description. It distinguishes from siblings like delimit_context_snapshot (read-only) and delimit_context_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' (exploring alternative directions, write-isolated) and 'When NOT to use' (immutable evidence, reading context, git operations). Contrasts with delimit_context_snapshot and git directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares side effects as read-only and mentions underlying call (ai.context_fs). Since no annotations provided, the description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise and well-structured: one-line purpose, then clear sections for when to use, when not to use, sibling contrast, and side effects. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers purpose, usage, side effects, and sibling contrast. With output schema present (as per context signals), no need to describe return values. Complete for a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides 100% coverage with descriptions for both parameters. The description reinforces parameter usage but adds no new semantic details beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool reads a specific artifact from a venture's context filesystem by name. Distinguishes from siblings like delimit_context_list (returns names only) and delimit_memory_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (fetch a specific artifact) and when not to use (venture-wide listing or memory search), naming alternatives (delimit_context_list, delimit_memory_search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden; it states side effect: 'writes a snapshot record under the venture namespace via ai.context_fs' and that the snapshot is an immutable point, sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently organized: purpose, when to use, when not, sibling contrast, side effects. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, clear schema), the description provides sufficient context for usage, side effects, and differentiation. Output schema exists, so return value details are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, both parameters have clear descriptions. The tool description does not add additional meaning beyond the schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Capture a point-in-time snapshot of a venture's context' with a specific verb and resource, and explicitly contrasts with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use (before risky handoff/edit/refactor), when NOT to use (individual artifact persistence or one-time memory), and alternative tools (delimit_context_write, delimit_memory_store).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses read-only side effects, the internal function called (ai.daemon.get_daemon_status), and the return value structure. It lacks details on authentication or rate limits, but for a read-only status check this is sufficient. Score 4 due to minor omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear section headings (When to use, When NOT to use, Sibling contrast, Side effects, Args, Returns). It is concise, with no redundant sentences, and front-loads the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description sufficiently explains the return value (loop counts, items processed, recent actions, next_steps). It covers all necessary aspects for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (input schema is empty). The description explicitly states 'Args: None.' with 100% schema coverage, meeting the baseline of 4 for zero parameters. The return value description adds context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Report' and the resource 'autonomous daemon's status', and specifies the contents (loops, items, actions). It also contrasts with sibling tools delimit_daemon_run and delimit_daemon_classify, providing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides 'When to use' and 'When NOT to use' sections, naming alternative tools (delimit_daemon_run and delimit_daemon_classify) for the excluded cases. This gives clear guidance on selecting the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly discloses behaviors: actions gated by require_premium, deterministic error for unknown actions, detailed per-action side effects (read-mostly, local writes, network writes, mutations, etc.), error handling, and dry_run suppression behavior. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and detailed, with multiple paragraphs and bullet-like sections. It is well-structured with headers, but could be more concise. Some per-action details might be better placed in separate docs. However, for a complex dispatch tool, brevity is difficult; it earns a 3.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 8 actions, no annotations, output schema exists), the description is remarkably complete. It covers all actions, side effects, parameter usage by action, error handling, and output wrapping. Every necessary aspect for correct selection and invocation is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for all 10 parameters. The description adds contextual value beyond schema, such as case-insensitive action matching, dry_run behavior (suppresses only final publish), and which parameters are ignored per action. However, much parameter usage is already in schema, so baseline 3; extra context earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'unified deployment entry point' that dispatches to eight deploy actions. It specifies the verb (dispatches) and resource (deploy operations), and distinguishes from sibling aliases and related tools like delimit_obs_status, delimit_test_smoke, and delimit_release_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('as the single MCP-registered deploy surface when the caller wants to pick the deploy operation by name') and when NOT to use ('from internal code paths or when you want the operation's behavior and gate to surface at the right name'), with specific alternatives listed (e.g., 'prefer the specific alias'). Also contrasts with non-deploy tools for health checks, smoke tests, and release tracking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully shoulders the burden of behavioral disclosure. It clearly describes side effects: auto-chaining of delimit_security_audit and delimit_gov_evaluate, with fail-closed behavior on critical findings (halting and returning status='blocked'). This provides essential behavioral transparency beyond basic read/write intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings for usage guidelines, sibling contrast, and side effects. It is concise—every sentence adds value—and front-loads the core purpose. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, auto-chaining behavior, output schema present), the description covers all necessary context: when to use, side effects, and failure modes. The presence of an output schema reduces the need to describe return values, and the description adequately addresses the tool's role in the deployment pipeline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a clear description. The tool description does not add additional parameter details beyond what the schema provides, but the schema descriptions are sufficient. A score of 3 is appropriate as the description does not degrade understanding but adds no extra value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a deploy plan with security preflight (Pro).' It specifies a concrete action (generate a deploy plan) and a key differentiator (security preflight). It also explicitly contrasts with sibling tools delimit_deploy_build and delimit_deploy_publish, making its distinct role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use ('as the first step in the deploy chain') and when not to use ('to actually build images' or 'to ship code'). It names specific alternatives (delimit_deploy_build, delimit_deploy_publish), enabling the agent to make an informed choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses side effects: license gating, premium requirement, network health checks, no writes, and experimental status with potential partial results. This exceeds basic 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when to use, not to use, sibling contrast, side effects). Front-loaded with core action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers usage context, side effects, experimental status, and alternatives comprehensively for a health probe tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema already describes each parameter. The description does not add new semantic details beyond what the schema provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool probes a freshly-deployed revision's health, with specific verb and resource. It distinguishes itself from siblings like delimit_deploy_status and delimit_obs_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (immediately after delimit_deploy_publish), when not to use (steady-state checks, metadata reads, pre-deploy smoke tests), and provides specific sibling alternatives and next steps for unhealthy results.
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?
No annotations are provided, so the description carries the full burden. It discloses side effects: writes tailwind.config.js if missing, otherwise reads existing. This is clear and honest about the tool's mutating behavior, satisfying the transparency requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and well-structured: purpose, usage guidelines, sibling contrast, side effects. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (read or write a file) and presence of an output schema, the description is complete. It covers behavior, side effects, usage conditions, and distinguishes from siblings. No missing information for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra parameter-level meaning beyond the schema's own parameter descriptions. It adequately explains the overall purpose but no additional semantic value for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads existing tailwind config or generates one from CSS tokens. It explicitly names the resource (tailwind.config) and action (read/generate), and distinguishes itself from siblings like delimit_design_extract_tokens 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (bootstrap config from CSS tokens or inspect existing config) and when-not-to-use (extract general tokens or generate components) with specific alternative tool names. This clearly helps the agent decide.
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 annotations provided, the description carries the full burden. It discloses side effects: normal mode fixes configuration drift and writes a manifest, dry_run is read-only, and undo reverts changes. This is good, but could be more explicit about permissions or data scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear labeled sections (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence adds value without redundancy. Length is appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 adequately covers purpose, usage, side effects, and parameter behavior. It mentions the areas checked (MCP connectivity, deps, governance, etc.), providing a complete picture for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving baseline 3. The description adds value by explaining the effects of dry_run and undo in the 'Side effects' section, and noting the default for project_path. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a comprehensive health check of the Delimit installation ('delimit doctor'), using a specific verb and resource. It distinguishes itself from sibling tools like delimit_repo_diagnose (repo-level) and delimit_quickstart (first-run), 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (universal first-step diagnostic for installation-wide issues) and when NOT to use (repo-level health or first-run discovery), including specific alternative tool names. This gives clear, actionable guidance for 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?
Even without annotations, the description fully discloses behavioral traits: it writes a new evidence bundle, is gated by require_premium (implying a paywall/mutation), and explains the backend. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with sections for purpose, usage, contrast, and side effects. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 optional params, output schema present), the description covers workflow context, usage guards, and side effects. It is complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add much. It does not elaborate beyond schema, but the baseline of 3 is appropriate as the schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'collect' and resource 'evidence artifacts for governance'. It clearly distinguishes from sibling tools delimit_evidence_verify and delimit_ledger by their functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' scenarios (deploy, security audit, test run, gate events) and 'When NOT to use' with alternative tool names, plus a sibling contrast section. 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes side effects as 'read-only' and mentions the backend call backends.gateway_core.run_explain. No annotations exist, so the description adequately covers behavioral traits. Could add more about idempotency or rate limits, but current detail is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear sections: purpose, when/when-not to use, and side effects. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the tool definition is complete. All parameters have descriptions, usage guidance is explicit, and side effects are disclosed. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters are described in the input schema (100% coverage). The description adds value by explaining template options and the purpose of old_version/new_version/api_name as context fields, going beyond schema labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Render a human-readable explanation of API changes' with specific use cases like migration notes and PR comments. It distinguishes from siblings by contrasting with delimit_diff and delimit_diff_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (produce explanations) and when NOT to use (raw change data or HTML report), with sibling tool names given as alternatives. This provides clear guidance for 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?
With no annotations provided, the description fully discloses side effects ('read-only network call'), implementation detail ('shells out to gh CLI'), and behavior ('any open PR or PR merged in last 30 days yields verdict=duplicate'). Also mentions 'fail-closed by design'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections (purpose, when to use, when not, sibling contrast, side effects). Every sentence is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and the presence of an output schema, the description is complete. It covers purpose, usage, side effects, and even hints at the output format ('verdict=duplicate'). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters (repo, author, state). The description adds no extra parameter 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a 'Pre-PR duplicate guard for external repos' and distinguishes it from the sibling 'delimit_gov_evaluate' which wraps this function with policy evaluation. The verb 'guard' and resource 'duplicate check' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('first step before drafting any PR against a repo you don't own') and when not to use ('internal repos or non-PR action'), along with an alternative tool ('delimit_gov_evaluate'). This is thorough 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?
With no annotations, the description fully discloses behavioral traits: read-only, no side effects, safe to call frequently, invokes internal health check, no ledger write or notifications. This compensates for missing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when to use, when not, sibling contrast, side effects). Every sentence is informative without redundancy, achieving conciseness without sacrificing completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers all needed aspects: purpose, usage context, behaviors, and constraints. No gaps remain for effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional parameter (repo). The description does not add additional semantics beyond the schema, which is acceptable but not value-added. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports whether governance kernel and policy are reachable, with specific verb and resource. It distinguishes from siblings by contrasting with delimit_gov_evaluate, delimit_gov_policy, and delimit_gov_status, making the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (session start ritual, CI smoke check) and when NOT to use (for specific gating, reading rules, per-repo task state), including alternative tools. This guides the agent effectively.
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?
No annotations provided, so description carries full burden. It explicitly states read-only, mentions side effects (read-only on policy storage, gated by require_premium returning license payload if unlicensed). This is comprehensive for 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise and well-structured with clear sections. Every sentence adds value: purpose, usage guidelines, sibling contrast, side effects. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, read-only), the description covers purpose, usage, side effects, and contrasts with sibling. Output schema exists, so return values are covered. Complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about 'repository (Pro)' but does not elaborate on the 'repo' parameter beyond what schema provides (filesystem path). Thus minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Read the active governance policy for a repository (Pro)' with a specific verb and resource. Contrasts with sibling delimit_gov_evaluate, differentiating that this returns the policy itself while the other runs an action against it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 guide the agent. Clearly states to not mutate policy, as the tool is read-only. Provides sibling contrast for alternative 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?
No annotations provided, so description carries full burden. It explicitly states side effects: writes an acknowledgement record and flips receipt status from pending to acknowledged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with clear sections (purpose, usage, side effects). No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers purpose, usage context, parameters, side effects, and sibling differentiation. Output schema exists, so return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description does not add significant extra meaning beyond what the input schema already provides for the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Acknowledge') and the resource ('pending handoff receipt'), and distinguishes from siblings by noting that this tool closes the loop on a specific receipt, not create or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with specific tool alternatives (delimit_handoff_create, delimit_handoff_list), plus a sibling contrast summary.
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?
With no annotations, description bears full burden. Clearly states side effect (read-only) and data source (in-memory help table). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five well-structured sentences covering purpose, when-to-use, when-not-to-use, sibling contrast, and side effects. No unnecessary words; front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, output schema present), description provides complete guidance: purpose, usage boundaries, side effects, and data source. Output schema handles return value description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema description already details the parameter (tool_name with examples and default behavior). Description adds no further parameter value, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb ('Get help') and resource ('Delimit tool'), with scope covered (purpose, parameters, examples). Distinguishes from siblings like delimit_version and delimit_gov_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (quick reminder of tool interface or workflow overview) and when NOT to use (version/status, governance health). Provides sibling contrast for decision-making.
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?
Discloses read-only side effects and the backend call (backends.gateway_core.run_impact). Lacks mention of authentication or rate limits, but with no annotations, this is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences efficiently covering purpose, usage, sibling contrast, and side effects. Front-loaded with key action. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description sufficiently covers purpose, usage, and side effects. Sibling contrast and backend call reference enrich context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters at 100%. Description adds context about dependency manifest scanning and clarifies default behavior for dependency_file (backend default path).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool analyzes downstream impact of an API change, is informational only, and distinguishes from siblings like delimit_lint which returns 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (assessing blast radius for a planned API change) and when not to use (for gate decisions), with named alternatives (delimit_lint, delimit_gov_evaluate).
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?
Since annotations are absent, the description carries full responsibility. It states 'read-only' and mentions the specific backend call (backends.tools_data.intel_dataset_list). While it covers read-only behavior, it omits potential details like rate limits, authorization requirements, or edge cases. Still, it provides essential transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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, Args, Returns). Every sentence adds meaningful information without redundancy. It is front-loaded with the core purpose and is efficiently short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary aspects for a simple list tool: purpose, usage guidelines, behavioral constraints (read-only), parameter documentation, and return type ('Dict with the dataset registry and next_steps'). The presence of an output schema further reduces the need for additional return value details. It is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params), and schema coverage is 100% (trivially). The description explicitly states 'Args: None.' This clarifies the lack of parameters, meeting the baseline expectation for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear, specific verb+resource: 'List all datasets in the intel registry.' It distinguishes this tool from siblings by explicitly naming the two related tools (delimit_intel_dataset_register, delimit_intel_dataset_freeze) and contrasting their 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/5Does 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 concrete alternative tool names (register, freeze) and the exact context (inventory currently registered datasets). This gives the agent clear decision 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?
Description discloses side effects ('read-only'), internal backend call, and parameter coercion. With no annotations provided, the description fully informs the agent about behavioral traits and implementation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with clear sections (purpose, when to use, when not, sibling contrast, side effects, implementation). Front-loaded, every sentence adds value, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given presence of output schema and only 3 optional parameters, the description covers all essential aspects: usage boundaries, side effects, and internal mechanics. No gaps identified for this read-only search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already describes all 3 parameters with 100% coverage. Description adds little beyond reinforcing the search dimensions (keyword, date, dataset). The coercion detail is minor; overall, description does not significantly enhance parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search saved intel snapshots by keyword, date, or dataset.' It specifies the resource (intel snapshots) and action (search), and distinguishes from sibling tools like 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (to surface ingested intel matching a query, optionally scoped to one dataset) and when NOT to use (to ingest new data or list datasets), with specific sibling names. This leaves no ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses side effects: 'writes the link via ai.ledger_manager.link_items' and auto-creation of reverse direction for 'blocks'/'blocked_by'. Could mention confirmation or return value, but output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence is purposeful: main action, usage guidance, side effects. No redundant or missing information. Efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full parameter schema coverage, the description completes the picture with usage guidelines and side effects. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds value with examples (e.g., 'LED-025'), clarification of link_type values, and auto-detection for venture. No contradictions or omissions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a typed relationship between two ledger items' and specifies link types like blocks, parent/child, duplicates. It clearly distinguishes from siblings (delimit_ledger_links reads, delimit_ledger_update changes fields).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' and 'When NOT to use' sections with alternative tools. Also includes sibling contrast, making it easy for the agent to choose correctly.
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?
No annotations provided, but description declares read-only side effects and references the underlying service ('Calls ai.loop_engine.loop_status'), fully meeting the transparency need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections (When to use, When NOT to use, Sibling contrast, Side effects) and no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no required, output schema present), the description covers usage guidelines, side effects, and parameter semantics adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains the session_id parameter. The description does not add new meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool checks autonomous loop metrics for a session, specifying exact metrics (iterations, cost, errors, safeguard status). Distinguishes from siblings delimit_loop_config and delimit_build_loop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use and when NOT to use, with direct references to alternative tools (delimit_loop_config, delimit_build_loop).
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?
With no annotations, the description fully discloses side effects: 'read-only', calls backend 'backends.memory_bridge.get_recent', and 'Free tier — no license gate'. This goes beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (under 100 words), well-structured with labeled sections (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 param, no required params, output schema exists), the description covers purpose, usage, behavior, and alternatives. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'limit'. The description adds 'Default 5' which is already in schema default. No additional semantics beyond schema, so baseline 3 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Return the most recent memory entries (Free tier)'. The verb 'Return' and resource 'memory entries' are specific. It distinguishes from siblings like delimit_memory_search and delimit_memory_store by noting the chronological tail vs semantic search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('at session start') and when not to use ('for semantic/structured search' or 'to write'). Also names alternatives (delimit_memory_search, delimit_memory_store).
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?
With no annotations provided, the description fully bears the burden. It states 'read-only on the memory backend; gated by require_premium' and 'Calls backends.memory_bridge.search.' This discloses side effects, auth requirement, and implementation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections. It is concise with no wasted words. Every sentence earns its place, and the key point is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (present), the description is complete. It covers purpose, usage guidelines, side effects, auth requirements, and distinguishes from siblings. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both query and limit are described in the schema). The description does not add significant 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search conversation memory semantically (Pro).' It specifies the action (search), the resource (conversation memory), and the method (semantic). It directly distinguishes from siblings like delimit_memory_recent 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('to recall prior context by meaning rather than recency') and when NOT to use ('for the chronological tail (use delimit_memory_recent) or to write a memory (delimit_memory_store)'). It also provides a sibling contrast with delimit_memory_recent.
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?
No annotations provided, but the description explicitly discloses side effects per action: 'action=\"configure\" writes via ai.notify.save_routing_config', 'action=\"test\" sends test notifications', and 'action=\"status\" is read-only'. This covers write operations and read-only behavior. Could mention auth or error handling but is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Highly structured into sections: purpose, when to use, when not to use, sibling contrast, side effects. Every sentence adds value with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values are covered. The description provides all necessary context: purpose, usage guidelines, sibling differentiation, side effects, and parameter context. Nothing essential is missing for an AI 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all 5 parameters. The description adds context by explaining the config parameter's use with configure action and webhook_url, email_to, from_account for test action, tying parameters to their respective actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Manage impact-based notification routing' and specifies inspecting or updating rules that route change alerts by severity. It distinguishes from sibling tools delimit_notify and delimit_notify_inbox, making the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides both 'When to use' and 'When NOT to use' sections with specific sibling tool names. Gives sibling contrast explaining the roles of delimit_notify, delimit_notify_inbox, and 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 no annotations, description discloses side effects: writes to alert config for create/update/delete, reads only for list. Also notes it is EXPERIMENTAL, backend-specific schema may evolve, routes through ops bridge, and no license gate. This provides strong behavioral context for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively long but well-structured: summary, when to use, when not to use, sibling contrast, side effects. Information is front-loaded. Each sentence adds value; no redundancy. Could be slightly more concise but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions, experimental status, no annotations, output schema present), the description is nearly complete. It covers purpose, alternatives, side effects, experimental nature, and schema volatility. Could mention error handling or permissions, but output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% parameter description coverage, so baseline is 3. Description adds value by listing the valid action values (list/create/update/delete) and clarifying when alert_rule and rule_id are required, going beyond the schema's string only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it manages alerting rules with specific verbs (list, create, update, delete). It distinguishes from sibling tools like delimit_obs_metrics and delimit_obs_logs by specifying that this is for configuring ongoing alerts, not for one-shot queries or log search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (configure ongoing alerts for production thresholds) and when NOT to use (one-shot queries, log search, health rollup, retrying failed deliveries). Also names alternatives: delimit_obs_metrics, delimit_obs_logs, delimit_obs_status.
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?
No annotations are provided, so the description fully carries the burden. It details read-only nature, licensing gate (require_premium), backend invocation, no side effects (no writes, ledger entries, notifications), and response routing through _with_next_steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (main purpose, when to use, when not to use, sibling contrast, side effects). Every sentence adds value, and the description is appropriately sized without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's context: purpose, usage guidelines, licensing, side effects, and typical workflow. It is complete for a log search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add new parameter-specific details beyond what the schema already provides, but reinforces the windowed search pattern and licensing context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches application and system logs across configured sources. It distinguishes from siblings like delimit_obs_metrics (numeric series) and delimit_obs_status (health rollup), leaving no ambiguity about its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (incident investigation with symptom) and when NOT to use (numeric series, health rollup, alerts, tail-follow). Includes typical pattern with delimit_obs_metrics and contrasts with grepping local filesystem.
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?
With no annotations provided, the description fully covers side effects: read-only, license gating, internal backend invocation, no writes or notifications. Also mentions response routing through _with_next_steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized into logical sections (what it does, when/not to use, sibling contrast, side effects). Every sentence adds value; no redundancy. Front-loaded with main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage boundaries, behavioral details, licensing, and inter-tool relationships. Output schema exists, so return value explanation is unnecessary. Complete for an agent to decide invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions, so baseline is 3. Description adds no extra parameter-level information beyond context of typical metric queries (CPU, memory, etc.), but that's more about output than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Pull' and resource 'numeric metric series from observability backend (Pro)'. Contrasts with delimit_obs_logs (text) and delimit_obs_status (rollup), making 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use (runtime health investigation) and when-not-to-use (log search, alert config, rollup). Names specific sibling alternatives with clear differentiation.
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?
No annotations provided, but description fully discloses side effects: read-only on policy and spec files, and simulate action runs lint without writing evidence. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for purpose, when to use/not use, sibling contrast, and side effects. Every sentence adds value, no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (1 required), output schema exists (so return values not needed), and no missing behavioral details. Description covers use cases, side effects, and alternatives comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. Description adds minimal extra parameter meaning beyond schema; it restates required fields and simulate prerequisites, but schema already has full descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Inspect or simulate governance policy configuration' with specific verb+resource. Distinguishes from siblings: delimit_gov_policy reads live policy, delimit_lint enforces, this simulates/inspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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, naming alternatives delimit_lint and delimit_gov_policy. Also provides sibling contrast.
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 read-only network via residential proxy, rate limit of 1 req/2sec, and mandatory chaining rule. No annotations present, but description covers key behavioral aspects thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (intro, usage, exclusions, side effects, chaining rule). Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters fully documented in schema and presence of output schema, the description covers purpose, usage, behavioral traits, and chaining requirements completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions. Description adds no extra meaning beyond what schema already provides, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it scans 25+ subreddits for outreach targets, with verb 'scan', resource 'subreddits', and specific purpose. Contrasts with siblings directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly defines when to use (venture-agnostic bulk scan) and when not (venture-scoped or single thread), with alternative tools named. Provides clear 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?
With no annotations, the description fully discloses side effects: read-only, no license gate, calls specific backend, no write/probe/notification. Also marks as EXPERIMENTAL with possible schema evolution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for purpose, usage, exclusions, sibling contrast, and side effects. Front-loaded, concise, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and two well-documented parameters, the description covers all necessary context: read-only nature, experimental status, sibling relationships, and use cases. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. It adds no extra parameter 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the recent release timeline for an environment, uses a specific verb-resource pair, and distinguishes from siblings like delimit_release_status and delimit_release_rollback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (incident investigation, picking to_version for rollback) and when not to use (for current release, per-app timeline, audit-trail), with alternative tool names provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses side effects: read-only, gated by require_premium, licensed call invokes reading release manifest, no write/probe/notification. Also explains response routing through _with_next_steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence earns its place; no fluff. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, clear schema, and an output schema, the description covers all essential aspects: purpose, usage guidance, side effects, licensing, and internal behavior. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'environment', which already has a default and description. The tool description does not add significant meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports the active release version for an environment (Pro). It uses specific verb+resource ('report', 'release version') and distinguishes itself from siblings by explaining it's a point-in-time snapshot at the release-tier, not per-app deploy-tier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (incident pages, pre-deploy snapshots) and when not to use (per-app rollout state, past releases, planning). Also contrasts with siblings delimit_deploy_status and delimit_release_history, providing clear guidance on alternatives.
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?
No annotations provided, so description carries full burden. It discloses read-only audit nature, side effects (gated by require_premium, calls internal read APIs). Minor omission: no mention of error behavior or response format, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with clear sections: purpose, when to use, sibling contrast, side effects. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, output schema exists), description covers all essential aspects: purpose, usage boundaries, side effects, and parameter semantics. It is complete and leaves no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (action) with 100% schema coverage. Description adds value by specifying default ('audit') and valid options ('audit' or 'config'), improving clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits or reports config of public surfaces for consistency, with explicit verb and resource. It distinguishes itself from sibling delimit_release_status by specifying that this tool audits config while that reports deployed state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when to use (confirm consistency of release version/config) and when not to use (deploy/sync content). Also provides sibling contrast, giving clear guidance to the AI 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?
No annotations provided, but description fully discloses side effects: on success no side effects, on failure auto-chains three specific tools. This gives agents essential behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Compact yet thorough: organized into clear sections (purpose, when to use/not, sibling contrast, side effects). Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and full parameter schema, the description covers all critical aspects: pipeline role, auto-chaining behavior, and differentiation from related tools. Sufficient for correct agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (environment, version) well-described. Description does not add extra parameter details, but baseline 3 is appropriate since schema already provides sufficient semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Validate that a release is safe to ship.' Distinguishes from siblings by stating it's the gate between delimit_release_plan and rollout, and contrasts with delimit_lint and delimit_obs_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (as gate between plan and rollout) and when not (for linting or runtime health). Provides sibling contrast, clarifying that delimit_release_plan describes what would ship, while this attests safety.
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?
No annotations provided, so description fully details behavior: read-only, accepts local path/owner/repo/GitHub URL, remote inputs shallow-cloned to tempdir, and calls backend function. Adds valuable context beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise; purpose, usage guidelines, and behavior are clearly front-loaded. No redundant sentences. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, when to use, side effects, parameter semantics, and sibling contrast. Since output schema exists, return values need not be explained. Complete for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'target' with 100% schema description coverage. The description doesn't add additional meaning beyond what the schema already provides; baseline score appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates repository configuration files (experimental) and lists example files. It distinguishes from siblings delimit_repo_config_audit (policy compliance) and delimit_repo_analyze (full repo analysis).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (pre-merge check) and when NOT to use (compliance vs external standard or full repo analysis), with specific sibling tool names. Provides clear context and 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?
Discloses read-only nature, requirement of 'require_premium', internal implementation call, and experimental status. With no annotations, this fully covers behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet structured with clear sections (when to use, when not, sibling contrast, side effects). Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple diagnostic tool: covers when to use, behavior, side effects, gating, and experimental status. Output schema exists so return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter 'target' with default and path explanation. The description adds no further detail beyond the schema, meeting the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Diagnose repository health issues' and distinguishes from siblings by specifying when to use delimit_repo_analyze and delimit_repo_config_validate instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (before commit/push), when not to use (for full analysis or per-file validation), and provides sibling contrast with delimit_repo_analyze.
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?
No annotations provided, but description states 'read-only network calls' and internal driver methods. Discloses side effects and internal behavior sufficiently 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at ~100 words, uses clear sections, front-loaded main purpose. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema descriptions and output schema existence, the description covers all necessary context: purpose, usage, side effects, and sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed param descriptions. Description adds usage context (e.g., 'repo required for workflow listing') but does not substantially extend parameter meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List resources from a connected data-plane system' with specific examples (repos, PRs, issues, workflow runs). Distinguishes from siblings by naming delimit_resource_get and delimit_resource_drivers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with alternative tools named. Sibling contrast further clarifies when to use this tool versus similar ones.
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 declares side effects: 'read-only scan via filesystem globs. Does not write to project files.' This fully discloses behavior. No annotations exist, so the description carries the burden and does it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when to use/not, sibling contrast, side effects). It is concise with no redundant sentences, front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with output schema, the description covers discovery intent, output specifics, side effects, and usage context. No gaps remain; the tool is fully described for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning for the parameter beyond the schema's description and default. It does not elaborate on path format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans a project and reports what Delimit can do, listing specific findings (OpenAPI specs, security issues, frameworks, tracking suggestions). It distinguishes from siblings delimit_quickstart and delimit_init by contrasting their purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections provide clear guidance. It states when to use (first-run discovery on a new project) and when not (governance initialization or quickstart), with named alternatives.
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?
No annotations are provided, so the description bears the full burden. It discloses side effects: launches headless Chromium or terminal subprocess, writes MP4/GIF files under ~/.delimit/recordings/, gated by require_premium, and duration capped at 120s. This is comprehensive, though it could mention if files overwrite or if the operation is cancellable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured with clear sections: purpose, when-to-use, when-not-to-use, sibling contrast, and side effects. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (screen recording with multiple modes and parameters) and presence of an output schema, the description covers input, side effects, output files, and usage constraints (Pro, duration cap). It is complete enough for an agent to determine when 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context beyond the schema by explaining that script is for terminal mode only, and that there are two modes (browser/terminal). It also mentions file outputs per mode. This adds meaningful value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Record a screen capture' with a specific verb and resource. It distinguishes from sibling tool delimit_screenshot by noting it captures video over a duration, not a single still.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (capture video for documentation, demo, audit) and when NOT to use (single still - use delimit_screenshot), giving clear context and alternative.
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 no annotations, the description discloses side effects as 'read-only', details the backend call, and explains the optional dependency behavior (returns verification_unavailable if cryptography is absent). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings (purpose, when to use/not use, sibling contrast, side effects). Every sentence adds value and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 param, no annotations, has output schema), the description covers purpose, usage boundaries, side effects, and alternatives. The output schema handles return value documentation, so the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description in the schema already explains 'receipt_path'. The description does not add additional semantics or usage details beyond the schema. Per guidelines, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Verify' and the specific resource 'Delimit Seal receipt against the bundled Layer-0 constitution'. The sibling contrast section explicitly distinguishes it from delimit_evidence_verify and delimit_ledger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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, naming alternative tools (delimit_evidence_verify, delimit_ledger) and contrasting their purposes.
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?
No annotations provided. Description states 'Side effects: read-only. Calls ai.secrets_broker.list_secrets' and emphasizes it never returns values. Provides good behavioral context beyond the bare minimum, though lacks audit/permission 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise with bolded sections and bullet points. Every sentence adds value. No wasted words. Efficiently structured to convey purpose, usage, and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no parameters and an output schema. Description specifies return type: Dict with key 'secrets' containing list of metadata records, plus next_steps suggestions. Completely covers all necessary information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters (schema coverage 100%). Description explicitly states 'Args: None.' which adds no further meaning beyond the schema, meeting baseline expectation for no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List secrets in the broker (metadata only — never values)' with specific verb (list) and resource (secrets). Distinguishes from siblings delimit_secret_get and delimit_secret_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('inventory what credentials are stored without exposing values'), when-NOT-to-use (retrieve value -> delimit_secret_get, add one -> delimit_secret_store), and sibling contrast with delimit_secret_get.
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?
No annotations present, so description fully discloses side effects: writes a revocation record via ai.secrets_broker.revoke_secret, subsequent get calls denied, access log preserved. Provides clear behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (4 sentences) and well-structured with labeled sections for when to use, when not to, sibling contrast, and side effects. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple revoke tool with one parameter and an output schema, the description covers use cases, side effects, and parameter usage completely. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not add meaning beyond the input schema for the single parameter 'name'. Schema coverage is 100%, so baseline 3 is appropriate; the description repeats 'Required.' which is already in the parameter description but does not provide additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'revoke' and resource 'secret' with the purpose 'prevent any future access'. It contrasts with sibling tool delimit_secret_store, which 'creates', and implicitly distinguishes from delimit_secret_get by noting revocation blocks it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios ('after a credential leak or when rotating away from an old secret name') and when-not-to-use ('to delete metadata only — revocation also blocks delimit_secret_get'). Includes sibling contrast for 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?
With no annotations provided, the description carries full burden and discloses side effects as read-only and internal backend call. It honestly states it is the built-in scan, providing full 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with clear headings for usage, not-to-use, sibling contrast, and side effects. Every sentence is valuable and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and only one optional parameter with full schema coverage, the description covers all necessary context: purpose, usage, alternatives, side effects. It is complete for a scan tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional semantics beyond what is already in the input schema. It merely restates the parameter description without extra guidance on format or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it scans a repository for security vulnerabilities with specific verb 'Scan' and resource 'repository for security vulnerabilities'. Distinguishes from siblings by naming delimit_security_ingest and delimit_security_deliberate with their contrasting purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (baseline before deploy/release), when not to use (ingestion or triage), and names specific alternatives. This gives clear decision boundaries for 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?
With no annotations, the description fully discloses behavioral traits: side effects for each action (e.g., 'promote' writes a new ledger item, 'freeze' cold-archives) and the storage location (~/.delimit/intel/signals/). Read-only and write actions are clearly separated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections: when to use, not to use, sibling contrast, and side effects. It is front-loaded with the main purpose and avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (noted in context signals), the description need not explain return values. It covers all essential aspects: purpose, usage, side effects, and sibling distinction, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 context for the 'action' parameter by explaining each action's effect, but other parameters are already well-documented in the schema. No significant additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Review and manage the signal corpus (LED-877).' It specifies actions like inspect, cluster, and promote, and distinguishes from sibling tools like delimit_reddit_scan and delimit_github_scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' and 'When NOT to use' sections, detailing appropriate use cases (inspect, cluster, promote) and exclusions (fetch new signals, write ledger items directly). Also includes sibling contrast for additional 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?
With no annotations provided, the description carries full responsibility for disclosing behavior. It states side effects: 'read-only network call via gh CLI.' It also mentions defense-in-depth mechanisms: 'Validates repo format with regex' and 'Subject to the confused-deputy guard (_check_repo_allowlist) before fetching.' This level of detail is exceptional for an agent to understand the tool's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, usage guidance, sibling contrast, and side effects. It is concise, with every sentence providing valuable information. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, output schema exists), the description covers all necessary aspects: purpose, usage, behavioral details, and parameter context. It mentions the return value implicitly ('structured signal for routing'). With the output schema available, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description does not add additional meaning beyond the schema; it mentions validation behavior but not parameter-specific details. The schema itself is descriptive enough, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Check a GitHub issue for new comments since the last sensor tick.' It identifies the specific resource (GitHub issue) and verb (check for new comments). It also distinguishes from sibling tools like delimit_github_scan and delimit_resource_get, making it easy for an agent to select this tool over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 monitor a specific outreach / tracking issue for new activity.' It also provides clear exclusions: 'When NOT to use: for repo-wide scans (use delimit_github_scan) or one-shot fetch (delimit_resource_get).' This provides strong guidance on usage 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?
No annotations provided, so description carries full burden. It discloses side effects: action='approve' posts via social backend (network write), action='reject' discards, action='list' is read-only. This is sufficient for understanding behavioral traits, though it could mention rate limits or auth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with no redundant sentences. It is front-loaded with purpose, then usage guidance, then side effects. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three actions), the description covers purpose, usage guidelines, sibling contrast, and side effects comprehensively. An output schema exists for return values, so no need to describe those. It is complete for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds behavioral context for each action value and explains when draft_id is required. For example, it notes that 'approve' actually posts, which is not in the schema. This enhances understanding beyond the schema's simple description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Manage social media drafts — list, approve, reject (Pro).' It uses a specific verb (manage) and resource (social drafts), and enumerates the three actions. It distinguishes from siblings like delimit_social_post and delimit_social_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'to clear the social drafts queue created by delimit_social_post(draft=True).' When NOT to use: 'to draft (use delimit_social_post(draft=True)) or inspect history (delimit_social_history).' Includes sibling contrast, leaving 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 annotations, the description fully discloses behavioral differences: actions like 'update' and 'add_subreddits' are writes, while 'status' and 'detect' are read-only. This is valuable, though it could mention if updates are destructive or require permissions, but overall it's very transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose statement, usage guidelines, sibling contrast, and side effects. Each sentence adds important information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters with 100% schema coverage and an output schema, the description provides complete context: what the tool does, when to use it, how it differs from siblings, and behavioral side effects. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by grouping actions into read/write categories and explaining the purpose of each action beyond the schema's short descriptions. This helps the agent understand parameter usage contextually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Configure social target scanning platforms') and further clarifies it is for inspecting/updating platforms and adding subreddits. It distinguishes from siblings by noting that delimit_social_target runs scans, while this tool configures platforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (inspect/update platforms, add subreddits) and when not to use (running scans or drafts), with specific sibling alternatives (delimit_social_target, delimit_social_generate). This gives clear guidance for 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?
Discloses side effects ('writes a soul record via ai.session_phoenix.capture_soul'), auto-detection of git state and model, and internal string-splitting behavior. With no annotations provided, the description fully bears the transparency burden and does so thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently front-loaded with purpose and usage guidelines. Every sentence adds value, though it is slightly verbose. No redundant phrases; structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and presence of an output schema (context signal), the description covers behavioral aspects and usage thoroughly. It omits explicit mention of return value, but the output schema likely provides that. Still, a brief note on what the tool returns would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 8 parameters with descriptions (100% coverage), so baseline is 3. The description adds value by noting that comma-separated strings are split into lists internally, which is not obvious from schema alone. A small deduction for not elaborating on 'tokens_used' or 'context_fullness' beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures session state as a 'soul' for cross-model resurrection, with a specific verb ('capture') and resource ('session state'). It distinguishes from siblings like delimit_session_handoff and delimit_memory_store by explicitly contrasting use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('at session end or when context gets full'), when-NOT-to-use ('general memory writes' and 'full handoff orchestration'), and names alternative tools (delimit_memory_store, delimit_session_handoff). This is exemplary 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?
No annotations provided, so description carries full burden. It discloses side effects: invokes build via subprocess, writes to output_dir, and returns setup guidance when not configured. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with core purpose, and organized into clear sections. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers purpose, usage, side effects, and parameter behavior adequately. No gaps for a build tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. Description adds minimal context beyond schema (e.g., default behavior of output_dir), but does not significantly enrich parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Build a Storybook static site (or return setup guidance)' with specific verb and resource. It distinguishes from siblings by explicitly stating what this tool does versus delimit_story_generate and delimit_story_accessibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use ('to build the Storybook static site for an existing project') and when-not-to-use ('to write stories' or 'run a11y checks') with alternatives. Sibling contrast is clearly given.
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 ('writes a new .stories.tsx file next to the component') and a behavioral quirk ('Coerces variants from a comma string to a list via _coerce_list_arg'), which adds value beyond the none provided 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured: purpose in one sentence, then usage guidelines, sibling contrast, and side effects. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and full schema coverage, the description covers purpose, when to use/not use, side effects, and behavioral details. It is complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional parameter explanations beyond the schema's own descriptions, but the coercion detail is more about behavior than parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate a .stories.tsx file for a UI component' and distinguishes it from sibling tools by naming delimit_story_accessibility and delimit_design_generate_component, showing 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' and 'When NOT to use' sections with specific alternative tools (delimit_story_accessibility, delimit_design_generate_component), and adds a 'Sibling contrast' paragraph for further clarity.
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?
Details side effects (writes baseline on first run, subsequent runs read-only) and fallback behavior (Puppeteer when Playwright missing). With no annotations provided, the description fully compensates by disclosing important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and well-organized: a one-sentence summary followed by use/when-not, sibling contrast, and side effects. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (documenting return values), the description covers usage guidelines, behavioral side effects, and sibling differentiation. It is sufficiently complete for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions and defaults (threshold default 0.05, project_path nullable). The description adds no extra parameter context beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a visual regression test (screenshot vs. stored baseline). It distinguishes from siblings like delimit_screenshot (one-off screenshot) and delimit_story_accessibility (a11y/HTML audit), making its purpose precise and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (as a CI gate after UI changes) and when not to use (a11y checks, one-off screenshots), with direct references to alternative tools. This leaves no ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description compensates fully by stating side effects: read-only, gated by require_premium, calls backends.ui_bridge.test_coverage, and marked experimental with heuristic 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is compact, well-structured with clear sections (when to use, when not, sibling contrast, side effects). Every sentence adds value and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and the description covers purpose, usage, behavior, and side effects (including experimental nature and backend call), it is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no additional parameter details. Baseline of 3 is appropriate; no extra value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Analyze test coverage for a project', using a specific verb and resource. It distinguishes itself from siblings by naming delimit_test_smoke and delimit_test_generate and explaining their differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (surface coverage for CI pass/fail) and when NOT to use (scaffold stubs or smoke run), including alternative tool names.
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?
No annotations provided, so description bears full burden. Clearly states 'Side effects: read-only on the vault backend' and 'gated by require_premium', disclosing both safety and access control. Also explains the vault concept as 'long-lived knowledge artifacts'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: header line, then sections for When to use, When NOT to use, Sibling contrast, Side effects. Every sentence adds value with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single fully-documented parameter, an output schema (assumed present), and thorough description of usage and side effects, the tool definition is fully complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add extra meaning beyond the schema's description of 'query' as 'Search query string. Required.' Baseline 3 is appropriate as description provides no additional parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search vault entries by query string (Pro)', specifying verb, resource, and scope. It explicitly distinguishes from siblings delimit_memory_search and delimit_vault_snapshot, leaving no 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use ('to retrieve stored vault content matching a search string'), when not to use ('for conversation memory use delimit_memory_search'), and sibling contrast. Also notes it's read-only and gated by require_premium.
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 annotations provided, the description must carry the full burden. It discloses side effects ('writes a snapshot record'), prerequisite ('gated by require_premium'), and internal call ('Calls backends.vault_bridge.snapshot'). Minor: could mention whether snapshot is instantaneous or async, but still very good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (one-liner, usage guidelines, sibling contrast, side effects, args, returns). Every sentence adds value and the key points are front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and existence of an output schema, the description covers all necessary context: use cases, exclusions, side effects, prerequisites, and a brief return description ('Dict with snapshot data and next_steps'). It is fully complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so baseline is 4. The description explicitly states 'Args: None,' confirming no additional meaning is needed. This is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Capture' and resource 'snapshot of vault state (Pro)'. It distinguishes from sibling tools delimit_vault_health (reports up/down) and delimit_vault_search (for searching content), making the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('before a risky vault edit, to have a rollback point') and when NOT to use ('for searching content' or 'checking health only' with specific sibling alternatives named). This is excellent 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?
Discloses side effects: action='add'/'remove' mutate ~/.delimit/webhooks.json, action='test' sends test notification, action='list' is read-only. Without annotations, this provides necessary behavioral context. Could mention persistence or reversibility, but still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (When to use, When NOT to use, Sibling contrast, Side effects) in a concise format. Every sentence adds value, no repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all key aspects: governance alerts, mutation, test functionality, file path. Given 3 parameters with 100% schema coverage and output schema present, the description is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning: explains action parameter's effects (mutate vs test vs read-only), clarifies url requirements for add/remove/test, and events filter values. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages webhook notifications for governance events, using a specific verb (manage) and resource (webhook). It contrasts with sibling tools delimit_siem and delimit_notify, distinguishing itself from structured streaming and one-shot notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (register a Slack/Discord/HTTP webhook for governance alerts) and when NOT to use (SIEM-class streaming or one-shot notifications), naming specific alternatives. Also provides sibling contrast.
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 (read-only network call via twttr241 RapidAPI) and behavioral traits (LRU + SQLite cache + budget gate, no writes). Since no annotations are provided, the description fully carries the transparency burden and does so thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (purpose, when to use/not use, sibling contrast, side effects). Every sentence adds value, and it is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 is complete: it covers purpose, usage guidelines, side effects, caching behavior, and sibling differentiation. An agent can confidently decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description does not add significant meaning beyond what the schema already provides for id_or_url and ids; it merely summarizes the parameters without new semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'tweets from X by id or URL', and explicitly distinguishes from sibling tools delimit_social_target and delimit_reddit_fetch_thread, making it easy for an agent to select the correct 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' (surgically fetch tweets by id/URL) and 'When NOT to use' (scanning for new content, Reddit threads), including alternatives. Also notes the cached path sharing with delimit_social_target for free repeats.
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?
With no annotations, the description fully discloses side effects (writes to disk, string coercion), explicitly states NO subagent spawning, and notes lack of license gating. Comprehensive coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, front-loaded purpose. Slightly verbose but each sentence adds necessary detail. Could be trimmed slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, full schema coverage, output schema present, and many sibling tools, the description covers all needed aspects: purpose, usage, behavior, parameter nuance, side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by noting coercion for string lists and clarifying assignee defaults beyond schema descriptions. Minor extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool records engineering-task dispatch with audit trail. Distinguishes from siblings by specifying it is for planning/audit surface, not execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' and 'When NOT to use' sections, plus sibling contrast. Guides the agent on proper context and alternatives like delimit_agent_status and delimit_agent_complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses side effects: status is read-only, other actions write and audit, dispatch only records intent. It details deterministic guards (kill switch, circuit breaker, ghost-title reject) and error format. This exceeds the burden typically expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core summary, then well-structured into usage guidelines and side effects. While verbose with guard details, every part earns its place given the tool's complexity. Slight verbosity keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, 4 actions, multiple guards, and an output schema, the description covers the lifecycle, per-action parameter usage, side effects, error handling, and sibling relationships. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds contextual nuance: which parameters apply to which actions, how 'context' differs for dispatch vs handoff, 'task_id' optional for status but required for complete/handoff. This adds meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages the agent-task lifecycle and dispatches to one of four actions. It distinguishes from siblings by naming thin aliases and contrasting with other delimit tools like delimit_ledger_add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when to use (single MCP surface for lifecycle actions) and when not to use (internal code paths preferring specific aliases). It warns about misconception that 'dispatch' executes, and clarifies separate tools that share the prefix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers side effects per action: read-only vs write ops, idempotency, silent overwrite, deterministic errors, and destructive merge behavior (deletes branch).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, but could be slightly more concise; the side-effect per-action list is thorough but verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and complex dispatch logic, the description is comprehensive, covering all actions, errors, and comparisons with sibling/memory tools. Output schema exists, so return details are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds practical context like conditional dependencies (branch_action requires branch_name) and default behaviors, beyond the schema's type/default fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'unified context-filesystem entry point' that dispatches to six actions, and distinguishes itself from sibling aliases like delimit_context_read, delimit_context_write, etc., by being the dispatch core.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections, compares to memory tools, and suggests preferring specific aliases for internal code paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: list/get are read-only, approve/reject append to an existing store, reject stamps disposition='rejected', idempotent re-approve no-ops, and no new store created. This covers safety, side effects, and idempotency comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, when to use, when not, sibling contrast, and side effects. It is slightly verbose but every sentence contributes meaningful information. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple action types, lane unification) and the presence of an output schema, the description is complete. It covers purpose, usage boundaries, side effects, and differentiation from siblings. No obvious gaps in required information for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that approve/reject act only on approval-class items and that item_id is required for specific actions, reinforcing schema descriptions. It does not fully redundantly document each parameter but provides useful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates governance lanes into a shared queue and can approve/reject approvals. It specifies the verb+resource ('aggregate', 'approve/reject') and distinguishes itself from siblings like delimit_agent_dashboard, delimit_ledger_context, and delimit_notify_inbox.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections provide clear guidance. It specifies that the tool is for the shared queue and approval-class actions only, and directs mutation of other items to their owning tools, which is excellent for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses read-only nature ('read-only static analysis'), implementation detail (calls backends.ui_bridge.design_validate_responsive), and parameter coercion (_coerce_list_arg). Adds valuable behavioral context beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections (purpose, when to use, when not, sibling contrast, side effects). Every sentence adds value; no fluff. Appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters (1 required), high schema coverage, and output schema present, description covers all necessary context: intended usage, exclusions, side effects, parameter handling. Complete and sufficient for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds meaning: explains check_types can be comma string or list, default behavior (None = all), and coercion to list. This goes beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Validate responsive design patterns via static CSS analysis.' and contrasts with sibling delimit_story_accessibility. Verb+resource+scope are specific and distinguish 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (CI check after editing UI/CSS) and when not to use (accessibility audits via delimit_story_accessibility, component scaffolding via delimit_design_generate_component). Provides clear context and 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?
Discloses side effects (writes one file, path sanitization, feature coercion, overwrite uncertainty). Since no annotations are provided, this description fully addresses behavioral transparency 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and no redundant sentences. It is slightly lengthy but every section serves a purpose (usage, contrasts, side effects).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and full schema coverage, the description covers all necessary aspects: purpose, usage, behavior, parameter dynamics, and side effects. It is complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the description adds meaningful context about parameter behavior (e.g., target is sanitized, features coerced from comma string). This provides additional value beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence clearly states the verb and resource: 'Write a single file from a code template into an existing project.' The description further distinguishes this tool from siblings by specifying it writes a single file, not a full scaffold or design 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/5Does 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, along with sibling tool comparisons. This gives the agent clear guidance on 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?
With no annotations, the description fully discloses side effects: read-only, gated by require_premium, no ledger writes or task creation. It also explains input coercion (_coerce_dict_arg) and short-circuit behavior for malformed context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (use, not use, sibling contrast, side effects). It is slightly long but every sentence adds value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full parameter descriptions, the description is very complete. It covers all essential aspects: purpose, timing, exclusions, side effects, license behavior, and input validation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers all 3 parameters with descriptions (100% coverage), but the description adds meaningful details: auto-coercion of string context to dict, and that empty action returns an error. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates whether a proposed action triggers governance gating, using a specific verb and resource. It distinguishes from sibling tools like delimit_gov_policy (returns rules) and delimit_gov_new_task (creates task after verdict).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use (before uncertain actions like deploy, PR submission) and when not to use (read policy, create tracked task, check health). It also warns against retroactive calls and provides sibling 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?
Discloses side effects ('read-only on the heartbeat directory. No network, no write, no ledger, no notification') and lists classification categories (parse_error, failed, stale, etc.). No annotations provided, but description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, clear sections for usage, side effects, and classification. Though verbose, it is efficiently organized and each section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete given single parameter and presence of output schema. Covers all relevant aspects: input, behavior, classifications, thresholds, override mechanism, and future plans.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter with description). The description adds context about default directory lookup (env var, fallback path) that enriches the schema's description, earning above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Walk the heartbeat directory and report which scheduled services are stale', specifying the verb (walk/report) and resource (heartbeat directory). It distinguishes from siblings like delimit_obs_status and delimit_gov_health by contrasting the scope of liveness vs observability vs system 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use ('as part of the session-start ritual') and when not to use ('for one-off liveness checks' or 'full-host metrics'), naming alternative tools. Also mentions future phase for external deadman ping.
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?
With no annotations, the description fully discloses side effects (marks/archives on dry_run=False), default behavior (dry_run=True returns plan), detection methods, action mapping per resolution state, error handling (API errors leave alone), and implementation reuse. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (when to use, side effects, detection, action map). Front-loaded with purpose. However, it is somewhat verbose; some details could be moved to output schema or shortened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (3 params, output schema exists, no annotations), the description is thorough: covers detection logic, action mapping, side effects, defaults, and error handling. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds behavioral context for dry_run (default true, returns plan vs applies) and max_items (hard cap, truncation flag), which goes beyond the schema definitions. venture is explained briefly but clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: auto-close ledger items whose linked GitHub issue/PR is resolved. It uses specific verbs and resources, and differentiates from siblings like delimit_ledger_done (per-item) and delimit_resource_get (read external state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (periodic maintenance) and when not to (manual close, read external state). Names alternative tools for those cases, providing clear 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?
No annotations are provided, so the description carries full burden. It declares read-only, details internal calls (list_items, groom, P0 quota helpers), and comprehensively describes the return structure, including overall_health and next_actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a succinct summary, usage guidelines, sibling contrast, and detailed return fields. It is somewhat lengthy but each sentence adds value. Slightly verbose but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (3 parameters, output schema exists), the description covers the return values comprehensively—totals, P0, stale, duplicates, garbage_venture, overall_health, and next_actions. It provides a complete picture for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context: venture auto-detects, stale_days and dup_min_count are thresholds passed to groom_proposal. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'One-shot ledger health check — totals + P0 + stale + duplicates + garbage,' clearly specifying the verb and resource. It contrasts with sibling tools like delimit_ledger_groom and delimit_ledger_context, making the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use 'at session start (orchestrator session ritual) or nightly review' and not for changes (use delimit_ledger_bulk) or single item inspection (delimit_ledger_query). It also contrasts with sibling 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?
With no annotations provided, the description fully discloses behavior: read-only, calls ai.license.get_license, and returns a dict with tier, validity, expiry, and next_steps. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (when to use, when not, sibling contrast, side effects, returns). It's concise yet comprehensive, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the description is adequate. It mentions the return dict structure, though more detail could be provided; however, the output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The description explicitly notes 'Args: None.' No additional parameter meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports the current Delimit license tier, validity, and expiry. It distinguishes itself from siblings by noting that 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use (inspect license before gated tools, diagnose rejections) and when not to use (install/rotate license), along with clear sibling contrast.
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?
No annotations exist, so the description fully covers behavioral traits: it details side effects (file writing, marker replacement, appending, file creation) and risks (one-way projection, format-drift). No contradictions with missing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, but includes a trailing line 'LED-1165 Phase 2 #5 PR-B.' that is irrelevant for the agent and slightly reduces conciseness. Otherwise, front-loaded with purpose and logically organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (file projection with conditional behavior) and no output schema shown (though context says it exists), the description is complete. It explains all key behaviors, edge cases, and constraints, leaving no critical gaps for selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description adds value by explaining how parameters interact with behavior (e.g., dry_run returns size, target_path default, limit cap). Still, the schema already provides basic semantics, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool projects hot delimit_memory entries into MEMORY.md, with a specific verb and resource. Distinguishes from siblings like delimit_memory_store, delimit_memory_search, and delimit_memory_recent by explaining its unique one-way projection 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' and 'When NOT to use' sections, naming alternative tools for adding new memories or searching. Also includes a sibling contrast paragraph that clarifies the different roles of related 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?
Despite no annotations, the description discloses read-only side effect, specific data types detected, internal token map not exposed, and irreversibility of redact action. Completely 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded main action, usage guidelines, and details. Slightly verbose but every sentence adds value; could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given parameter count 3, full schema coverage, and output schema exists, the description covers all necessary aspects: purpose, usage, behavior, parameter details, detected types, and security note. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaningful context: explains categories (api_key, secret, pii, infra) and that empty means all categories. Provides value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool scans or redacts sensitive data from text, with specific verb-resource pairs. It distinguishes from sibling delimit_secret_store family, which manages stored secrets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (before sending text to external LLMs or publishing) and when not to use (for managing stored secrets, redirecting to delimit_secret_store). Also includes sibling contrast.
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 no annotations, the description fully discloses side effects: mutation, experimental nature, partial results possible, no license gate, no auto-ledger/notify. This is comprehensive behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when, when not, sibling contrast, side effects). Slightly long but every sentence adds value. Front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (experimental mutation), no annotations, and existing output schema, the description covers purpose, usage, side effects, and post-verification steps. Highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 params with descriptions. Description adds value by clarifying that 'version' is the failing release and 'to_version' is the target from delimit_release_history, and gives usage context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb-reource pair: 'Revert a whole environment to a prior release version'. It distinguishes from siblings like delimit_deploy_rollback which is for single-app SHA rollback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use', 'When NOT to use' sections, a typical sequence (alert -> history -> this -> status), and sibling contrast make it clear when to 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?
No annotations provided, so the description fully covers behavioral traits: persistence, scope enforcement, overwrite behavior, no append-only history, no network egress, and audit trail recording. Discloses internal component invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (summary, when to use/not, sibling contrast, side effects). Front-loaded with a one-sentence purpose. Slightly verbose but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensively covers all aspects: purpose, usage guidelines, side effects, and parameter semantics. Contrasts with siblings. No gaps given the tool's complexity and absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage. The description adds context about scope enforcement and purpose of parameters, enhancing understanding beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Write a credential into the Delimit secrets broker store,' providing a clear verb and resource. It differentiates from siblings like delimit_secret_get, delimit_secret_list, and delimit_secret_revoke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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, detailing typical scenarios (onboarding API keys) and exclusions (fetching, listing, revoking, general KV store). Also suggests pairing with delimit_secret_get.
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?
With no annotations provided, the description fully discloses side effects: it always writes an evidence bundle, and on critical findings creates a governance task and sends a notification. It also explains test directory skipping behavior with rationale (LED-1278) and mentions optional env vars (SNYK_TOKEN, Trivy) for enhanced scanning. No contradictions 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (overview, usage, sibling contrast, parameter details, side effects). It is front-loaded with the main purpose. However, it is slightly verbose in places, repeating 'auto-chains evidence...governance task...notification' but overall efficient for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complexity (multiple scans, side effects, env vars), the description covers all necessary aspects: purpose, when to use/not use, parameter details, behavioral side effects, and optional enhancements. An output schema exists (no need to describe return values), so all relevant context for agent decision-making is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters have descriptions. The description adds value by explaining the rationale for include_tests (LED-1278, false positive reduction) and when to set it to true. For target, it restates the default but adds context ('cwd'). This exceeds baseline 3 by providing meaningful extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: audit security and auto-chain evidence + governance on critical findings. It specifies the combination of scans (dependency vulnerability, hardcoded-secret, dangerous-pattern, .env in git) and automatic side effects. It also differentiates from sibling tools like delimit_security_scan, delimit_security_ingest, and delimit_security_deliberate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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, providing clear guidance on appropriate contexts (deploy gate/pre-release) and explicit alternatives for other scenarios (use delimit_security_scan, delimit_security_ingest, or delimit_security_deliberate).
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?
No annotations provided, but the description fully discloses side effects: mutation on start/stop, idempotent start, circuit-breaker stop after 3 consecutive failures, environment variable handling (DELIMIT_SELF_REPAIR_PAUSE=1), and chaining of higher modes when configured.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, but slightly verbose with internal reference (LED-191) and minor redundancy. Each sentence adds value, but could be trimmed for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of daemon control with multiple actions and side effects, the description covers all essential aspects. Output schema exists (per context signals), so return values are handled. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (only 1 parameter), but the description adds context beyond the schema's action description by explaining idempotency, circuit-breaker, and env var behavior. However, the schema already provides a good description of action values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool controls the self-repair watcher daemon, with specific verb 'Control' and resource. It distinguishes from siblings by naming delimit_daemon_status, delimit_inbox_daemon, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with direct tool name mentions for alternatives. Also provides sibling contrast explaining the difference from delimit_daemon_status.
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 (queue for approval vs direct post), rate caps (2/hour, 24/day) with override env vars, sends approval email, and platform-specific tone rules. No annotations exist, so description carries full burden and delivers comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (When to use, Side effects, etc.) and front-loaded purpose. However, it repeats the auto-trigger rule twice and includes platform tone details that could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With high parameter count, full schema coverage, and output schema, the description is exceptionally complete: covers side effects, rate caps, override mechanisms, email flow, platform tone rules, and auto-trigger logic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds context beyond schema for 'draft' (queues for approval), 'context' (strategic reasoning for email), and 'text' (auto-generation). Platform tone rules are separate from parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it posts to social media (Twitter/Reddit), contrasts with siblings (delimit_social_generate, delimit_social_approve, delimit_social_history), and specifies the action 'post'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (immediately after drafting), when not to use (use generate or history), and provides sibling contrast with actionable guidance for the AI 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?
With no annotations, the description fully carries the burden. It details side effects: writes a completion record, flips status from 'dispatched' to 'completed', persists result and files_changed, appends an audit log, and coerces files_changed from comma string to list. It also notes no license gate and no notification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, usage sections, sibling contrast, and side effects. While slightly long, every sentence provides essential information. No waste, but could be trimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, 1 required, 100% schema coverage, has output schema, no annotations), the description covers lifecycle, errors, side effects, and usage context. It fully compensates for the lack of annotations and provides a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaning beyond the schema: task_id is from delimit_agent_dispatch, result is a summary, files_changed is comma-separated paths, and it mentions coercion. This adds value without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Close a dispatched agent task by recording the outcome.' It uses specific verbs (close, recording) and identifies the resource (dispatched agent task). It also distinguishes from siblings explicitly, naming delimit_agent_handoff and delimit_agent_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to use' and 'When NOT to use' sections, including alternatives like handoff, dispatch, and status. It also warns against repeated calls on the same task_id, giving clear guidance on correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers transparency: states it's read-only, names the underlying function call (ai.agent_dispatch.get_agent_dashboard), and outlines the return structure. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with labeled sections (main purpose, when to use/not use, sibling contrast, side effects, args, returns). Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only dashboard tool, the description covers purpose, usage, side effects, underlying function, and return structure. An output schema exists but description adds enough context for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero parameters, schema coverage 100%. The description explicitly states 'Args: None', making it clear. Baseline for no params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for viewing a multi-agent orchestration dashboard, and distinguishes it from sibling tools (delimit_agent_status returns raw records vs. aggregated view). The verb 'View' and resource 'multi-agent orchestration dashboard' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections provide clear guidance, including alternatives (delimit_agent_status for single task status, delimit_agent_dispatch for dispatching work). Sibling contrast further clarifies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description fully bears the burden. It details read-only nature on inputs, side effects of writing to output_file, and the special prepend behavior for 'CHANGELOG.md'. It also describes the two modes and their effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: when to use, when not to use, sibling contrast, two modes. Each sentence adds value, no fluff. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, two modes, and absence of annotations, the description is thorough. It explains mode selection, parameters, side effects, and contrasts with related tools. The output schema exists but description doesn't need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 8 parameters described). The description adds value by linking parameters to modes (e.g., repo_path for git mode, old_spec/new_spec for spec mode) and clarifying the prepend behavior for output_file. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a changelog from git+ledger (git mode) or spec diff (spec mode). It distinguishes itself from siblings like delimit_explain (human prose) and delimit_release_plan (release planning).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (part of deploy gate chain, producing release notes, prepending CHANGELOG.md) and when NOT to use (ad-hoc explanations, release planning) with alternative tools named. This provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers behavioral traits: read-only, failure-isolated partial errors, and npm-bundle behavior. Contradiction-free.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, no unnecessary words, info dense yet readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations but output schema exists, description covers return dict contents, failure modes, and npm-bundle edge case—fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, baseline is 4. Description states 'Args: None' which matches.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a unified 'corp status' snapshot, replacing a ritual. It uses specific verbs and distinguishes from sibling tools like delimit_obs_status and delimit_gov_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections, with concrete alternatives (delimit_daemon_status, etc.) and sibling contrast, providing excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses behavioral traits: side effects (writes transcripts), model invocation details (configured providers, tier differences, BYOK for Pro/Premium), scope enforcements (3-model minimum, Grok tiebreaker), and modes (dialogue vs debate). This covers all necessary behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concisely structured with front-loaded purpose, clear 'when to use/when not to use' sections, sibling contrast, and side effects list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-model deliberation, tiers, scopes), the description covers usage guidelines, behavioral side effects, tier differences, parameter details, and sibling context. With an output schema present, return values are not needed, making the description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While input schema coverage is 100%, the description adds meaning beyond schema by explaining mode types ('dialogue' short turns, 'debate' long essays), default rounds per mode, scope override values ('strategic', 'social', 'operational'), and that empty scope triggers classification. This enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run multi-model consensus via AI-to-AI deliberation (Pro)' and specifies use cases like foundational decisions, pricing, naming, public-facing copy. It distinguishes from sibling tools delimit_models and delimit_security_deliberate, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly outlines when to use (foundational decisions, cross-model contradiction-detection) and when not to use (routine implementation choices). It also contrasts with sibling tools, providing clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, calls ai.deliberation.get_deliberation_status, reads ~/.delimit state. No annotations provided; description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, front-loaded purpose, and concise. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete description including output schema details. Covers all aspects for a status check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; description states 'Args: None.' Schema coverage is 100% (empty). With zero params, baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks deliberation usage and mode, distinguishing it from siblings: delimit_deliberate runs the panel, delimit_models manages keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections, plus sibling contrast. It specifies use before delimit_deliberate to check quota and OAuth state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly discloses side effects: writes markdown/json to ~/.delimit/digest/ for action='run', email delivery gate via env variable, and that action='latest' is read-only. This fully informs the agent of behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections (what, when to use, when not to use, sibling contrast, side effects). Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers purpose, usage guidelines, side effects, and parameter behavior thoroughly. For a 4-parameter tool with no required parameters, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline of 3. The description adds value by explaining the side effects of action values and the email pipeline gate related to send_email and to parameters, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a structured daily digest of loop activity (LED-966)'. It uses a specific verb and resource, and distinguishes itself from siblings like delimit_notify (per-event vs windowed rollup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use (founder daily summary) and when-not-to-use (raw notifications, inbox routing) with alternative tool names. Also contrasts with sibling delimit_notify, aiding 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?
With no annotations, the description fully discloses side effects: 'action="run" / "poll" with live=True fire whitelisted state-changing actions...'. It also details logging to a specific file and the mechanism to pause execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: main purpose, when to use/not use, sibling contrast, and side effects. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no required, high schema coverage, and the existence of an output schema, the description is thorough. It covers purpose, usage guidelines, behavioral traits, and safety mechanisms (dry-run, logging, pause), fully equipping an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 4 parameters. The description adds context beyond the schema, such as the audit log identifier purpose for 'executed_by' and the dry-run behavior for 'live'. This extra value justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run approved work orders from the dashboard inbox (Pro) (Worker Pool v2).' It also distinguishes from a sibling tool: 'delimit_work_orders reads/closes the work order artifact; this is the run surface that turns approved orders into real GitHub side effects.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('as the autonomous executor for human-approved work orders, or to inspect/pause the executor') and when not to use ('to dispatch new agent work (use delimit_agent_dispatch) or close out a work order (delimit_work_orders complete)'). Provides clear sibling contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects: gated by require_premium, appends a run record (status transition, timestamp, repo), and routes response through _with_next_steps for orchestrator hints. Also clarifies the tool does not perform the underlying work itself. With no annotations, the description carries full behavioral burden and meets it thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, when to use/when not, sibling contrast, and side effects. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in a pipeline, 2 parameters, and an existing output schema, the description fully covers the context: pipeline step, licensing gate, side effects, and what the tool does not do. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described in the schema. The description adds context by clarifying that task_id is required despite not being marked as required in the schema, and explains the repo default. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Execute a previously created governance task under policy (Pro)' with a clear verb and resource. It distinguishes itself from siblings like delimit_gov_new_task and delimit_gov_verify by specifying its role as step two of a three-step pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after delimit_gov_new_task, before delimit_gov_verify) and when not to use (for evaluate, mint, or verify). Provides sibling contrast and the full pipeline sequence.
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?
Lists side effects: creates .delimit/policies.yml, ledger dir, and optional settings.json, plus chmod operations. Also mentions no_permissions parameter to skip permission step. Since no annotations exist, the description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with labeled sections, front-loaded key info, no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, side effects, parameters, and sibling contrast. Output schema exists so return value explanation is optional. Complete for a one-time initialization tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds context linking no_permissions to permission side effect, but doesn't add new meaning beyond schema descriptions for project_path and preset. Slight value uplift.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it initializes Delimit governance scaffolding, lists files created, and distinguishes from siblings by explicitly naming delimit_project_config and delimit_scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'when to use' (once per project, first time) and 'when NOT to use' (load config or discover capabilities), along with alternative tool names.
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?
No annotations are provided, so the description carries the full burden. It clearly outlines side effects: writes status='done', attaches ship_proof block with verified=True when commit_sha or pr_url is provided, and mentions future Phase 2 enforcement. This goes beyond basic functionality and discloses important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections ('When to use', 'When NOT to use', 'Sibling contrast', 'Side effects'). Every sentence adds value, and there is no redundancy. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a clear purpose, explicit guidelines, detailed parameter semantics, and an output schema (not shown but flagged), the description provides sufficient context for an agent to correctly select and invoke the tool. It covers all necessary aspects without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the LED-1408 feature: auto-extraction of PR URLs from notes, and the meaning of commit_sha/pr_url as ship proof. This provides context that the schema descriptions hint at but do not fully elaborate, making it easier for the agent to understand parameters' purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Mark a ledger item as done (convenience wrapper).' It uses a specific verb ('mark as done') and resource ('ledger item'). It also distinguishes itself from sibling tools by explaining it is a shortcut for delimit_ledger_update with status='done'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use ('to close out a ledger item with one call') and when NOT to use ('to change other fields' or 'create new items'). It also mentions sibling contrast with delimit_ledger_update. This is comprehensive and helps the agent make correct decisions.
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?
No annotations are provided, so the description carries full burden. It discloses side effects ('writes evidence on breaking findings; auto-chains semver classification and governance evaluation') and behavior under dry_run ('suppresses evidence, notifications, and governance – returns violations + semver only'). Also explains URL handling ('fetched once into a tempfile (size cap, SSRF guard)'). This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with four short paragraphs. Every sentence adds value: purpose, usage guidelines, side effects, parameter specs. It is front-loaded with the primary action, and no unnecessary wording is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, side effects, URL input), the description covers all essential aspects: input types, dry_run mode, evidence writing, and governance chaining. An output schema exists, so the description need not detail return values. The description is sufficiently 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant meaning beyond the schema. It explains the purpose of dry_run (suppressing side effects) and the behavior for spec args (URL handling). While the schema already describes parameters, the description provides vital context for correct usage, justifying a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lint two OpenAPI specs for breaking changes and policy violations.' It specifies the verb (lint), resource (two OpenAPI specs), and scope (breaking changes and policy). It distinguishes from siblings by contrasting with delimit_diff (raw changes) and delimit_diff_report (HTML rendering), indicating this tool enforces policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('as the primary CI gate before merging API spec changes') and when not to use ('for raw change data – use delimit_diff – or quality scoring – delimit_spec_health'). Provides alternative tool names, giving clear guidance for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully discloses behavioral traits. It details side effects: action='poll' with process=True forwards owner-action emails (network writes), action='poll' with process=False is dry-run, and action='status'/'history' are read-only. This clearly communicates potential write operations and safe modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a brief purpose statement, clear when-to-use/when-not-to-use sections, and a side-effects breakdown. Each sentence provides essential information without redundancy. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no required ones), the existence of an output schema reduces the need to describe return values. The description covers purpose, usage, behavioral details, and parameter semantics comprehensively. It also contrasts with siblings, making it contextually complete for an AI agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters and their defaults (100% coverage), so baseline is 3. The description adds value by explaining the behavioral implications of the 'process' parameter (dry-run vs. actual forwarding) and clarifying that 'status' and 'history' are read-only. This extra context helps the agent understand parameter effects beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check inbound email inbox, classify, and route (Pro).' It names specific verbs (check, classify, route) and resource (inbound email inbox). It distinguishes itself from siblings by stating 'delimit_notify is the outbound counterpart' and 'delimit_inbox_daemon controls the long-running daemon; this is a one-shot poll.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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. It advises using this tool to poll the operator inbox and classify emails, and warns not to use it for sending notifications (use delimit_notify) or controlling the polling daemon (use delimit_inbox_daemon). It also provides sibling contrast, making it clear when to 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?
No annotations provided, so description carries full burden. It details side effects: read-only actions gated by licensing, write-capable alert sub-actions being experimental, error handling returning deterministic errors, and that none of the read actions write data or send notifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, front-loaded purpose, and no unnecessary sentences. Every sentence adds value and is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, 4 actions, write vs read), the description is comprehensive. It covers all actions, licensing, error handling, and when parameters are relevant. Output schema exists so return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds significant behavioral context: when parameters are used/ignored (e.g., query ignored for alerts/status), defaults, and sub-actions for alerts. Adds meaning beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a unified observability entry point dispatching to four actions: metrics, logs, alerts, status. It distinguishes itself from sibling aliases by explaining it is the core implementation, and each action is described with its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (as single MCP-registered observability surface) and when NOT to use (internal code paths, prefer specific aliases). Provides sibling contrast and details on each action's appropriate 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?
With no annotations, the description fully discloses read-only behavior, premium licensing gating, internal call chain (_with_next_steps, backends.tools_infra.obs_status), and response wrapping. States no writes, no ledger entry, no notifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though longer, the description is modularly structured: purpose, usage, contrast, side effects, returns. Each section is front-loaded with key information. No redundant sentences; every line adds diagnostic value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers return format (overall, services, checked_at, next_steps, error/ license payload), error handling, and licensing behavior. Given no input parameters and comprehensive output schema description, it is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), and the description explicitly says 'Args: None.' This adds clarity by confirming absence of inputs, preventing any assumption of hidden parameters. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a precise verb+resource: 'Return a high-level health rollup from the observability layer (Pro).' It clearly differentiates from siblings like delimit_obs_metrics (raw series vs. synthesised rollup) and delimit_gov_health (runtime observability vs. governance kernel).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with concrete alternatives (delimit_obs_metrics, delimit_obs_logs, delimit_obs_alerts) and deploy chain pairing advice (delimit_security_audit + delimit_test_smoke). 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?
Discloses side effects (read-only, require_premium gated) and backend call. No annotations provided, so description fully covers 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (when, when not, sibling contrast, side effects, args, returns). Every sentence adds value; not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description briefly notes return type. Covers usage, exclusions, and side effects completely for a simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and description explicitly states 'Args: None.' Baseline 4 for zero-param tool as it adds no extra info beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Report Delimit OS overall status (plans, tasks, tokens) (Pro).' Distinguishes from siblings by naming them 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (session start, status dashboard) and when not to use (governance health, per-plan gates) with alternative tools named.
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?
No annotations provided, so description carries full burden. Details side effects: reads ledger, network reads, writes new intel-class LEDs, dispatches substantive tasks. Also mentions kill switches (env var and sentinel file), per-tick caps, and intentional limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (main sentence, when to use, when not, sibling contrast, side effects). Front-loaded, every sentence earns its place, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for this tool: covers purpose, usage, parameters, side effects, kill switches. Output schema exists so return values not needed. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
100% schema coverage, baseline 3. Description adds extra context beyond schema: explains 'max_dispatch' that targets beyond cap still file intel LEDs but not dispatched, and 'max_monitor' as monitor-call cap. Adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Run one tick of the autonomous github-outreach loop' (specific verb+resource). Differentiates from siblings like delimit_social_target (broader platform set) and delimit_sensor_github_issue (single 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (external scheduler or manual cycle) and when not (backfill of stale items due to per-tick caps). Provides correct alternative pattern (multiple ticks at scheduler interval).
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?
No annotations provided, so the description fully discloses behavioral traits: indicates side effects (init writes, load/model read-only), mentions the internal function called, and notes read-only nature of some actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, no extra words. Structured with summary, usage guidelines, and side effects. Front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, output schema exists), the description is complete: covers all actions, side effects, usage context, and sibling differentiation. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds context about parameter applicability (e.g., task_type only for action='model'), but does not repeat schema details. Adds moderate value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Manage delimit.yml project configuration (load / init / model).' It distinguishes itself from siblings like delimit_gov_status and delimit_playbook, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use ('to inspect, create, or query the project's delimit.yml AI configuration'), when NOT to use ('for governance state' or 'manage prompts'), and contrasts with sibling 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?
Despite no annotations, the description fully discloses behavioral traits: declares 'read-only' and describes the side effect ('Calls ai.social.list_twitter_accounts, which scans ~/.delimit/secrets/twitter-<handle>.json files'). This provides transparency about what the tool does internally, beyond just its interface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: summary, when to use, when NOT to use, sibling contrast, side effects, args, and returns. Every sentence adds value; no fluff. It is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description still adds value by describing the return structure ('Dict with "accounts" list and "count" plus next_steps') and the underlying implementation. This provides complete context for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. Baseline for 0 parameters is 4, and the description correctly states 'Args: None.' This is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear action verb and resource: 'List configured social media accounts.' It immediately states the purpose and distinguishes from siblings by specifying that this tool inventories Twitter/X accounts with credentials, while siblings handle drafting and publishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('to inventory which Twitter/X accounts have credentials available before drafting or scheduling a post') and when NOT to use ('to draft content (use delimit_social_generate) or publish (delimit_social_post)'). Also contrasts directly with siblings, offering clear decision 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?
With no annotations provided, the description fully discloses side effects (read-only, pure validator, no network/writes/notifications) and details the two-stage gate logic (target-side veto and content shape checks). This covers behavioral traits comprehensively, including the rationale for the hard veto (KYC deanonymization). No contradictions with missing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a one-line summary, then clearly labeled sections (When to use, When NOT to use, Sibling contrast, Side effects, two stages). Every sentence serves a purpose, and the information is front-loaded. It is concise yet thorough, avoiding unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description appropriately does not explain return values. It covers usage, behavioral side effects, validation logic, and sibling differentiation. The description provides enough context for an agent to correctly select and invoke this tool, including mandatory bypass conditions and the two-stage process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 how the parameters (body, repo, repo_description, repo_topics, proposed_action) are used in the two-stage validation logic (target veto and content shape). While the schema descriptions are clear, the description contextualizes the parameters within the validation rules (e.g., forbidden phrases, technical anchors), going beyond basic schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a pre-submit gate for autonomous GitHub outreach, specifying the exact verb (check) and resource (substantive content). It distinguishes from the sibling delimit_external_pr_check by stating that this guard is for the substantive-content boundary, while the sibling handles PR duplication. The purpose is explicit and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (last step before submitting to third-party GitHub repos under outreach_substantive, mandatory per CLAUDE.md) and when-not-to-use (internal repos, non-GitHub platforms, non-outreach submissions). It also contrasts with a sibling tool and explains that for PR submissions, both tools are called in sequence. This is exemplary 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 side effects as none, states it uses static analysis via ast (no import, no execution), and does not write ledger, evidence, or notify. Full transparency with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: opening sentence, usage guidelines, sibling contrast, side effects. No wasted words, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, description suffices without explaining return format. Covers purpose, usage, parameters, side effects, and context for a static analysis tool. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds practical context: default paths, resolution, and when to use the human flag for CI pipes. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool scores MCP tool docstrings against TDQS dimensions. Specifies the scope (Python files with @mcp.tool() decorators) and distinguishes from siblings like delimit_lint and delimit_spec_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (as a CI gate before publishing MCP server) and when not to use (runtime tool selection or policy decisions). Contrasts with siblings to guide 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?
With no annotations, description fully discloses read-only nature, premium gating, backend call, and return type (Dict with health status and next_steps). Contradiction 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections; each sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a zero-parameter health check: purpose, usage, side effects, parameters, returns all covered. Output schema covers return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100%. Description adds 'Args: None' for clarity, justifying above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Report vault subsystem health (Pro)' and distinguishes from siblings delimit_vault_search (content) and delimit_vault_snapshot (state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (session start, CI smoke test) and when not to use (content/state), with sibling contrast.
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 states 'Side effects: read-only' and 'Calls ai.ledger_manager.list_ventures', disclosing the underlying implementation and the read-only nature. Since no annotations are provided, this fully covers behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections: summary, usage guidelines, sibling contrast, side effects, args, returns. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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: purpose, usage boundaries, side effects, and return shape. It is fully self-contained and requires no additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly lists 'Args: None' for the zero-parameter tool, which aligns with the empty input schema. It also describes the return value structure. Following the guideline for 0 params, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all registered ventures (auto-registered project directories)', specifying the action (list) and resource (ventures). It distinguishes from sibling tools by later explaining that delimit_context_list inventories artifacts inside a venture, while this lists ventures themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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, giving concrete scenarios and naming alternative tools (delimit_context_list, delimit_memory_recent). This guides the agent on appropriate 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?
Description discloses side effects as read-only, and explains that it counts tools and detects environment capabilities. Since no annotations are provided, the description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections (summary, usage, contrast, side effects, args, returns). It is concise and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and existence of an output schema, the description adequately explains what the tool returns (version, tool count, etc.) and is complete for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema coverage is 100%. Description mentions 'Args: None.' which is sufficient. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns server version, tool count, and environment status. It uses a specific verb ('Return') and distinguishes itself from siblings like delimit_help and delimit_gov_health by explaining what it reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (session start, dashboard, diagnostic) and when not to use (governance health or OS status, with alternative tool names). Also includes a sibling contrast sentence.
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 no annotations, the description declares 'Side effects: read-only' and names the internal function call. It provides a clear return structure overview, ensuring the agent understands the tool is safe and non-mutating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concisely structured with clear sections (description, when to use/not use, sibling contrast, side effects, args, returns). Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description fully covers the tool's purpose, usage guidelines, behavioral notes, and return structure, making it complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and the description explicitly states 'Args: None.' Schema coverage is 100% trivially, and the description adds no unnecessary detail, fulfilling the baseline with perfect clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'View the upcoming content schedule (queued + pending + recent)' with a specific verb and resource. It explicitly distinguishes from siblings by stating what it is not for (publish, manage queue) and names the alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use ('inspect what's queued...') and when-not-to-use ('to actually publish' or 'manage the content queue') scenarios, and contrasts sibling behavior ('delimit_content_queue mutates queue state; this reads').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It details side effects ('read-only on the resolved local path'), input handling ('remote inputs are shallow-cloned into a tempdir'), and internal implementation ('Calls backends.repo_bridge.analyze'). This fully discloses the tool's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with clear sections for purpose, usage, sibling contrast, and side effects. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and an output schema (context indicates it exists), the description fully covers what the agent needs to know: purpose, usage guidance, parameter behavior, and side effects. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'target' is described in the schema with default and type. The description adds value by explaining that remote inputs are shallow-cloned and that the local path is read-only. With 100% schema coverage, the description enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze repository structure and quality (experimental).' It explicitly contrasts with sibling tools delimit_repo_diagnose (quick smoke test) and delimit_repo_config_audit (config-only), making it 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'When to use: for a deep audit of a repo... When NOT to use: for a fast health pass (use delimit_repo_diagnose) or config-only audit (delimit_repo_config_audit).' This clearly indicates the appropriate context and 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?
Discloses read-only side effects, behavior with remote inputs (shallow clone), and internal implementation call. With no annotations, the description fully informs about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, concise sentences, and front-loaded purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and presence of output schema, the description covers all necessary context: purpose, usage boundaries, side effects, input variations, and experimental status. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds value beyond the input schema by explaining that target accepts local path, 'owner/repo' shorthand, or GitHub URL. The schema had 100% coverage, but description clarifies input types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits repository configuration for compliance, listing specific compliance aspects (required files, branch protection, license header). It distinguishes from siblings by naming delimit_repo_config_validate and delimit_repo_analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 for other use cases. This gives excellent 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?
With no annotations provided, the description fully covers behavior: declares 'side effects: read-only' and states the underlying API call ('Calls ai.data_plane.list_drivers'). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose, usage guidelines, side effects, args, and returns. Each section is front-loaded and adds value without superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), the description covers all necessary aspects: purpose, usage context, side effects, return structure. It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage). The description explicitly states 'Args: None,' which is clear and complete. No additional parameter description needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List available data plane drivers and their resource schemas.' It also distinguishes from sibling 'delimit_resource_list' by noting that this lists drivers, not items via a driver.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (inventory external systems) and when not to use (to read data from a driver), with specific alternative tools mentioned.
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?
No annotations provided; description carries full burden. It details side effects per action, storage model under ~/.delimit/secrets/, scope enforcement, audit trail behavior, and error handling. Every action's read/write nature and consequences are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, when to use, sibling contrast, storage model, side effects. Sentences are informative and not redundant. Despite length, every sentence adds necessary detail for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no required params, and output schema exists, the description is complete. It covers all operations, side effects, storage, scope, audit, and error behavior. Agent has enough information to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but description adds significant value beyond schema: action is case-insensitive, name is sanitized for filesystem safety, value is never echoed back, scope is enforced at read time, agent_type and tool are checked against scope. Provides context that aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a unified entry point for five secret operations, distinguishing from sibling tools by explaining that aliases exist for each action and contrasting with other delimit_* tools like delimit_context_* and delimit_memory_*. The verb 'dispatches' and resource 'secrets-broker entry point' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (as single MCP-registered secrets surface) and when NOT to use (from internal code paths, prefer specific alias) and not to use as general key/value store. Provides clear alternative: use specific delimit_secret_* aliases for each action.
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?
No annotations are provided, so the description fully covers behavioral aspects: it declares read-only nature and enumerates internal operations (greps crontab, reads log files, etc.), ensuring the agent understands 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (general description, when to use, when not to use, sibling contrast, side effects, args, returns) and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the description provides complete context: it explains the tool's scope, side effects, and return fields (cron_installed, last_run_ts, etc.) with no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so no parameter documentation is needed. The description explicitly states 'Args: None.' which is clear and helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is a health check for the vendor-news riff system, specifying exactly what it checks (cron firing, drafts landing, rejections) and distinguishes it from sibling tools like 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/5Does 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 with concrete examples, and contrasts with sibling tools, giving clear guidance on 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?
No annotations provided, but description covers side effects: gated by require_premium, wraps sensor+drafter, and details dry_run behavior (cache-friendly, skips JSONL log and drafter). Comprehensive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections: main action, usage guidelines, sibling contrast, side effects. Concise and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavior, and parameter thoroughly. Output schema exists, so return values need not be explained. Complete for an ad-hoc scan tool with good annotations (even though annotations are absent, description compensates fully).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter dry_run has schema description, but description adds significant value: explains cache-friendly polling, skipping JSONL log write, drafter, queue, and rate-cap consumption.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans watchlisted vendor accounts and auto-drafts riffs. It uses specific verbs and resources, and distinguishes itself from siblings like delimit_vendor_news_draft and delimit_vendor_news_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (ad-hoc execution) and when not to use (single tweet or subsystem health), and provides sibling contrast with clear alternatives.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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