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

With no annotations, the description carries the full burden and does so excellently. It discloses dry-run default, per-file plan statuses, skip/overwrite behavior for existing files, force semantics, and explicitly states it 'Never touches app code or secrets-bearing CD workflows.' This is rich behavioral context beyond any schema.

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

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

The description is dense and front-loaded with the main action, but it is longer than the 'two sentences' ideal. However, every sentence contributes essential information (component taxonomy, dry-run behavior, force semantics, safety boundary). No filler, but a slightly tighter structure would earn a 5.

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

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

The description is fully complete for a complex tool with 5 optional parameters and an output schema. It covers purpose, usage context, parameter semantics, and safety limitations. Since an output schema exists, not describing return values is appropriate.

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

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

Although schema coverage is 100%, the description adds substantial meaning: it details the contents of each component (ci, security, etc.), explains auto-detection for starter, describes dry_run behavior and force implications on dirty trees. This goes well beyond the schema property descriptions.

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

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

The description clearly states the tool's action ('Lift a starter's CI/CD layer into an EXISTING repo') and specifies the resource (CI/CD components). It distinguishes itself from siblings by framing it as the 'remediation half of the audit loop' opposite to audit_security/audit_release, and from create_project by noting 'without re-scaffolding.' This meets the 5-level bar for specific verb+resource+scope and sibling differentiation.

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

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

Explicitly specifies when to use: after audits diagnose, as the remediation step to install missing files. It also implies when not to use (instead of re-scaffolding with create_project) and names the diagnostic sibling tools. This is clear, contextual usage guidance with exclusions implicit.

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

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

With no annotations, the description discloses key behaviors: makes outbound HTTPS requests and never mutates. It also previews the return concept (per-destination drift) with possible states. It doesn't mention auth or rate limits, but public APIs make this less critical.

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

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

Two sentences with no filler. The first sentence states purpose, the second covers behavior and output. Every clause adds value.

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

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

Given one optional parameter, multiple registries, and an output schema, the description covers inputs, side effects, and expected results. It's complete for an agent to invoke correctly without additional documentation.

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

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

Schema covers 100% of the single parameter (`path`) with a clear description including default behavior. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('Check whether') and resource ('local repo's version has been published to destination registries'), listing exact registries. It clearly distinguishes from sibling tools like audit_release or audit_security by focusing on publication drift across specific registries.

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

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

The description makes the tool's use case clear: verifying publication of a repo version to registries. It doesn't explicitly mention when not to use it or point to alternatives, but the specificity provides clear context for when an agent should select it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only; does not rewrite files' and clarifies that it produces 'advisory keyword risk summaries' rather than enforcement. This is valuable beyond the raw schema and gives an agent essential safety expectations, though it could go further (e.g., whether scanning is recursive) if that information were relevant.

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

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

The description is two sentences, with the first sentence front-loading the core scope and the second sentence adding essential behavioral clarifications. Every clause earns its place; there is no redundant or filler wording.

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

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

Given the tool has only one optional parameter, an existing output schema, and a read-only, non-destructive nature, the description is complete. It explains what is audited, the categories of analysis, the read-only guarantee, and what the tool is not for, leaving no significant gap for an agent to select or invoke it correctly.

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

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

The input schema already documents the single `path` parameter thoroughly with a description and default behavior, achieving 100% schema description coverage. The tool description does not add additional parameter-level semantics beyond reinforcing the resource being audited ('instruction files'), so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb ('Audit') and a clear resource ('local agent instruction files'), then enumerates precise audit dimensions: exact same-file duplicates, cross-file surface overlap, and advisory keyword risk summaries. It also distinguishes itself from siblings by explicitly excluding semantic drift and safety enforcement, 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.

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

The description states when to use the tool: to audit local agent instruction files for duplicates, overlap, and keyword risks. It also gives exclusions ('is not semantic drift or safety enforcement') and emphasizes read-only behavior, which helps an agent avoid invoking it for rewrite tasks. However, it does not explicitly recommend alternative sibling tools for those excluded use cases, so it stops short of full alternative guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only; never mutates the repo,' which is a key safety trait. It also describes the checks performed. However, it does not mention potential side effects like network access, caching, or timeouts, but for a read-only audit tool, the disclosure is adequate.

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

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

The description is two concise sentences with no filler. The first sentence states the core purpose and scope, the second lists specific checks and the read-only guarantee. Every sentence earns its place.

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

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

Given the tool has an output schema (so return values are covered elsewhere), the description provides all necessary context for invocation: what it does, which repository, what it detects, and its mutability constraints. The sibling tool context further clarifies its role. No significant information gaps remain.

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

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

The schema coverage is 100% for the single parameter 'path', which already provides clear meaning. The tool description adds no additional parameter-specific detail beyond what the schema states. Since the schema handles parameter documentation fully, a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Audit') with a clear resource ('local repo') and purpose ('release-readiness'), and enumerates concrete checks (CHANGELOG drift, version-bump, publish-workflow). This distinguishes it from sibling audit tools (audit_cd, audit_security, audit_instructions) by its focus on release-readiness.

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

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

The description clearly indicates the tool is for auditing release-readiness against a specific quality bar, and lists what it detects. While it doesn't explicitly mention when NOT to use it or name alternatives, the scope is defined well enough that an agent can infer appropriate use cases based on the sibling tool names.

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

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

Explicitly states 'Read-only' and enumerates the specific checks performed, providing behavioral context despite no annotations. Does not mention potential side effects, but read-only covers the main risk.

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

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

Single sentence, front-loaded with the audit target, then lists checks, and ends with read-only. No wasted words.

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

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

Covers the tool's purpose, scope, and read-only nature; output schema exists for return details. For a single-parameter read-only audit, this is adequate.

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

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

Input schema fully documents the single 'path' parameter with default and usage guidance; description adds no param details beyond schema coverage.

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

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

Clearly states it audits a local repo for baseline security CI hygiene, listing specific checks (gitleaks, CodeQL, etc.). Distinguishes from sibling audit tools (audit_release, audit_cd, audit_instructions) via the security focus.

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

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

Implies usage for security CI hygiene validation against the Starter Series quality bar, but does not explicitly state when to use this over siblings or provide exclusion criteria.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It only states the action 'scaffold' without mentioning side effects like filesystem changes, git initialization (which is a parameter), reversibility, or error conditions. The description adds no behavioral context beyond the verb itself.

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

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

The description is a single, concise sentence that states the tool's purpose with no wasted words. It is front-loaded and avoids repetition of schema information, making it highly efficient.

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

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

Despite having a rich schema and output schema, the description is too minimal for a scaffolding tool. It doesn't explain the workflow, what happens after execution, how to select a template, or any side effects, which is essential 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.

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

All 5 parameters have descriptions in the input schema, providing 100% coverage. The tool description itself does not mention any parameters, so it adds no extra meaning beyond what the schema already provides. Per baseline rules, a score of 3 is appropriate when schema covers parameters.

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

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

The description uses a specific verb 'scaffold' and resource 'new project', clearly indicating the tool's core function. It also references 'Starter Series template', which gives context about the template source. However, it does not explicitly differentiate from sibling tools like add_component or list_templates within the description itself, relying on the schema's template description for that.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or that one should first call list_templates to choose a template. This is a clear gap given the related sibling tools.

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

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

With no annotations provided, the description carries the burden of disclosing side effects, and it does so well by stating 'Read-only by default' and explaining how to enable writing via write=true and output_path. It also clarifies that the report is Markdown and client-ready, but does not mention failure modes or permissions beyond what is implied.

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

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

The description is two sentences, front-loads the tool's core action, and includes all essential information—the sub-tools, the output, the read-only default, and the write mechanism—with no unnecessary words.

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

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

This compound tool has three parameters and an output schema; the description covers the orchestrated sub-tools, the return format, and the read/write behavior, which is sufficient for safe invocation. Since an output schema is present, not detailing the report structure is acceptable.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value by specifying the default report filename 'launch-proof-report.md' and clarifying that output_path is only used when write=true. This goes beyond the schema's property descriptions and helps the agent understand parameter interplay.

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

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

The description clearly states what the tool does: it runs four named audit tools together and returns a client-ready Markdown Launch Proof Report. This specific verb+resource combination distinguishes it from sibling tools, especially the individual audit tools it orchestrates.

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

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

The description says to run audit_release, audit_cd, audit_security, and audit_instructions together, implying this tool is used when a combined launch-readiness report is needed. It gives clear context but does not explicitly state when not to use it or compare it directly to running the sibling audit tools individually.

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

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

No annotations are provided, so the description carries the burden. 'List' implies a read-only operation, but the description does not explicitly state side effects, authentication needs, or return format. However, for a simple list tool, this is minimally acceptable.

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

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

The description is a single, concise sentence that fully conveys the tool's purpose without redundancy. Every word adds value.

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

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

Given that the tool has no parameters and an output schema exists, the description is complete. It fully explains what the tool returns (a list of templates) and requires no additional context. The full sentence 'List all available Starter Series project templates' provides sufficient information for an agent to invoke the tool correctly.

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

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

The tool has zero parameters, so the schema provides no parameter descriptions. The description appropriately states the scope ('all available') and does not need to explain any parameter semantics. The baseline of 4 for zero parameters applies.

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

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

The description uses a specific verb ('list') and resource ('all available Starter Series project templates'), making it distinct from sibling tools like generate_launch_proof_report or create_project. It clearly states what the tool does.

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

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

The description implicitly conveys usage: this is for retrieving templates, while sibling tools are for generating reports, adding components, or creating projects. Although no explicit exclusions or alternatives are mentioned, the context is clear enough for an agent to choose this tool appropriately.

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

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

With no annotations, the description carries the disclosure burden. It transparently reveals the file creation behavior and the overwrite option via `force`, plus adds valuable context about the consuming plugin. It doesn't mention potential side effects beyond overwriting, but the key behavioral traits are covered.

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

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

Three sentences with no wasted words. The description front-loads the primary action and includes necessary context about the plugin and force flag.

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

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

The description, combined with high schema coverage and an output schema, is nearly complete. It explains the file's purpose and consumption but doesn't address template detection failure or other edge cases, so just shy of fully complete.

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

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

Schema coverage is 100% and the description's mention of `force: true` essentially restates the schema's force property. No new semantic meaning is added beyond what's already in the input schema.

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

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

The description clearly states the tool generates a `claude-security-guidance.md` file at the repo root, with a specific verb and resource. However, it doesn't explicitly contrast with sibling tools like `audit_security` or `list_templates`, so it lacks a differentiation statement.

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

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

The description implies usage for seeding security guidance and includes a parameter tip about `force: true`, but no explicit when-to-use vs alternatives is given. The context about the plugin being consumed in-session suggests when it matters, but exclusions are absent.

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