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

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered. The description adds real behavioral value: it discloses the bootstrap mechanism, the percentile outputs (P50/P80/P90/P95) and the condition under which calendar dates appear, plus the optional splitRate scope-creep modeling.

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 tight sentences, front-loaded with the question it answers, then mechanism, then outputs, then the optional parameter. No filler and each sentence carries distinct information.

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 an 11-parameter tool with a full output schema, the description covers the core mental model (inputs, bootstrap, outputs, scope creep) adequately. It omits discussion of distribution choices and iteration counts, but those are fully specified in the schema and annotations already cover safety.

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%, so every parameter is already documented in the schema. The description only gestures at throughputSamples, backlog, and splitRate at a conceptual level, adding no syntax or format detail beyond the schema; baseline 3 is correct.

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?

States a specific verb+resource ('forecast how many periods are needed to clear the backlog') and frames the exact question it answers ('when will it be done?'). It distinguishes itself from estimate-based siblings by contrasting 'historical throughput instead of per-task estimates', though it does not name forecast_duration/pert_estimate explicitly.

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?

Specifies the required inputs (throughput per recent period + remaining backlog) that select this tool over per-task estimate approaches, and notes the optional start date/period length that unlocks calendar output. No explicit when-not or named alternative, so it stops short of a 5.

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?

Annotations already establish readOnly/idempotent/closed-world safety, and the description adds real behavioral value: it discloses the percentiles returned, the distribution shape output, and the conditional behavior when `budget` is supplied. It stops short of discussing iteration cost or runtime, but the safety profile is well 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, each earning its place: what it does, what it returns, and when to prefer it. Purpose is front-loaded before the outputs and the use-case note.

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 simulation tool with one required parameter, a full schema, and an output schema, the description supplies everything an agent needs to decide and invoke correctly; return-value detail is properly left to the output schema.

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, but the description goes beyond it by explaining the semantic intent of the optimistic/most-likely/pessimistic triple (a three-point estimate summed into a total) and the meaning of the optional budget cap. Reproducibility of the seed is left to the 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?

States a specific verb and resource ('Run a Monte Carlo simulation over a list of cost line items... probabilistic forecast of the TOTAL budget') and enumerates the outputs (P50/P80/P90/P95, mean, stdev, distribution shape). This clearly separates it from the sibling forecast_duration/forecast_completion tools, which forecast other quantities.

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?

Gives a clear use context ('Ideal for building a contingency-aware estimate instead of a single point number') and explains the optional `budget` use case, but never references siblings like pert_estimate or sensitivity_analysis, so no explicit when-not 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 readOnly/idempotent/closed-world annotations already covered, the description adds genuinely useful behavior: results are a serial sum (no parallelism modeled), the fixed default seed makes runs reproducible, and specific outputs (P50/P80/P90/P95, mean, stdev) are named. It does not contradict the annotations and surfaces the key modeling assumption.

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?

Front-loads the action and output, then adds the value proposition and the crucial serial-summing caveat. Every sentence carries information; nothing is redundant filler.

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?

An output schema exists, so the brief return summary suffices; annotations cover the safety profile; and the description supplies the one thing an agent could otherwise miss (tasks are run in series). Complete enough to invoke correctly without opening the schema.

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 schema already documents all six parameters thoroughly. The description only lightly reinforces `target` ('get the probability of finishing within it') and the three-point estimate shape, adding little beyond what the schema text provides, so the baseline of 3 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?

States a specific verb+resource: 'Run a Monte Carlo simulation over a list of tasks ... to produce a probabilistic forecast of the TOTAL project duration.' The scope ('Tasks are summed (run in series)') is concrete and separates it from cost-oriented cousins, but it never names or contrasts the closest sibling (forecast_completion), so differentiation is only implicit.

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?

Gives a clear when-to-use rationale and an alternative: 'Use this instead of guessing a single deadline.' It also implies the precondition (three-point estimates per task). It stops short of routing the agent away from sibling tools such as pert_estimate or forecast_completion, so no explicit exclusions.

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?

Adds substantial context beyond the readOnly/idempotent annotations: it is 'instant and deterministic', uses a 'normal approximation', and assumes 'tasks are independent and summed'. These methodology and assumption disclosures materially shape how an agent should trust and apply the result.

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 tight sentences with zero waste: capability, outputs, and usage context are front-loaded, followed by the key independence/sum assumption. Every clause 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?

An output schema exists so return values need not be detailed, yet the description still summarizes them usefully. Combined with the stated assumptions and determinism, an agent has everything needed to invoke and interpret this 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 description clarifies that tasks carry optimistic/most-likely/pessimistic values and that confidence levels produce 'value achievable at each confidence level', adding meaning beyond the schema. With 67% schema coverage the 'unit' parameter is not elaborated, so it is slightly short of complete.

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?

States a specific verb and resource ('Compute a classic PERT estimate') and names the exact inputs (optimistic/most-likely/pessimistic). It also contrasts itself against the Monte Carlo forecast sibling and the analytical approach, so an agent can distinguish it from the forecast_* family.

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 says to 'use it for a quick estimate or to cross-check a Monte Carlo forecast', giving a clear selection context against the alternative predictive tool. It stops short of naming the sibling tools directly or stating when-not to use it, so it falls just under full marks.

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 readOnlyHint, openWorldHint=false, and idempotentHint already declared, the description adds real behavioral context: it performs a Monte Carlo simulation, computes correlation and variance share per task, and ranks results. It does not mention the reproducible-by-default seed behavior (left to the schema) or the compute cost of large iteration counts, but it goes meaningfully beyond the annotations.

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?

Purpose is front-loaded in the first clause, followed by mechanism, output shape, and a memorable framing metaphor. Four tight sentences with no filler, each earning 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?

An output schema exists, so return values need not be explained, and the description covers purpose, mechanism, and output ranking adequately. It could note prerequisites (minimum two tasks, distribution choice) that live only in the schema, but nothing essential for correct invocation is missing.

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 80% and the schema already documents seed, unit, iterations, distribution, and the nested task fields in detail. The description adds no parameter-level syntax or format guidance beyond what the schema provides, so the baseline 3 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 states a specific verb+resource (identify which tasks drive uncertainty in a project total) and explains the mechanism (runs Monte Carlo, computes per-task correlation and variance share). It returns ranked drivers and even frames the output ('the data behind a tornado chart'), which clearly separates it from the forecast_* and pert_estimate siblings.

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 conveys the value proposition ('so you know where reducing estimate uncertainty or de-risking the work has the most impact'), which implies when to reach for it. However, it never names an alternative or states when NOT to use it versus forecast_duration, forecast_cost, or pert_estimate, leaving the routing decision to inference.

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