ModelRisk MCP

Official

by vosesoftware

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.0
Disambiguation3/5
Many tools have overlapping domain concepts (e.g., multiple fitting tools, multiple reading tools, multiple reporting tools). While descriptions are detailed, the sheer number and similar verbs (list_, get_, compute_) force an agent to carefully parse each description, risking misselection particularly between read_range vs get_cell vs get_samples.
Naming Consistency4/5
All tool names use consistent snake_case with a verb_noun pattern (e.g., list_modelrisk_inputs, fit_distribution_to_data). A few longer names (fit_all_data_and_wire, generate_executive_summary) break the pattern slightly but remain clear. Overall, the naming is predictable and readable.
Tool Count2/5
59 tools is very high for a single MCP server. Many tools are highly specific (decompose_uncertainty, backtest_output) that could be combined or offered as optional. This large surface increases agent complexity and decision latency, suggesting the tool count should be pruned or better organized into subcategories.
Completeness4/5
The tool set covers the full risk modeling workflow: workbook management, input discovery, distribution fitting, simulation, sensitivity analysis, reporting, and auditing. Minor gaps exist (e.g., no tool to edit an existing distribution formula directly), but the core lifecycle is well-supported, and restore_cell provides a safety net.
Average 4/5 across 51 of 59 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 36 commits in the last 12 weeks
- Last stable release on August 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the tool wraps a cell with VoseInput("name")+ and shows it in the input list, but does not disclose if the original cell formula is modified, whether the operation is reversible, or what happens if the cell already has a VoseInput wrapper.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and includes the product prefix 'ModelRisk'. Every word serves a purpose, though it could optionally mention parameter behavior without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no schema descriptions, no annotations, and many sibling tools, the description is insufficient. It does not explain that the cell must contain a distribution, how 'name' is used, or what the output schema contains. The return value is not explained, but since an output schema exists, that is less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should explain parameters. It mentions 'name' implicitly in VoseInput("name") but offers no details about 'cell', 'sheet', 'dry_run', or 'workbook'. The title fields in the schema are minimal (e.g., 'Cell'), so the description adds almost no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('wrap') and resource ('existing distribution cell') and explains the result ('appears in the input list and the Results Viewer'). However, it does not distinguish from sibling tools like 'wrap_with_output', missing a clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., 'wrap_with_output' or 'insert_distribution'). There is no mention of prerequisites, typical scenarios, or 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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It says it wraps a cell with VoseOutput, implying modification, but doesn't mention side effects, required state (e.g., workbook open, cell must contain an existing output?), or the effect of dry_run. Very sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. However, it is too brief for a tool with 5 parameters and no annotations; could benefit from a second sentence summarizing parameter roles or usage flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing prerequisites (e.g., workbook state, cell content requirements) and integration hints with sibling tools. Output schema exists, so return values are covered, but setup and post-conditions are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description only indirectly references 'name' and assumes cell/sheet/workbook context. Does not explain the 'dry_run' parameter (with default true), which is critical for execution. Many parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a specific verb ('wrap') and resource ('existing output cell'), and clearly states the outcome: it makes the cell appear in the output list and Results Viewer. Differentiates from the sibling wrap_with_input by targeting outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., other output-related tools like list_modelrisk_outputs or get_cell). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool overwrites a non-Vose cell and does so by design, which is a key behavioral trait. However, it does not mention whether the operation is reversible, what permissions are required, or what happens to the original value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding value: first states the action, second gives usage context, third stresses uniqueness. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 required parameters and an output schema, the description lacks essential details about parameter semantics and expected values. It provides high-level purpose but insufficient guidance for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its 7 parameters, yet the description provides no information about any parameter (cell, sheet, workbook, function_name, parameters, input_name, dry_run). This is a critical gap for an agent to use the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replaces a hard-coded number with a Vose distribution wrapped by VoseInput. It specifies the context (ModelRisk) and differentiates from siblings by noting it is the only tool that overwrites a non-Vose cell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to use after find_hard_coded_inputs identifies candidates, establishing a clear workflow. It implies when not to use (not for cells already containing distributions) but does not explicitly list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses reading from a specific file and rewriting the oldest before-formula. It does not mention side effects or error conditions, but the core behavior is clear without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Purpose and key detail (log file location, parameter hint) are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema shown and description omits return value or error handling. For a mutation tool with no annotations, more context about outcomes and prerequisites is needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 25% schema description coverage, the description should add meaning for the required parameters (workbook, sheet, cell) but only discusses 'since'. The schema description for 'since' already covers its purpose, so the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Restore a cell to its pre-write state from the audit log' with a specific verb and resource, and references ModelRisk context. It is clear and distinguishes from sibling tools like restore_deterministic_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like restore_deterministic_state. The description only explains the 'since' parameter but lacks explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Mentions overwrite behavior and A1-style constraint, but does not disclose side effects, permissions, or that dry_run parameter exists (noted in schema but not described).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey purpose and one key constraint without extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Significant gaps: no mention of dry_run purpose, return values (output schema exists), or how this tool fits with siblings like write_formula or read_range.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description only adds that range_ref must be A1-style. Does not explain workbook, name, or dry_run parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (create/overwrite) and resource (workbook-level named range). Distinguishes from sibling tools by specifying it's for named ranges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes usefulness for giving cells identities for later reference, indicating when to use. No explicit exclusions or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the return format (2D array of values and formulas) but does not mention error handling, edge cases, or permissions. For a read-only tool, this is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that immediately convey the tool's purpose and a usage example. Every sentence is necessary and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 and the tool's simplicity as a read operation, the description is fairly complete. However, it could provide more context about multi-sheet references or error cases, especially with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%; only 'range_ref' has a description in the schema. The tool description reinforces the range syntax but does not clarify 'sheet' or 'workbook_name'. It adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a contiguous range as a 2D array of values and formulas', identifying the specific verb (read), resource (contiguous range), and output format (2D array). This distinguishes it from siblings like 'get_cell' which reads a single cell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example of range syntax ('A1:C10') but does not explicitly state when to use this tool versus alternatives like 'get_cell' or list tools. No guidance on 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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the original cell formula is captured and restored after the sweep (even on error), leaving the workbook in its pre-call state. It also notes each scenario takes roughly the same time as run_simulation. Missing details on potential side effects or blocking behavior, but the recovery disclosure is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about 4 sentences, efficiently conveying the core function and key behavioral points. It is front-loaded with the main action and purpose. While not structured with bullets, it is clear and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (scenario sweeping, cell restoration) and the presence of an output schema, the description covers the main behavioral aspects: what it does, time cost, recovery guarantee. It does not explain whether results are returned synchronously or how errors beyond restoration are handled, but it is largely complete for an agent to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 6 parameters. The description adds a small guideline (3-7 scenarios) but does not significantly expand on parameter meaning, format, or constraints beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: sweeping a single input cell across multiple deterministic values, running simulations, and returning per-output statistics. It distinguishes itself from sibling run_simulation by explicitly describing the scenario-sweep nature and gives a concrete what-if example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage context: useful for what-if analysis and suggests keeping the values list short (3-7 scenarios) due to time cost per scenario. It implies not for single simulations, but does not explicitly compare to alternatives like run_simulation or propose_distributions_for_inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes the wrapper nature and filtering but doesn't disclose error handling, permissions, or potential side effects (though likely read-only). Adequate but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with purpose, then usage details. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return values are covered. Description explains wrapper behavior, filtering, and condition for enumeration. Could mention file existence handling, but overall sufficient given output schema presence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (path has description, output_names does not). Description adds meaning for output_names ('filter; leave empty to attempt enumeration') and clarifies path expectation. Compensates well for incomplete schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it reads simulation results from .vmrs files (specific verb and resource). Immediately distinguishes itself as a convenience wrapper for set_active_vmrs + get_simulation_results, setting it apart from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes it doesn't need an open workbook, contrasting with alternatives like get_simulation_results. Also explains output_names filtering behavior and what happens when left empty. Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the behavior: partitioning iterations into breach/no-breach, reporting mean shifts and tail concentrations, and producing a tornado and mean input vector. It does not mention side effects, but given the read-only nature, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely packed with information and front-loaded with the key action. It is slightly verbose but every sentence adds value. It could be trimmed slightly, but generally well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool, the description covers inputs (threshold, percentile, direction, etc.) and outputs (tornado and mean input vector). It also explains the statistical approach and prerequisites. An output schema exists, so explanation of return values is not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal extra meaning beyond the schema. The description explains the overall partition logic but not details of individual parameters beyond what is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Reverse stress test — start from a BAD output outcome and work back to the joint input state that produces it.' It expands on the method and distinguishes it from sibling tools by mentioning the specific Solvency II / PRA requirement and the need for a completed simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite: 'requires a completed simulation.' This provides clear context for when to use the tool. However, it does not mention when not to use it or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 setting a path overrides the default file location and that subsequent calls will use it. However, it does not mention potential side effects like invalidation of cached results or scope of the setting. This is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no wasted words. The first sentence states the purpose, and the second provides concrete usage details. It is highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema shown (though context indicates output schema exists), the description is sufficiently complete for an agent to invoke it correctly. It explains the effect, the required input format, and the clearing mechanism. It could mention the return value, but it's a setter so likely not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'path', with a description stating it should be an absolute path or empty string. The tool description adds value by explaining the purpose of the empty string and the requirement for an absolute path, going beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Pin a specific .vmrs file as the source of simulation results.' It uses a specific verb ('Pin') and resource ('.vmrs file'), and distinguishes from sibling tools like get_simulation_results by specifying that it sets the file that those tools will read from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Pass the absolute path of the file' and explains the effect on subsequent calls to related tools. It also specifies how to clear the override with an empty string. While it doesn't explicitly state when not to use it, the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to pass an absolute file path and notes the behavior when a duplicate is open (returns existing). It does not explicitly list when not to use or compare to alternatives, but the context of being a prerequisite for other tools is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool triggers a full Excel recalculation (Application.CalculateFull), which is a heavy operation. It explains the behavioral effect (restores deterministic values). No mention of side effects or permissions, but given the recovery context, it's reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but packs problem statement, action, mechanism, and usage guidance into a tight, front-loaded structure. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's recovery purpose and the presence of an output schema (context signal indicates it exists), the description is complete: it explains what triggers the condition, what the tool does, how it works, and when to use it. No gaps for the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one optional parameter (workbook_name) with a schema description covering 100% of parameters. The tool description does not add meaningful extra semantics beyond the schema's 'Workbook to recalculate. Omit for the active workbook.' Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: recover a workbook from a 'frozen sample' state where VoseOutput cells show per-iteration values instead of deterministic baselines. It distinguishes itself from siblings like run_simulation (which triggers simulation) and list_modelrisk_outputs (which reads outputs) by specifying the exact problem scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: after `run_simulation` raises a post-condition error, or when `list_modelrisk_outputs` shows nonsense current values. It also explains the mechanism (full Excel recalculation). No explicit when-not-to-use, but the conditions are well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the read-only nature and what the tool reports (declared outputs, hard-coded cells, checklist). While no annotations are present, the description covers key behavioral traits. It does not mention error conditions or response format, but the output schema handles the latter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus an imperative instruction. It front-loads the core function and avoids fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no annotations and only one parameter, the description covers the tool's purpose, outputs, and usage timing. It does not full describe the return structure (output schema exists), but for a planning tool, it provides sufficient context for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'workbook_name' is self-explanatory, but the description does not explicitly clarify its role. With 0% schema description coverage, the description should compensate, but the parameter is simple enough that missing detail is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it plans a Monte Carlo risk model from a deterministic workbook. It distinguishes itself from siblings by positioning itself as a 'one-call blueprint' to run first, contrasting with more specific action tools like insert_distribution or run_simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Run this first when asked to add uncertainty or make this a risk model.' It also notes that it's read-only, providing clear context for when to use this tool versus other more granular tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: overwrite protection (refusal unless allow_overwrite=True), dry_run default, and audit logging. Missing details like permissions or rate limits, but still strong for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly long but well-structured and focused, front-loading the core purpose and then adding essential behavioral details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown) and the tool's complexity, the description covers writing behavior, safety, dry run, and audit logging, making it sufficiently complete 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers only 50% of parameters with descriptions, but the description adds meaningful context: explains that '=' is optional in formula, the purpose of allow_overwrite, and dry_run behavior. This compensates for missing schema descriptions on workbook and sheet.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a formula or value into a single cell, provides examples, and distinguishes itself from Vose-specific tools, making its unique purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool (for arbitrary formulas not covered by Vose tools) and explains safety defaults (dry_run, overwrite protection), but does not explicitly name sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses: blocks until completion, matches UI behavior, uses fixed seed, saves to specific locations with fallback, and auto-pins result for next step. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is moderately sized but every sentence adds value. Could be slightly more compact, but information density is high and well-structured with the main purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects given complexity: purpose, behavior, defaults, output file, next step, and parameter nuances. Output schema exists, so return value disclosure is not needed. Highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context beyond parameter descriptions: explains default for samples (1000), alias between samples and iterations, precedence rule, and save_to fallback for OneDrive. This aids correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Run a Monte Carlo simulation on the active (or named) workbook and save the results to a .vmrs file.' It specifies both the action and the resource, and distinguishes from sibling tools 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes default behavior (1000 iterations, fixed seed), file location, and explicitly says to call get_simulation_results afterward. However, it does not explicitly mention when not to use this tool or compare to alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: it refuses to overwrite unless overwrite=True, it returns the resolved absolute path, and it does not implicitly call Workbook.Save(). These details are critical for the agent to understand the tool's side effects and safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only three sentences. It starts with the core purpose, then clarifies the distinction from Ctrl+S, provides usage guidance, and details overwrite behavior and return value. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a save operation with an output schema, the description covers all essential aspects: target path, overwrite condition, and return value. It does not need to explain return values if the output schema does that. The description is complete for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers only 33% of parameters with descriptions (only 'path' has a description). The description adds significant value for 'overwrite' (explaining default false and refusal behavior) and reinforces 'path' constraints (must end with .xlsx, .xlsm, .xlsb, or .xls). However, the 'workbook' parameter lacks additional semantics beyond the name, but overall the description compensates well for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Save the workbook to a specific path on disk.' It distinguishes itself from the user's Ctrl+S by noting that the MCP server never calls Workbook.Save() implicitly. The verb 'save' and resource 'workbook' are specific, and the description effectively differentiates from potential sibling tools like open_workbook or close_workbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use this tool: 'Use only when the caller explicitly named a target file.' It also notes the overwrite behavior: 'Refuses to overwrite an existing file unless overwrite=True.' This provides clear context, though it does not explicitly mention alternatives among siblings. The guidance is still strong and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses that the tool does not write to Excel and only returns suggestions, giving the agent a clear behavioral model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff, front-loaded with the action and key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and output format, but does not mention prerequisites like a workbook being open; however, given sibling tools like discover_inputs, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds context (each input gets a ranked list) beyond the schema's documentation of the inputs array, though the meaning is largely captured by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it proposes distribution families for a list of uncertain inputs, and distinguishes from sibling tools like replace_constant_with_distribution by noting it does not write to Excel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool returns suggestions for the LLM to discuss with the user before committing via replace_constant_with_distribution, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![modelrisk-mcp MCP server](https://glama.ai/mcp/servers/vosesoftware/modelrisk-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vosesoftware/modelrisk-mcp)

Score Badge

Copy to your README.md:

[![modelrisk-mcp MCP server](https://glama.ai/mcp/servers/vosesoftware/modelrisk-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vosesoftware/modelrisk-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vosesoftware/modelrisk-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server