dcma_assessment

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: it reports per-check metric/threshold/pass-fail and example offenders, explains the baseline fallback chain (baseline_path -> stored baseline -> P6 planned dates labelled), and clarifies the float_source options (computed vs stored). This goes beyond the annotations and helps an agent predict behavior.

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

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

The description is a single dense paragraph that packs a lot of information: purpose, check list, reporting format, baseline requirements, float_source options, and the special check parameter behavior. Each sentence contributes new value. It could be improved with bullet points for readability, but it is not overly verbose and front-loads the core purpose.

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

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

For a tool with 7 parameters and no output schema, the description covers the essential aspects: it lists all 14 checks, explains the reporting (metric, threshold, pass/fail, example offenders), details baseline and float_source options, and clarifies how to request a full offender list. It omits details on 'limit' and 'project', but these are likely auxiliary; overall the agent has enough to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'check' (by name or number, e.g., '6_high_float' or '6'), 'float_source' (computed or stored), and 'baseline_path' (a baseline schedule file). It also mentions 'baseline_project' implicitly through the baseline context. However, it does not explain 'limit', 'project', or 'baseline_project' individually. Given the zero coverage, this partial compensation earns a 3.

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 purpose: 'DCMA 14-point schedule assessment' with the specific checks enumerated. This distinguishes it from sibling tools like logic_check (which covers only one check) and compare_schedules (which compares schedules rather than assessing against DCMA thresholds). The verb and resource are 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?

It provides context on when to use the tool (for a comprehensive 14-point assessment) and notes prerequisites: 'Missed tasks / BEI / CPLI need a baseline' with fallback options. It also explains how to get full offender lists for a specific check (check='6_high_float' or '6'). However, it doesn't explicitly state when to use an alternative like logic_check for a single check, but the comprehensive nature is implied.

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