uncertainty_monte_carlo

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

Annotations only declare the generic profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false, idempotentHint=false), so the description carries the real burden and does so well: it discloses that every valid realization is independently checked, that failures are published alongside results, that no hidden resampling/clipping occurs, and that percentiles are labelled conditional when draws fail. It omits whether the call is synchronous or returns a job handle, which is the one behavioral trait an agent still has to guess.

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?

Four tight sentences, front-loaded with the computational method followed by output and guarantee clauses; no filler. It is jargon-dense ('linear-rank statistics') and never states the plain payoff (P10/P50/P90 STOIIP/GIIP), which slightly slows first-pass comprehension but does not pad the text.

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, deeply nested, non-read-only tool with no output schema, the description covers methodology, validation behavior and delivered artifacts (draws CSV, S-curve PNG, empirical correlations) reasonably well. It still leaves out execution shape (sync vs. job/artifact handle, where results are retrieved) and any pointer to compute_targets_list or follow-up comparison tools, which matters for a run this heavy.

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% and the nested request schema documents seed, samples, correlation, correlation_space and metric thoroughly, so the baseline is 3. The description adds a little meaning by framing the correlation as latent/Gaussian-copula and the bounds as marginal, but it adds no syntax, ordering, or shape guidance for the correlation matrix beyond what the schema already states.

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 method and resource: seeded regional Monte Carlo over bounded marginal distributions with a Gaussian-copula correlation matrix, producing P90/P50/P10 statistics. An agent can tell this is probabilistic volumetrics rather than a single deterministic run. It never names the nearest siblings (sensitivity_tornado, regional_volumes, scenarios_run, ensemble_plan), so differentiation still requires inference.

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?

There is no explicit when-to-use, when-not-to-use, or alternative routing anywhere in the text. Given that sensitivity_tornado, scenarios_run, regional_volumes and ensemble_plan all sit adjacent, the absence of any selection guidance is a real gap. Prerequisites (user-confirmed parameters, valid properties artifact) are only implied by phrases like 'explicit bounded'.

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