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

With no annotations provided, the description carries full responsibility for disclosing behavior. It goes well beyond a shallow summary: it explains the simulation is calibrated from real market data, lists the algorithmic pipeline, specifies 10,000+ paths, and says fallback priors are clearly labeled. This is strong contextual disclosure.

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 longer than average but well-structured with a clear lead sentence, an explicit alternative, and a numbered methodology. Every section contributes useful selection and behavior information, though some repetition of 'Monte Carlo' and 'not fake data' could be trimmed.

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 stochastic simulation tool with no annotations, the description is unusually complete: it covers purpose, alternatives, data source, algorithm steps, fallback behavior, and response labeling. An output schema exists, so the lack of detailed return-value prose is acceptable.

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 the baseline is 3. The description adds extra meaning by explaining how the simulation horizon, model choice, and number of paths fit into the math: e.g., weekly resampling, annualized drift/volatility, Merton/GBM, and 10,000+ paths. This reinforces and extends the schema without fully re-documenting each parameter.

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 opens with a specific verb+resource: 'Run a Monte Carlo price simulation for a trading card' and explicitly names it as the stochastic alternative to get_forecast. This clearly separates it from sibling pricing and forecast tools.

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 explicitly tells the agent to use get_forecast for the default forecast and positions simulate_price as the Monte Carlo alternative. It also states the fallback behavior for insufficient price history, which helps the agent decide whether the tool can still return useful results.

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