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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so 'No live data is fetched' mostly restates the openWorld hint. The description does add real context about what the run reports (drift, evidence quality, sensitivity, estimate volatility) and warns about argument-shape pitfalls, but it says nothing about cost, latency, determinism, or how the likelihood ratios are combined.

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 and reported outputs are front-loaded in the first two sentences, which is efficient. However, the trailing sentences are a mix of genuinely useful shape guidance ('Put tool fields inside inputs') and filler or confusing instructions ('Follow its required fields and exact choices', 'Do not pass the REST calculator field inside MCP arguments') that an MCP agent has no way to act on.

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?

This is a deeply nested tool (30-signal array, 60-point history array, nested inputs) and the description covers only the wrapping rules, not how the estimation works or what constraints matter. An output schema exists so return values need not be explained, which keeps this at a minimum-viable level rather than lower.

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 should compensate, and it only partially does: it clarifies that fields belong inside the nested 'inputs' object and that 'units'/'modelVersion' are conditional. It does not explain the meaning or interaction of basePercent, likelihoodRatio, quality, ageDays, feasibility, previousPercent, or the history/historyIntervalDays pair, leaving most nested-field semantics to name inference.

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 gives a specific verb ('Estimate') plus the resource ('a conditional scenario from an explicit probability and grouped evidence') and enumerates what is reported: drift, evidence quality, sensitivity, and optional historical volatility. That is enough to understand the operation, but it never differentiates this tool from near-name siblings such as buscalc_fluxneed or buscalc_need_velocity, and the term 'conditional scenario' stays abstract.

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 when-to-use guidance at all: nothing says which forecasting/estimation sibling to pick, what precondition (min 3 history points, min one signal) makes this tool appropriate, or when it should be avoided. The only guidance is invocation mechanics ('Put tool fields inside inputs', 'Supply units or modelVersion only when listed in inputSchema'), which is not usage selection.

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