p6_float_analysis

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description nonetheless adds substantive behavior: exclusions (completed, LOE, WBS summary), bucket semantics including the guarantee that every value lands in exactly one bucket, the wrinkle that comparison happens in hours and is never rounded, and the internal consistency checks (no_value, all_ranges_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?

The purpose is front-loaded and nearly every clause carries functional information about bucket boundaries, output fields, or filters. It is a dense single paragraph with no visual structure, which hurts scanability for a long definition, but there is little filler to cut.

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 complex analytical tool with no output schema and low schema description coverage, the description is thorough: it defines the output shape (per-bucket total_float/free_float counts, percentages, samples), the stats block, and the integrity fields. An agent can interpret the result and call the tool correctly without further 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 description coverage is only 25%, so the description must compensate. It explains edges_days bucketing in detail, restates sample_size's effect ('the sample_size lowest floats'), clarifies include_milestones, and covers wbs_name_contains / code_type / code_value / include_child_codes by delegating to p6_query_activities. The delegation rather than inline explanation keeps it short of a 5, since the agent must open another tool to fully understand the code filters.

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?

Names a specific computation (total and free float distribution) on a precisely scoped resource (open activities of the last F9), and explicitly excludes completed, LOE and WBS-summary activities. It also names the sibling whose filter semantics it mirrors (p6_query_activities), giving the agent a concrete anchor, though it never contrasts with p6_critical_path, the most adjacent tool.

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?

Usage is implied (analyze float distribution of an activity set) and the filter parameters are explicitly delegated to p6_query_activities, which is useful routing. However, there is no explicit statement of when this tool is preferable to p6_query_activities or p6_critical_path, nor any stated prerequisites.

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