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

Without annotations, the description must carry the transparency burden. It discloses that instrumentation is always enabled, which is a key behavioral trait, and mentions structured error/warning output and a buildId. However, it omits potential side effects (e.g., DerivedData creation, system modifications) and does not explain failure modes, so it is only partially transparent.

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

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

The description is a single sentence that packs all key information: the action, the always-on instrumentation, the structured output, and the buildId for later reporting. There is zero waste or redundancy, making it appropriately concise and front-loaded.

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

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

While the description gives a solid high-level overview, it lacks details on the expected output structure (no output schema), parameter formatting for the undocumented fields, and any prerequsites or side-effect caveats. For a build tool with 5 parameters, it is adequate but leaves notable gaps in fully guiding an agent.

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

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

Schema description coverage is low (40%): only deep and projectPath have descriptions, while scheme, destination, and configuration are undocumented. The tool description does not compensate for these missing semantics; it only mentions instrumentation generally without linking to specific parameters. This leaves the agent guessing about accepted values for three out of five parameters.

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

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

The description clearly states 'Run an Xcode build' and distinguishes this tool by noting build-timing instrumentation is always enabled, returning structured errors/warnings and a buildId for build_timing_report. This differentiates it from sibling tools like cache_inspect and build_timing_report.

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

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

The description provides clear context: this is the tool to use when you want to run a build with timing instrumentation and obtain a buildId for later reporting. It does not explicitly mention alternatives or when-not-to-use, but the specific mention of instrumentation and buildId implies the intended usage scenario.

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

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

With no annotations, the description carries full responsibility. It discloses that output is ranked, slow, and tied to a previous build_run, which is useful. However, it doesn't mention side effects (likely none), permissions, or what happens if no previous build exists. Adequate but not rich.

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?

A single, front-loaded sentence that conveys all essential information without unnecessary words. It is perfectly scannable and immediately understandable.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the core purpose well. However, it could specify the return format (e.g., array of objects with timings) to fully equip the agent, as the tool appears to generate a report.

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

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

Schema description coverage is 100% with the buildId parameter already documented as defaulting to the most recent build_run. The description's language 'previous build_run call' aligns with this but adds no new insight beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb 'Return' and clearly identifies the resource ('ranked slow build task categories/functions/expressions') and context ('for a previous build_run call'). It effectively differentiates itself from sibling tools like build_run or cache_inspect by focusing on report generation.

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 phrase 'for a previous build_run call' implies usage after build_run, but there is no explicit guidance on when to choose this over alternatives or any exclusion criteria. Sibling tools are distinct enough that usage is inferable, but the description doesn't make it explicit.

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 burden of revealing behavior. It states a destructive action and scope but doesn't explicitly warn about irreversibility, permission requirements, or side effects. The 'Requires confirm: true' adds a small but useful safety note. More transparency about the consequence of deletion would improve this score.

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?

A single, well-structured sentence communicates purpose, constraints, and prerequisite without wasted words. Every element contributes 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?

For a destructive operation with no output schema or annotations, this description covers input scope, source data, and an important requirement (confirm). It could mention that deletion is permanent, but given the simple two-parameter tool and clear sibling context, it is adequately 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?

The schema only documents 'path' with a description, leaving 'confirm' as a bare boolean. The description compensates by clarifying 'Requires confirm: true', which adds meaning about how to use the confirm parameter. While path semantics come from the schema, the additional constraint on confirm bridges the coverage gap effectively.

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 'Delete a specific DerivedData or ModuleCache.noindex path', using a specific verb and resource. It also distinguishes itself by referencing 'previously reported by cache_inspect', which differentiates it from siblings like build_run or config_lint.

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 implies usage as a follow-up to cache_inspect, naming the source tool and stating a prerequisite ('Requires confirm: true'). It provides clear context for when to use this destruction tool rather than alternatives, though it doesn't explicitly say when not to use 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?

No annotations are present, so the description carries the full burden. It discloses the reporting aspects (size, staleness, bloat) but does not explicitly state that it is a read-only operation, whether it has side effects, or how it computes metrics. It is not contradictory, but lacks depth.

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 concise sentence that front-loads the action and object. No redundant wording, 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 the tool has zero parameters and no output schema, the description covers the essential purpose and scope. It lists the key aspects (size, staleness, bloat) and target (DerivedData, module cache). A note about read-only behavior would improve completeness but is not essential for selecting/invoking.

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 has zero parameters, and description supplies no additional parameter info, which is acceptable because there are no parameters. Baseline for 0 params is 4; the description does not need to compensate for anything.

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

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

Description uses specific verb 'Report' with clear resource 'DerivedData and module cache' and scope 'for all projects' (size, staleness, bloat). It fully distinguishes from siblings like cache_clean (which cleans) and build_timing_report (which reports timing).

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 on when to use this tool versus alternatives. It does not mention that cache_clean is for cleaning rather than reporting, nor any exclusions. The usage context is implied but not explicitly stated.

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

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

No annotations are provided, so the description carries the full burden. 'Scan' reasonably implies read-only and the scope is stated, but key behaviors are undisclosed: what the output looks like, how .xcconfig files relate to the lone pbxprojPath input, and error handling for invalid/missing paths. Adequate but not transparent.

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

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

One front-loaded sentence with zero filler: verb first, target second, purpose third. Every word 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?

With no output schema and no annotations, the description should compensate by explaining return format but does not. The .xcconfig handling path is unresolved, and there is no severity/fix guidance. For a simple 1-param lint tool the gap is moderate — usable but the agent must guess at outputs.

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% — the single pbxprojPath parameter is clearly described in the schema, so baseline 3 applies. The description adds no extra parameter meaning; it even introduces mild ambiguity by mentioning .xcconfig without explaining how those files are discovered from pbxprojPath.

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?

Specific verb 'Scan' + specific resources '.pbxproj/.xcconfig' + clear objective 'known build-speed anti-patterns'. This clearly differentiates from siblings: build_run executes, cache tools manage entries, build_timing_report profiles execution — config_lint is static analysis of build config files.

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

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

The purpose statement implies usage context (checking config for build-speed issues), but there is no explicit when-to-use/when-not-to-use guidance, no named alternatives, and no exclusions. An agent would infer usage from the verb rather than being told.

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