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

The description indicates the tool audits the workbook and returns a report, implying a read operation but without explicit statements about non-destructiveness or permissions. With no annotations, the description partially informs behavior but lacks completeness.

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 extremely concise, with two sentences: the first states the core action, the second adds reusable rule configuration and return type. No unnecessary words, and critical information is front-loaded.

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?

The description covers the tool's function and return type, and an output schema exists (not shown). However, it omits prerequisite context (e.g., workbook must be open) and does not address whether the audit modifies the workbook, leaving gaps for an agent.

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 sole parameter 'workbook_name' has no schema description, but the description connects it to the workbook being audited, adding meaning. For a single parameter, this is effective, though more detail (e.g., format or constraints) would improve clarity.

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 clearly states the tool runs a model audit against a workbook and returns an AuditReport with findings. However, it does not differentiate this tool from sibling tools like 'diagnose_workbook' or 'plan_risk_model', leaving some ambiguity about unique purpose.

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?

The description provides no guidance on when to use this tool versus alternatives (e.g., 'diagnose_workbook'), nor does it mention prerequisites like workbook being open. The rule location details are implementation-focused, not usage-oriented.

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?

No annotations provided, so description must cover behavioral traits. It states the tool reads per-iteration samples and reports metrics without modification, but does not explicitly declare read-only behavior, auth needs, or side effects. Adequate but not thorough.

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?

Two sentences packed with information: main action, metrics reported, usage requirement. No filler or unnecessary words. Front-loads key verb and resource.

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?

Given the tool's complexity (5 params, 2 required) and the presence of an output schema, the description provides sufficient context: what it does, prerequisites, and key metrics. Minor misses like explicit read-only declaration but overall complete.

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%, baseline 3. Description adds value by explaining the role of actuals, output_name, and the prerequisite of running simulation first. It also clarifies that intervals default is used, adding context beyond 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?

Description clearly states the tool's purpose: backtest simulation output against actuals to assess calibration. It specifically mentions PIT, coverage, and bias, distinguishing it from sibling tools like get_simulation_results or compare_distributions.

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?

The description implies usage after running a simulation ('run the simulation first') and requires passing actuals. However, it does not explicitly state when not to use this tool or mention alternatives among siblings, leaving agent without clear triage 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?

No annotations provided, so the description carries full burden. It details report components and notes each call produces one sheet, but fails to disclose that the target sheet will be replaced if it already exists (schema states 'Replaced if it already exists'), creating a minor contradiction with 'Drops onto a new sheet'. No mention of prerequisites or auth needs.

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 detailed and front-loaded with the main action, but slightly verbose with full sentence examples. Could be trimmed without losing clarity, but overall efficient.

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 report generator, the description covers all report elements and notes one output per call. Output schema exists, so return values are covered. Lacks explicit prerequisites (e.g., must have simulation data), but sibling tools like run_simulation provide context.

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 baseline is 3. The description repeats some parameter info (e.g., output_name usage) but does not add significant new meaning beyond what the schema already provides.

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 clearly states the tool builds a single-sheet drivers report for sensitivity analysis, listing specific components (key findings, tornado chart, ranking table, etc.) and contrasts it with the broader executive dashboard, distinguishing it from siblings like build_executive_report.

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?

The description explicitly says 'Use this when the user asks for an uncertainty-drivers report rather than the broader executive dashboard,' directly guiding when to use this tool vs. the sibling build_executive_report.

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?

No annotations provided, so description carries full burden. Discloses idempotency ('re-running replaces the sheet') and describes output components in detail. Lacks mention of permissions or prerequisites but is otherwise transparent.

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?

Single paragraph is information-dense and front-loaded with purpose. Slightly dense but efficient; could be broken into bullet points for clarity.

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?

Given 8 parameters, 1 required, and output schema exists, description covers purpose, key behavior (idempotency), and report content. Could mention prerequisites (e.g., simulation must be run) but overall adequate.

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% (baseline 3). Description adds value by explaining what each component of the report includes (e.g., headline stats, tornado of top N drivers), which clarifies how parameters like primary_output and top_drivers affect the output.

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?

Description explicitly states it builds an executive report for a decision-maker, lists specific components (headline numbers, histogram, tornado, etc.), and distinguishes from siblings by contrasting with 'raw stats'.

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?

Provides a clear usage scenario: 'Use this when the user asks for a decision-maker-facing summary rather than raw stats.' Does not explicitly mention alternative tools like get_simulation_results, but the context is sufficient.

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 no annotations, the description fully discloses behavior: atomic and reversible pass, audit-logged safe-write path, change-set tracking, rollback on failure, default dry_run=True, and returns headline percentiles. This is comprehensive transparency.

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 three sentences, dense with information, but front-loaded with the main action. Each sentence adds value, though slightly verbose. It efficiently conveys key details without unnecessary fluff.

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?

Given the complexity (8 parameters, no annotations, output schema exists), the description covers purpose, usage guidelines, behavioral nuances, and parameter hints comprehensively. It leaves little ambiguity for an AI agent.

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 input schema covers 75% of parameters with descriptions, and the tool description adds context for inputs (Vose distribution families) and provides example structures. This enhances understanding beyond the schema alone.

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 clearly states the tool converts a deterministic workbook into a Monte Carlo model, using specific verbs like 'turn', 'wrap', 'replace', and 'run'. It distinguishes itself from siblings by emphasizing it's an end-to-end build that an advisory agent cannot perform.

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?

The description specifies the inputs needed (output cells and uncertain inputs) and the actions performed, implying when to use this tool. However, it does not explicitly state when not to use or mention alternative tools, though it contrasts with advisor limitations.

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?

No annotations provided, so description carries full burden. It discloses destructive default (unsaved changes discarded), return value (closed name and remaining open workbooks), and error condition (raises if not open).

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?

Two sentences: first states the action and key parameter, second details default, optional save, return, and error. Every sentence provides essential information without fluff.

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?

Given low complexity, complete schema coverage, and existence of output schema (return values described), the description fully covers all necessary information for an agent to use the 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?

Schema coverage is 100%, so baseline is 3. Description adds context: explains default for 'save' and consequence, and provides example for 'workbook_name' ('risk.xlsx'), enhancing understanding beyond schema types.

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?

Description clearly states the verb ('Close') and resource ('an open workbook by file name'). It specifies the default behavior regarding saving. No other tool in siblings has a close function, so it is well-distinguished.

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?

The description explains the default action (discard unsaved changes) and the optional save behavior, plus error condition. It does not explicitly compare to siblings, but the context is clear as there is no alternative close tool.

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 no annotations, the description discloses the tool's behavior: it computes differences and dominance under a specific convention (larger outcomes preferred). It also notes the prerequisite of a prior simulation. However, it doesn't mention potential errors or state mutations (though likely read-only).

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 a single paragraph of three sentences, covering purpose, metrics, and usage context. It is efficient but includes a bit of explanatory text on stochastic dominance that, while helpful, adds length.

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?

Given the complexity of comparing distributions, the description explains key statistical concepts and prerequisites. An output schema exists, so return values are documented elsewhere. It could mention default max_n behavior, but overall is sufficiently complete.

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 each parameter already has a description in the input schema. The description adds context about per-iteration samples but does not provide significant new meaning beyond the parameter descriptions.

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 clearly states the tool compares two simulation outputs head-to-head, specifying the exact metrics (mean/stdev/percentile differences, P(A>B), stochastic dominance). It distinguishes itself from sibling tools like get_simulation_results by focusing on comparative analysis and strategy selection.

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?

The description provides explicit context: 'Use it to decide between strategies' and 'Run a simulation that records both outputs first.' It explains the dominance concepts but does not explicitly exclude alternative tools or state when not to use it.

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 no annotations provided, the description fully discloses behavior: it is read-only, runs on a transient scratch sheet that is always deleted, and performs two operations (compute matrix and validate it). This gives the agent complete understanding of side effects.

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 two sentences, each earning its place: the first defines the core function, the second provides usage context and a behavioral note. No redundant or missing 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?

Given the tool's complexity (correlation matrix computation and validation), the description covers purpose, usage, parameter behavior, and side effects. The presence of an output schema ensures the return format is documented, making the description complete for invocation.

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?

All parameters are described in the schema (100% coverage). The description adds value by explaining the default for data_in_rows (columns) and giving an A1-style example for data_range. However, the meaning of the output (two matrices) is not detailed in the description, but since an output schema exists, the agent can infer it.

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 it computes a Spearman correlation matrix and its nearest valid form, explicitly naming the underlying functions (VoseCorrMatrix, VoseValidCorrmat) and linking it to the downstream tool create_copula. This clearly differentiates it from siblings like get_correlation_matrix or fit_copula_to_data.

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?

The description explicitly says 'Use this to turn historical data into the correlation matrix you feed to create_copula for correlated inputs,' providing clear when-to-use guidance. It also notes the data_in_rows option. However, it does not describe when not to use the tool or mention alternatives.

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 no annotations, the description fully handles transparency. It states the tool is exact and read-only, and that no simulation is run. It does not detail error handling or performance, but covers core behavioral traits.

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 a single paragraph that is relatively concise and front-loaded with the main purpose. It could be improved slightly by using bullet points for the metric list, but it is not verbose.

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?

Given 6 parameters with 100% schema coverage and an output schema mentioned, the description covers the two major usage modes and the key metrics. It lacks examples of parameter alignment but is sufficient for agent understanding.

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%, baseline 3. The description adds significant meaning by explaining the 'metric' options (pdf, cdf, etc.) and the conditional use of 'at', 'family', 'parameters', and 'object_cell'. This goes beyond the schema's parameter names and types.

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 clearly states it is an analytic distribution calculator for computing distribution properties without simulation. It lists specific metrics and the two input modes (family/parameters or object_cell), distinguishing it from simulation-based sibling 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?

Explicitly says to use for analytic computation without simulation, and that it is read-only and exact. It mentions alternatives by pointing at object_cell for fitted distributions, but does not directly contrast with simulation or fitting tools in sibling list.

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 no annotations, the description fully discloses that the tool builds an aggregate distribution, can write an Object form to avoid simulation, and requires frequency/severity distribution-object cells as prerequisites. It does not mention side effects or permissions, but the core behavior is transparent.

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 well-structured, starting with the main purpose, then explaining methods and options. While slightly verbose with technical details, every sentence adds value and is front-loaded with the core action.

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?

Given the tool's complexity (14 parameters, multiple methods, output schema present), the description covers methods, method-specific options, and the alternative sibling tool. It does not detail return format (handled by output schema) or error conditions, but overall sufficiently complete.

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 57%, and the description adds significant context by grouping parameters by method (e.g., density for FFT, intervals/max_p for Panjer, min_limit/max_limit/distribution_shift for MC) and explaining the purpose of as_object, clarifying meaning beyond the schema definitions.

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 clearly states the verb 'Build' and the resource 'frequency-severity aggregate', specifies the three methods (FFT, Panjer, MC), and explicitly differentiates from the sibling tool create_aggregate_mc by mentioning it as a dedicated shortcut for plain MC sampling.

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?

Provides explicit guidance on when to use FFT/Panjer vs MC, explains the benefit of as_object=True for analytic methods, and advises that for plain MC sampling the agent should use create_aggregate_mc instead, offering a clear alternative.

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 no annotations provided, the description bears full responsibility for behavioral disclosure. It does not mention that the tool writes a formula into a cell (target_cell), the effect of dry_run, or any side effects on the workbook, leaving significant gaps for the agent.

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 short and front-loads the core purpose, but it lacks structure and fails to cover essential details. While concise, it sacrifices completeness for brevity.

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?

Given 9 parameters with 0% schema coverage and a complex function, the description is severely incomplete. It does not explain how results are returned, the role of dry_run, or the purpose of limits and shift, leaving the agent underinformed.

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 must provide parameter context. It only explains frequency_object_cell and severity_object_cell, ignoring 7 other parameters like target_cell, dry_run, limits, and shift. Most parameters remain unexplained, making correct invocation difficult.

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 clearly states the tool builds a VoseAggregateMC formula for simulating aggregate losses, naming the specific function and the roles of n and distribution. However, it does not distinguish from the similar sibling tool 'create_aggregate', leaving potential confusion about when to use which.

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?

The description implies usage for simulation aggregate loss models but provides no guidance on when to choose this tool over alternatives like 'create_aggregate' or 'create_risk_event', nor does it mention prerequisites or limitations.

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 no annotations, the description fully discloses creation of a new sheet with binned data table and Excel line chart, replacement of existing sheets, and prerequisite of completed simulation. No contradictions.

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 essential: purpose, chart type/behavior, prerequisites/idempotency. No redundant or trivial content.

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?

Given moderate complexity and full schema coverage, the description covers all key aspects: output (sheet with data+chart), prerequisite, idempotency, and default naming. Output schema exists, so return values need not be detailed.

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%. Description adds value by explaining default sheet name pattern and Excel's 31-character truncation, going beyond the schema's bare definitions.

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?

Clearly states it renders a cumulative probability curve (CDF) of a simulation output as a new sheet, distinguishing it from sibling histogram or tornado chart 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?

Specifies that a completed simulation is required and that the tool is idempotent. Implicitly differentiates from histogram (PDF) by describing the CDF perspective; lacks explicit when-not or alternative comparisons.

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?

No annotations are provided, so the description carries the burden. It discloses that the tool writes a formula and is exempt from the bulk-write guard, implying a write operation. However, it does not clarify side effects, permissions, or reversibility, leaving gaps.

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 two sentences, front-loading the core purpose. It is concise, but the second sentence about the bulk-write guard could be integrated better. Still, every sentence adds value.

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?

Given the complexity (6 parameters, 5 required, no param descriptions) and the presence of an output schema, the description is too sparse. It does not explain the input-output relationship or how to construct the parameters array, making it insufficient for an agent to use 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?

Schema description coverage is 0%, and the description provides no explanation for any of the 6 parameters (e.g., what 'parameters' or 'u_array_target_range' mean). The tool name and a single example do not compensate for the lack of parameter documentation.

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 clearly states 'Build a copula formula' with a specific example (VoseCopulaMultiNormal) and its purpose (produce correlated u-array). It distinguishes itself from siblings like fit_copula_to_data by focusing on creation rather than fitting.

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?

The description mentions that copula tools are exempt from the bulk-write guard, providing a usage context. However, it does not explicitly guide when to use this tool versus alternatives (e.g., fit_copula_to_data) or any prerequisites.

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?

No annotations are present, so the description fully covers behavioral traits: it creates a new sheet with a binned data table and native Excel chart, includes specific features (frequency columns, cumulative curve, P10-P90 band), and is idempotent (replaces target sheet).

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, front-loaded with the main action, then detailed specifics. Every sentence is essential with no redundancy.

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 histogram creation tool with an output schema, the description covers prerequisites, idempotency, and the detailed chart structure. It is complete for an agent to decide when and how to invoke the tool.

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% with well-described parameters. The description repeats default values but does not add significant extra meaning beyond the schema, meeting the baseline expectation.

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?

Description clearly states the specific verb 'Render' and resource 'histogram of one output's simulation result distribution'. It distinguishes from sibling chart tools like create_tornado_chart and create_cdf_chart by detailing the histogram view and referencing ModelRisk's Results Viewer.

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?

Description explicitly requires a completed simulation and notes idempotency, providing clear context for when to use. It does not list alternatives but implies its specific purpose among sibling chart tools.

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?

No annotations provided. The description only notes that impact_function_name must be a distribution-object function. It does not disclose that the tool inserts a formula into target_cell, nor any side effects or authorization needs. The agent lacks behavioral context.

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 very concise, one sentence. However, it could be slightly more structured without losing content. It front-loads the main action.

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?

With 7 parameters, 0% schema description coverage, and no annotations, the description is insufficient. It does not explain impact_parameters, dry_run, or the role of target_cell. The agent would likely need to infer or have prior knowledge.

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%. The description mentions probability and impact_function_name but ignores other parameters (workbook, sheet, target_cell, impact_parameters, dry_run). Essential details for correct invocation are missing.

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 clearly states the tool's purpose: building a VoseRiskEvent formula with probability and impact_object. It is specific and distinguishes from sibling tools like create_aggregate or create_copula.

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?

No guidance on when to use this tool vs alternatives (e.g., create_aggregate). Does not mention prerequisites or context for selecting this tool beyond the function name constraint.

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 no annotations, the description must disclose behaviors. It reveals that the tool writes formulas and is exempt from the 50-cell guard, which is useful. But it doesn't mention overwrite behavior, permissions, or side effects. Adequate but not rich.

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?

Two concise sentences, no redundancy. First sentence states core action, second adds an important exception. Every word 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?

Given the complexity (6 parameters, nested array) and presence of an output schema, the description covers the main action and a key behavioral trait. However, it doesn't detail parameter structure or usage, leaving gaps for an agent.

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 only 17% (only target_range has a description). The description adds context for function_name (types of formulas) and target_range (write into), but leaves parameters (array of objects) and dry_run unexplained. Partially compensates but not fully.

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 clearly states the tool builds and writes a time-series formula, listing specific formula types (VoseTimeGBM, VoseTimeAR1). It distinguishes from siblings like write_formula and fit_time_series by specifying the exact function and use case.

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?

The description mentions exemption from the bulk-write guard, implying when to use this tool (for time series that naturally spill across many cells). However, it does not explicitly compare to alternatives or state when not to use it, missing a bit of 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?

Discloses idempotent replacement, sheet content (sorted data table + native Excel chart), default naming with truncation, and largest-magnitude input at top. No annotations provided, so description fully covers behavior.

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?

Five sentences, each with distinct value. Front-loaded with main purpose. Slightly long but no redundancy. Structure is clear and logical.

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?

Given tool complexity, covers purpose, behavior, output format, naming, and usage context. Output schema exists, so return values are covered. Sufficient for an agent to invoke 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?

Schema coverage is 100%, so baseline 3. Description adds context about sheet content and idempotency but doesn't significantly elaborate on parameter semantics beyond 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?

Clearly states the tool renders a tornado chart of input sensitivity as a new sheet, using specific verb 'Render' and resource 'tornado chart'. Differentiates from siblings by noting persistence vs. MCP return.

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 it's useful when the user wants visualization persisted, implying alternative (e.g., get_sensitivity_ranking) for MCP data. Could mention prerequisites like existing simulation results.

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?

No annotations are provided, so the description carries full burden. It discloses that the tool approximates a two-dimensional simulation via law of total variance and requires specific run configurations. It explains epistemic vs. aleatory uncertainty. It does not mention side effects, error conditions, or performance impacts, but for a read-like analytical tool, the disclosure is adequate.

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 a single paragraph that front-loads the main purpose in the first sentence. It explains the method, requirements, and outcome efficiently without redundancy. Slightly dense but no wasted words, earning a score of 4.

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?

The description covers the conceptual input requirements and the decision insight but does not mention the output format or any return value. Despite 'Has output schema: true', the description would benefit from a brief note on what the tool returns (e.g., variance components). Otherwise, the agent might be unclear on the result structure.

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%, but the description adds meaning by explaining the purpose of 'total_output' and 'conditional_output' beyond the schema's bare name. It clarifies that 'total_output' comes from a full run and 'conditional_output' from a frozen run. This extra context enhances parameter understanding.

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 clearly states the action 'Split an output's uncertainty into EPISTEMIC and ALEATORY' using 'law of total variance', with a specific verb and resource. It distinguishes this tool from siblings by its unique decomposition purpose, which is not duplicated by other listed 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?

The description provides clear context for when to use: requires two specific outputs from two runs (full run and frozen-epistemic run). It explains the approximating nature and the decision insight it provides (whether to collect more data or hedge variability). However, it does not explicitly state when not to use or list alternative tools, missing some explicit exclusion criteria.

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 no annotations, the description carries the full burden. It discloses a comprehensive list of returned data (Excel reachability, SDK activation, workbook info, counts, vmrs details, audit-log). It does not mention side effects, error conditions, or authentication requirements, but as a read-only health check, the disclosure is adequate.

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 exceptionally concise: two sentences with no wasted words. The first sentence states the primary purpose, and the second enumerates the returned items, ensuring front-loaded critical 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?

Given the tool's complexity (many sibling tools) and the presence of an output schema, the description is complete. It explains when to use it (first call vs. multiple tools) and what it returns, covering all essential context for an AI agent.

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 single parameter 'workbook_name' is fully described in the schema (100% coverage). The description adds no further meaning beyond repeating the schema's instruction to omit for the active workbook, so it meets the baseline but does not exceed it.

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 clearly states the tool's purpose as a 'one-call workbook health check' and lists the specific information returned. It distinguishes itself from sibling tools by explicitly offering a single call that replaces orchestrating 4-5 individual reading 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?

The description explicitly recommends using this tool as the first call and explains that it is an alternative to combining multiple reading tools, providing clear usage guidance and context.

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?

No annotations provided, so description carries the burden. It discloses ranking behavior based on reference count and magnitude, and identifies the output as a list of candidate cells. It does not describe side effects, destructive actions, or output structure beyond ranking, leaving some gaps.

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?

Two sentences, no fluff: first describes the tool's function and ranking methodology, second provides a clear usage suggestion. Every sentence 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?

There is an output schema (not shown), so return values are covered. The description explains the ranking criteria and suggests a pairing, but omits prerequisites (e.g., workbook must be open) and edge cases. Parameter semantics are absent, lowering completeness.

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%. The description mentions neither workbook_name nor limit, nor does it explain that limit controls the number of candidates. It adds no meaning beyond the schema titles, failing to compensate for the lack of parameter descriptions.

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 clearly states the tool discovers candidate input cells (numeric cells referenced by formulas) and ranks them by likelihood of being uncertain inputs, using reference count and number magnitude. It also distinguishes itself from the sibling propose_distributions_for_inputs by suggesting pairing, indicating a sequential relationship.

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?

The description explicitly advises to pair with propose_distributions_for_inputs, providing a usage sequence. However, it does not specify when not to use this tool or contrast it with alternatives like find_hard_coded_inputs, missing full exclusion 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool uses heuristic discovery and specifies the criteria (plain number referenced by at least one formula). However, it does not mention behavior aspects such as whether it is read-only, performance implications, or what happens if called multiple times. The description provides basic transparency but lacks depth.

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 a single, concise sentence that front-loads the key action ('Heuristic discovery'). It avoids unnecessary words and clearly conveys the purpose. While it is efficient, it could benefit from slight structuring (e.g., separate bullet for criteria) without increasing length.

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?

Given the tool's moderate complexity and the presence of an output schema (not shown but mentioned in context), the description adequately explains the purpose and criteria. However, it lacks information on the output format (likely cell references) and does not address prerequisites (e.g., workbook must be open). With no annotations, completeness is acceptable but could be improved.

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 schema has 0% description coverage for the single parameter 'workbook_name'. The description does not mention the parameter at all, leaving its semantics (e.g., how to specify the workbook) unexplained. With minimal schema coverage, the description should compensate by clarifying the parameter, but it fails to do so.

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 clearly states the tool's purpose: heuristic discovery of deterministic numeric inputs (plain numbers referenced by formulas) that are candidates for replacement. It uses specific language ('discovery', 'candidates for replacing') and distinguishes from sibling tools like 'discover_inputs' and 'propose_distributions_for_inputs' by focusing on hard-coded cells.

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?

The description implies usage context (preliminary step for replacing constants with distributions) but does not explicitly state when to use or not use this tool versus alternatives like 'propose_distributions_for_inputs' or 'discover_inputs'. No examples of appropriate scenarios are given.

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 no annotations, the description discloses key behaviors: dry run defaults to true, rollback on failure, reversible pass, and validation simulation. It does not cover all edge cases (e.g., permissions, idempotency) but provides solid context beyond the schema.

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 front-loaded with the main purpose and each subsequent sentence adds detail (process, defaults, rollback). It is relatively long but efficient, with no wasted words.

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?

Given the tool's complexity (12 parameters, output schema exists), the description covers the overall workflow, dry run behavior, rollback, and validation. It complements the output schema sufficiently, leaving no major gaps for agent understanding.

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 83%, and the description adds value by explaining the process flow (fitting marginals per column, fitting copula, wiring). This helps interpret parameters like 'columns', 'copula_anchor', and 'target_sheet' beyond their schema descriptions.

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 explicitly states the tool fits both marginals and copula dependence, then wires the model into the workbook. It uses specific verbs ('fit', 'wire') and resources ('marginal distributions', 'copula dependence'), clearly distinguishing from siblings like fit_copula_to_data or fit_and_rank_distributions.

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?

The description implies the tool is for complete model wiring ('data→model step') and mentions defaults and optional validation. However, it does not explicitly compare with siblings or state when to use this combined approach versus separate steps.

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 no annotations provided, the description fully carries the burden of behavioral transparency. It clearly states that the tool 'Runs on a transient scratch sheet that is always deleted; the data is not modified', revealing non-destructive behavior and temporary scratch usage. It also mentions that families unable to fit are reported under 'skipped' with reasons.

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 relatively concise at around 100 words, covering key aspects in a logical flow: what it does, how it ranks, when to use, and side effects. While well-structured, it could potentially be trimmed slightly without losing 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?

Given the complexity of fitting multiple distributions, ranking, handling skipped families, and the transient scratch sheet, the description addresses all these aspects adequately. An output schema exists, so return values are not needed in the description. The absence of any gaps makes it contextually complete.

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% with each parameter having a description in the input schema. The tool description adds minimal extra meaning beyond the schema, such as explaining that omitting 'families' uses a broad default set and the default criterion is 'SIC'. This does not significantly surpass the baseline of 3.

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 the tool fits several distribution families to a data range and ranks them by goodness of fit, specifying the exact verb-resource relationship. It distinguishes itself from the sibling tool 'fit_distribution_to_data' by saying 'Use this instead of guessing a single family', clearly differentiating its purpose.

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?

The description explicitly tells when to use this tool: 'Use this instead of guessing a single family for fit_distribution_to_data'. It also explains the ranking mechanism and that skipped families are returned with a reason. However, it does not explicitly state when not to use it or provide alternative tools for other scenarios.

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 no annotations provided, the description fully carries the burden. It discloses technical details: uses VoseFamilyFitObject, scores with AIC/SIC/HQIC, reports winner plus tail-dependence character (explaining 'lower = crash-together', etc.), and explicitly states it runs on a transient scratch sheet that is always deleted and that data is not modified. This is comprehensive.

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 slightly verbose but every sentence earns its place. It is front-loaded with the main purpose and ends with a pairing recommendation. Minor redundancy exists (e.g., 'the DEPENDENCE STRUCTURE fitted from data, not merely constructed' could be tighter), but overall it is well-structured.

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?

Given the complexity (7 params, output schema exists), the description covers the return value (winner plus tail-dependence character), mentions the transient scratch sheet, and references a sibling tool. It provides sufficient context for an AI agent to use the tool correctly without additional 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 coverage is 100%, so the description adds value beyond the schema by explaining the default family set (Normal, T, Clayton, Frank, Gumbel), the semantics of the criterion parameter, and clarifying that data_range is multi-column. It also explains the data_in_rows parameter meaning. This enriched context helps the AI agent understand parameter intent.

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 ('Fit parametric copulas to a multi-column data range and rank them by goodness of fit') and distinguishes the tool from siblings by emphasizing it fits dependence structure from data rather than merely constructing it. It also lists the families tried and scoring criteria, leaving no ambiguity about the tool's function.

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?

The description explicitly advises pairing with fit_all_data_and_wire to insert the fitted copula, providing clear when-to-use guidance. It also notes the transient scratch sheet and that data is not modified. However, it does not explicitly state when not to use this tool or list exclusion criteria, which would have pushed it to 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?

Despite no annotations, the description discloses key behavioral traits: the mapping of 'family' to Vose<Family>Fit, the inclusion of parameter uncertainty via 'uncertainty', and the distinction between sampling and object forms via 'as_object'. However, it does not mention side effects like overwriting cells or error handling, leaving some gaps.

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 three sentences long and front-loads the main purpose. It efficiently covers the key points but could be slightly more concise by reducing redundancy in the first sentence.

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?

Given the complexity (8 parameters, 5 required, extensive sibling list), the description provides core functionality but lacks details on error conditions, data range validation, and behavior of 'dry_run'. The presence of an output schema reduces the need to explain return values, but the description is still not fully complete for practical use.

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?

With only 25% schema description coverage, the description compensates for 'family' and 'uncertainty' semantics, but other parameters like 'sheet', 'target_cell', 'data_range', and 'dry_run' are not explained beyond their names and types. The description adds value for the core parameters but is insufficient for full guidance.

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 clearly states the tool fits a distribution family to a data range and writes the result, with explicit examples of families like 'Normal', 'Lognormal', etc. It distinguishes itself from sibling tools like 'fit_and_rank_distributions' and 'fit_tail' by focusing on a single family fit.

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?

The description lacks explicit guidance on when to use this tool vs alternatives. It explains the 'family' and 'uncertainty' parameters but does not clarify when to choose this over sibling tools like 'fit_and_rank_distributions' or 'fit_tail'. No prerequisites or exclusions are mentioned.

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?

Describes that it writes a Vose<Family>FitObject (with dry-run preview) and returns mean/high percentiles analytically. No annotations exist, so description carries full burden; lacks details on side effects, permissions, or limitations.

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 pack purpose, usage, parameters, and output. Front-loaded with action verb. Could be slightly more concise but each sentence adds value.

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?

Covers purpose, parameters, behavior, and output (mean, high percentiles). Output schema exists but description explains return values. Adequate for an agent to understand and invoke 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?

Adds meaning beyond schema by explaining 'data_range' as exceedances above threshold for GPD, and lists family options. Schema coverage is only 43%, so description compensates with context like 'dry_run previews' and 'uncertainty'.

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 clearly states it fits extreme-value tails (GPD, GEV, etc.) to data and returns risk metrics. It distinguishes itself from sibling tools like fit_distribution_to_data and get_tail_risk by specifying the output and follow-up actions.

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?

Indicates when to use: for fitting tails and obtaining risk percentiles. Mentions alternative tools (compute_distribution, get_tail_risk) for further analysis. However, does not explicitly state when not to use or compare to other fitting tools.

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?

No annotations are provided, so the description must disclose behavior. It states that the ranking does not modify the workbook and that writing the projection creates a CSE-entered ARRAY formula. It also notes the limitation on parameter uncertainty. This is clear and honest about side effects.

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 dense but efficient, front-loading the purpose and technical details without unnecessary words. It is well-structured with clear sections. A slight improvement could be breaking into paragraphs, but it remains concise.

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?

Given the complexity of the tool (multiple families, ranking, optional projection, array formulas) and the presence of an output schema, the description is thorough. It covers all essential aspects: ranking, writing projections, dry run, and unsupported features. No gaps remain.

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 input schema has 100% coverage, so the baseline is 3. The description adds value by explaining the default for 'families' (a broad 12-family set), the effect of 'target_range' and 'dry_run', and the criteria options. This enriches the schema beyond mere field names.

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 clearly states it fits time-series models to historical data and ranks them by goodness of fit. It lists specific model families (GBM, AR1, etc.) and distinguishes from distribution fitting siblings like 'fit_distribution_to_data' and 'fit_and_rank_distributions'.

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?

The description explains optional parameters like 'target_range' and 'dry_run', and notes when to use them. It also mentions that parameter uncertainty is not supported. However, it does not explicitly state when not to use this tool or provide alternatives for other tasks.

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?

No annotations are provided, so the description carries the full burden. It states the tool returns markdown and covers certain comparisons, but it does not explicitly confirm it is read-only, has no side effects, or requires any permissions. The description is functional but lacks behavioral guarantees.

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?

Two sentences, no wasted words. The first sentence states the action and audience, the second details the content and output format. Highly concise and front-loaded.

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?

With an output schema present, the description doesn't need to detail return values. It adequately covers what the summary includes. However, it could be slightly richer by mentioning the workbook must have run a simulation, but given the tool name, it's implied.

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 50% (workbook_name has no description, deterministic_values has a description). The tool description adds context by mentioning 'most recent simulation results for a workbook' for workbook_name, but does not elaborate further. It provides no new meaning beyond the schema for deterministic_values, so baseline 3 is appropriate.

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 clearly states the tool generates an executive-audience summary for the most recent simulation results, with specific content like deterministic vs P50 comparisons, P80 contingency, and top sensitivity drivers. This distinguishes it from sibling tools like get_simulation_results or build_executive_report.

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?

The description explicitly says the markdown output is 'ready to paste into a deck/report', indicating when to use it (for presentation-ready summaries). However, it does not mention when not to use it or suggest alternative tools for raw data or detailed analysis.

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?

The description implies a read-only operation without side effects, which is clear for a getter. However, it does not explicitly state safety or nondestructive behavior. Given no annotations, the description carries the burden and does so adequately.

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 a single, efficient sentence with no unnecessary words. It is front-loaded with the tool's primary action and result.

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?

Given the tool's simplicity (0 params, output schema exists), the description fully covers the necessary information. It is complete for an agent to understand and invoke the 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 input schema is empty (0 parameters), so schema coverage is 100%. The description adds value by specifying what is returned (name and path), which goes beyond the schema. Baseline 4 is appropriate.

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 clearly states the verb 'Get' and the resource 'name and path of the active workbook'. It uniquely identifies the tool's purpose among siblings like list_open_workbooks and open_workbook.

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?

The description does not explicitly state when to use this tool versus alternatives, such as when needing the active workbook's identity. Usage is implied but lacks exclusions or context.

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?

No annotations provided, so description carries full burden. It only states what is read but does not disclose side effects, permissions, or other behavioral traits.

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?

A single sentence that is concise and front-loaded with purpose; no wasted words, though slightly minimal.

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?

Adequately describes the tool's input and output for a simple read operation, with output schema covering return details. No mention of prerequisites like workbook being open.

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 33% (only 'cell' described). The description adds no extra meaning to parameters, failing to compensate for the missing schema descriptions.

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 clearly states the verb 'Read' and the specific resource 'a single cell's formula, value, and number format', distinguishing it from siblings like 'read_range'.

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?

No explicit guidance on when to use this tool versus alternatives, but the name and description imply it's for individual cell reads, and siblings provide context.

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?

No annotations are present, so the description carries full burden. It discloses the data source (per-iteration samples from ModelRisk) and that both Pearson and Spearman methods are computed. However, it does not explicitly state side effects, read-only nature, or permissions required, which are important for a read operation.

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 consists of two concise sentences with no extraneous words. The first sentence states the core functionality, and the second provides optional usage guidance. Ideal length and structure.

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?

Given the presence of an output schema, return values need not be explained. The description provides context about ModelRisk simulation and the optional name list. It is complete enough for an agent to understand the tool's purpose and usage, though it lacks details about the output format (e.g., matrix structure), which is covered by 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 description coverage is 0%, so the description must compensate. The description explains that the 'name_list' parameter restricts variables, adding meaning beyond the schema's type definition. The required 'workbook_name' is not explained but is contextually obvious.

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 clearly states the tool computes Pearson and Spearman rank correlation between simulation inputs and outputs, citing the source (per-iteration samples from ModelRisk). The verb 'compute' and resource 'correlation matrix' are specific, and it distinguishes from siblings by naming both correlation types.

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?

The description provides guidance on restricting variables via a name list, implying default inclusion of all variables. However, it does not explicitly state when to use this tool versus its sibling 'compute_correlation_matrix' or other correlation tools, nor does it mention when not to use it.

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 no annotations, the description carries full burden. It discloses the default cap at 10,000 samples, the ability to raise max_n, and the resulting response size, providing transparency about performance and limits.

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 that are front-loaded: purpose, use cases, and parameter behavior. Every sentence adds value without redundancy or fluff.

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?

Given the tool's simplicity and the presence of an output schema, the description covers what the tool returns, when to use it, and key parameters. It is complete for a getter tool.

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%, but description adds practical guidance on max_n: default value, cap, and expected response size. This goes beyond schema descriptions, helping the agent choose appropriate values.

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 explicitly states 'Return raw per-iteration sample values for a single output or input', providing a specific verb and resource. It distinguishes the tool from siblings like get_simulation_results by focusing on raw samples.

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?

The description indicates usage for 'custom histograms, arbitrary percentiles, downstream analysis' and mentions adjusting max_n for larger datasets. It gives clear context but does not explicitly exclude alternative tools.

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?

No annotations provided, so description carries full burden. Discloses read-like behavior (returns statistics) but omits side effects, permissions, or performance. Adequate but not detailed.

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?

Single sentence, front-loaded with key information. No wasted words, but could be better structured with separate sentences for purpose and output.

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?

Describes return values but lacks context on prerequisites (e.g., workbook must be open) and how output relates to other tools. Adequate for a simple tool but could be more complete.

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%, and description adds no explanation for parameters (workbook_name, output_name). Relies entirely on parameter names, which is insufficient.

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?

Clearly states the tool computes sensitivity ranking (Tornado) for a single output, specifying it returns Spearman rank correlation and standardised regression coefficient. Distinguishes from siblings like get_simulation_results.

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?

Implies use for single output sensitivity analysis, but no explicit guidance on when to use vs. alternatives or prerequisites. Lacks when-not-to-use context.

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?

No annotations are provided, so the description carries full burden. It discloses that it is a read operation, lists return values, and states a prerequisite. It does not cover error conditions or behavior when simulation has not been run.

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?

Two sentences, front-loaded with purpose and return values, then prerequisite and filter option. No unnecessary words.

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?

Given the presence of an output schema, the description covers the key points: what it does, what it returns (list of statistics), prerequisite, and filtering. Minor gap: no mention of behavior if simulation not run or if no outputs match.

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 must add meaning. It explains 'output_names' as a filter but does not detail its format or the role of 'workbook_name'. Partial compensation for one 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 clearly states it reads simulation result statistics, listing specific metrics (mean, stdev, etc.), and distinguishes from siblings like 'get_samples' or 'get_tail_risk' by focusing on summary statistics per output.

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 provides clear context: requires a simulation to have been run and allows filtering by output_names. However, it does not explicitly contrast with sibling tools like 'get_tail_risk' for when to use alternatives.

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 no annotations, description covers reading from .vmrs, tail direction interpretation, metric definitions, defaults, and optional thresholds, but lacks details on errors or performance.

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?

Packed with information but efficient; slightly long but every sentence adds value, and core purpose is front-loaded.

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?

With output schema present and full parameter descriptions, the description covers prerequisites, metric definitions, and behavior, making it sufficiently complete for an agent.

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% (baseline 3), and description adds context: tail examples (cost vs. NPV), explanation of VaR/CVaR, and default alphas, enhancing understanding beyond 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?

Description clearly states the tool computes tail-risk metrics (VaR, CVaR, threshold probabilities) from simulation output samples, distinguishing from siblings like get_samples or compute_distribution.

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?

Implies usage after running a simulation ('run a simulation first'), but does not explicitly compare to alternatives or state when not to use.

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?

No annotations are provided, so the description carries full burden. While the tool name and context imply it is a read-only summary operation, the description does not explicitly state it is non-destructive or safe to use. Adding a note about no side effects would improve transparency.

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?

Two sentences, front-loaded with the tool's purpose and key details. No extraneous information. Every word 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?

Given the single parameter and presence of an output schema, the description is mostly complete. It could benefit from mentioning that the workbook must be open, but this is implied by the sibling tools. Overall, adequate for the tool's simplicity.

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% for the single parameter 'workbook_name'. The description does not add semantic meaning beyond what the schema already provides, meeting the baseline for full coverage.

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 clearly states the tool returns an aggregated summary of a workbook including sheet names and counts of specific cell types. It distinguishes from sibling tools by calling itself a 'one-shot alternative' to individual list 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?

Explicitly says 'One-shot alternative to running the individual list tools', providing clear context on when to use this tool instead of listing each type separately. This directly addresses usage guidance against siblings.

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 no annotations, the description carries full burden. It discloses dry_run default and validation, but does not mention side effects like overwriting cells, permissions, or error handling. Moderate transparency.

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?

Two concise, front-loaded sentences with no wasted words. Every sentence adds distinct value: core action and behavioral 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?

Despite 6 parameters and many siblings, the description omits prerequisites (e.g., workbook must be open), return value format, and how parameters map to Vose formula syntax. Low completeness for the tool's complexity.

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 17%, yet the tool description adds minimal parameter context beyond a function name example. The 'parameters' array and other fields remain unexplained, forcing the agent to guess or rely on external knowledge.

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 clearly states the tool writes a Vose distribution formula into a cell, specifies the function name validation against the ModelRisk catalogue, and distinguishes itself from siblings that perform computations, fitting, or other actions.

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?

The description implies usage for inserting distribution formulas but provides no explicit guidance on when to use vs. alternatives like 'compute_distribution' or 'write_formula'. The dry_run note is behavioral, not usage context.

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 no annotations, the description partially discloses behavior: it lists cells and includes flags for VoseInput/VoseOutput. However, it does not mention performance implications, required permissions, or side effects, leaving gaps in transparency for a potentially large list operation.

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?

Two tightly written sentences. The first sentence states the core purpose; the second adds the optional filter. No wasted words, and the key information is front-loaded.

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?

Given the simple parameter set (2 params, 1 required) and the presence of an output schema, the description adequately covers what an agent needs to know. It specifies the scope and optionality, making it complete for this tool's complexity.

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 explains the 'sheet' parameter ('restricts the scan to one sheet'), adding meaning beyond the schema. However, it does not describe the required 'workbook_name' parameter, and schema coverage is 0%, so the description only partially compensates.

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 clearly specifies the action: 'list every cell containing a Vose distribution / aggregate / copula / time-series / fitting function'. It names the resource (cells with specific functions) and distinguishes from siblings like list_modelrisk_inputs/outputs which focus on specific wrapped cells.

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?

The description states the purpose but does not explicitly say when to use this tool versus alternatives (e.g., list_modelrisk_inputs). It mentions an optional sheet filter, which provides some context, but lacks guidance on exclusions or prerequisites.

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?

No annotations; description is the sole source. It states the tool returns specified info but omits side effects, authorization, or performance implications. Basic transparency but not thorough.

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?

Single sentence with key action upfront and return details. Efficient but could benefit from structured bullet points for readability.

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?

Given a single parameter and output schema likely defined elsewhere, the description covers the core functionality. Lacks edge cases (e.g., empty result) but is sufficient for typical use.

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%, yet the description adds no additional context for the workbook_name parameter (e.g., format, validity constraints). Fails to compensate for missing schema descriptions.

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?

Description clearly states it lists cells wrapped with VoseInput() and enumerates returned fields (reference, name, formula, value). This distinguishes it from siblings like list_modelrisk_outputs.

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?

Description implies usage (to find VoseInput cells) but provides no guidance on when to choose this tool over alternatives like discover_inputs or list_modelrisk_outputs.

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?

No annotations exist, so the description must disclose behaviors. It states the operation is listing cells, implying a read-only action, but does not confirm idempotency, performance expectations, or whether the workbook must be open.

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 a single, focused sentence with no extraneous information. It efficiently conveys the tool's purpose.

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?

Given the simple operation (1 param, output schema exists), the description is mostly complete. It lacks only minor context like required workbook state, but the output schema presumably covers return structure.

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%, and the description does not elaborate on the meaning of 'workbook_name'. It does not specify how to obtain or format the workbook name, leaving ambiguity despite the schema showing it's a required string.

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 clearly uses a specific verb 'List' and resource 'every cell wrapped with VoseOutput()'. It distinguishes from the sibling tool 'list_modelrisk_inputs', which targets VoseInput() cells.

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?

No guidance is provided on when to use this tool versus alternatives. With many sibling tools offering similar list operations, explicit usage context like 'use this to enumerate output cells before analysis' would help.

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?

The description discloses the basic behavior (listing open workbooks) but does not clarify whether it lists all Excel workbooks or only ModelRisk-related ones. With no annotations, more context would be beneficial.

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?

Single sentence that is concise and to the point, with no unnecessary words.

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?

With no parameters and an output schema present, the description is sufficient for a simple list tool. Could add scope clarification, but not necessary.

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?

No parameters exist, so schema coverage is 100%. The description adds no parameter info, but baseline for 0 parameters is 4.

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 uses a specific verb ('List') and resource ('all Excel workbooks currently open'), clearly distinguishing it from siblings like 'get_active_workbook' or 'get_workbook_summary'.

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?

No explicit guidance on when to use this tool vs alternatives, but the purpose implies it is for getting a list of open workbooks. Does not mention when not to use it.

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?

No annotations are provided, so the description carries the full burden. It clearly describes the listing behavior and the output format (name, kind, var_id, iterations), but does not disclose any limitations or edge cases. For a simple read operation, this is largely adequate.

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?

Two concise sentences with no superfluous information. The first states the core function, the second gives usage context.

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?

Given the simple parameter, the existence of an output schema (which the description previews), and clear positioning among many siblings, the description covers all necessary information for proper tool selection and invocation.

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% for the single optional parameter. The description does not add further semantics beyond what the schema already provides, meeting the baseline.

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 uses a specific verb ('list') and resource ('.vmrs variables declared as VoseInput or VoseOutput'), clearly distinguishing its purpose from siblings like get_samples or read_vmrs. It explicitly states the condition and output structure.

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?

The description explicitly says when to use this tool ('before get_samples or read_vmrs when you don't already know which outputs / inputs exist in the file'), providing clear context and direction.

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 no annotations, the description bears full responsibility. It discloses the 'no duplicate' behavior and the prerequisite of Excel running. It does not mention side effects or error handling, but for a simple open operation these are adequately 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 description is two sentences: first states the core purpose, second adds behavioral details. No redundant information; efficiently front-loaded.

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?

Given the tool's simplicity (one parameter, no nested objects), and presence of output schema, the description covers prerequisites, duplicate handling, and file types. It is complete for its complexity.

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% for the only parameter 'path'. The description reiterates the absolute path requirement without adding semantic value beyond the schema's example. Baseline is appropriate.

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 clearly states the tool opens a workbook (.xlsx/.xlsm) from disk for use by other ModelRisk tools. It specifies the verb ('Open'), resource ('workbook'), and distinguishes from siblings by noting it is the gateway for subsequent actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.