Server Quality Checklist

Tool Scores

• calc_depreciationD
  1.3/5.0
  Behavior1/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 of behavioral disclosure. It fails to mention whether the computation is read-only, what method values are accepted, or what the output schedule looks like. The description is entirely non-transparent about tool behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely under-specified, consisting of only 'COMPUTE. Depreciation schedule.' This is not conciseness but rather an absence of content, providing no useful structure or front-loaded information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has five parameters, no annotations, and no output schema, a description of this length is grossly inadequate. It fails to provide the necessary context for an agent to invoke the tool correctly or interpret results.

  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 does not mention or elaborate on any of the five parameters (cost, method, salvage_value, useful_life_years, currency). The agent receives no semantic help beyond the raw schema property names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'COMPUTE. Depreciation schedule.' is essentially a restatement of the tool name 'calc_depreciation', providing no additional specificity such as supported depreciation methods or output format. It fails to distinguish the tool from sibling calc_* tools beyond naming the resource.

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

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance whatsoever on when to use this tool versus alternatives like calc_npv, calc_irr, or other financial calculation tools. The description is silent on context, prerequisites, or exclusions.

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

• calc_compound_growthD
  1.5/5.0
  Behavior1/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does not describe what inputs are required, how the calculation works, what outputs are returned, or any edge cases. The tool's behavior remains essentially unknown.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely short, which is good for conciseness, but it is a fragmented phrase rather than a well-structured sentence. It lacks a clear subject-verb-object framing and does not earn its place by providing meaningful information beyond the tool name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (9 parameters, no annotations, no output schema), the description is woefully incomplete. It does not explain the tool's purpose, input requirements, output format, or any operational context. An agent would not be able to use this tool correctly based on this description alone.

  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 compensate. The list 'future_value | present_value | cagr' hints at possible values for the 'operation' parameter, providing minimal semantic information. However, it does not explain the meaning or roles of the other eight parameters, leaving all parameter semantics largely undefined.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'COMPUTE. future_value | present_value | cagr' is a terse fragment that lists possible operations but fails to clearly state that this tool calculates compound growth metrics. It provides minimal clarification of the tool's purpose and does not distinguish it from sibling calculation tools like calc_metric or calc_npv.

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

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions. The description offers no context for an agent to decide between calc_compound_growth and other similar tools.

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

• calc_npvC
  2.1/5.0
  Behavior1/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only says 'COMPUTE. Net Present Value.' and provides no details on how the calculation behaves, such as assumptions about cash flow timing, rate interpretation, or whether it is a read-only operation. This is completely inadequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely short ('COMPUTE. Net Present Value.'), but this is under-specification rather than good conciseness. It omits essential context about parameters and usage, making it insufficiently informative despite being front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 3 parameters, no output schema, and no annotations, yet the description provides no details about return values, parameter formats, or typical usage. It is completely incomplete for a tool with these characteristics.

  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%, so the description must explain the parameters. It does not explain that 'rate' is a discount rate, the expected format of 'cashflows' (e.g., array of numbers with negative outflows), or the role of 'currency.' The description adds no meaning beyond the parameter names.

  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 states 'Net Present Value,' which clearly identifies the tool's purpose as computing NPV. The verb 'COMPUTE' is generic but the resource is specific. It does not distinguish from sibling tools like calc_irr, which also compute financial metrics.

  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 such as calc_irr, calc_compound_growth, or other financial calculators. There is no mention of use cases, prerequisites, or scenarios where NPV is appropriate.

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

• decide_scoreC
  2.1/5.0
  Behavior2/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 of behavioral disclosure. It only hints at the output format (matrix + ranking) but does not explain normalization logic, whether the operation is read-only, required permissions, error behavior, or side effects. This leaves the agent without sufficient information to anticipate outcomes.

  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 extremely concise with no wasted words. However, it is under-specified and reads more like a heading than a functional description. While brevity is positive, the extreme minimalism harms clarity and the description does not fully earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (multiple parameters, nested objects, many sibling tools) and the absence of annotations and output schema, this description is grossly incomplete. The agent would not know the expected input structure, output details, or how to correctly invoke the tool, making it nearly unusable without additional information.

  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 4 parameters with 0% description coverage, and the description adds no meaning beyond the schema. It never explains what options, criteria, scores, or method are for. The description fails to compensate for the lack of schema descriptions, leaving parameter semantics completely unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description says 'DECIDE. Full normalized scored matrix + ranking.' This implies the tool produces a normalized score matrix and ranking, but it does not clearly state the action (e.g., 'evaluate options') or the inputs. It does not distinguish from sibling tools like decide_sensitivity or decide_compare_two, making the purpose vague though not purely tautological.

  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. There is no mention of suitable scenarios, prerequisites, or exclusions. Given the many decision-related siblings, this is a significant omission.

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

• calc_irrC
  2.3/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'COMPUTE' and offers no details on input handling, side effects, or assumptions. This is minimal and does not clarify how the tool behaves beyond the fact that it computes something.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely short ('COMPUTE. Internal Rate of Return.'), which is concise but under-specified. It lacks necessary details about inputs and context, so it is not appropriately structured for effective use.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has two parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain the cashflows format, the role of the guess parameter, or what the return value represents, making it impossible for an agent to use correctly without external knowledge.

  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%, so the description must compensate for the undocumented parameters. It mentions neither 'cashflows' nor 'guess', leaving the meaning of both parameters entirely unexplained. No value is added beyond the bare 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 states the verb 'COMPUTE' and the resource 'Internal Rate of Return', which clearly identifies the tool's function. However, it does not differentiate this from sibling tools like calc_npv or calc_metric, which are also financial calculations.

  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, nor any context about prerequisites or use cases. It is a bare statement with no usage direction.

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

• calc_business_daysC
  2.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions holidays but does not explain how holidays are determined, whether custom holiday inputs are required, or how regional defaults work. There is also no mention of date formats, potential side effects, or edge cases. This minimal disclosure is insufficient for a tool with no annotation support.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely short, composed of two fragments. While there is no fluff, it is under-specified to the point of offering almost no actionable information. The phrase 'COMPUTE.' is redundant and the rest does not provide enough detail for an agent to understand the tool's interface or behavior. This is under-specification rather than effective conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With six parameters, no output schema, no annotations, and no parameter descriptions, the description is severely inadequate. An agent cannot determine how to construct a valid request, what response to expect, or how to handle variants like custom holidays or region-specific rules. This is far below the minimum viable completeness for a tool of this 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?

  The schema includes six parameters with zero description coverage, and the description adds no meaning to parameter names such as operation, start_date, or custom_holidays. The phrase 'business-day arithmetic' vaguely implies the operation parameter, but it does not clarify valid values, date formats, or how parameters interact. The description fails to compensate for the lack of schema documentation.

  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 states 'Business-day arithmetic with holidays,' which clearly indicates a tool for date calculations involving business days. It distinguishes itself from sibling calc_* tools like calc_metric and calc_currency_convert by focusing specifically on business-day logic. However, the exact operations (e.g., adding days, counting days between dates) are not enumerated, leaving some ambiguity.

  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. The description is purely a statement of purpose and does not mention typical use cases, prerequisites, or any exclusions. An agent is left without context for selecting this tool over similar date-related tools.

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

• calc_currency_convertC
  2.4/5.0
  Behavior2/5

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

  With no annotations, the description bears full responsibility for behavioral disclosure. It only mentions Decimal precision, leaving unclear how rates are sourced, whether 'live' and 'date' affect results, or what edge cases exist. This is insufficient for a conversion tool.

  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, but 'COMPUTE.' is filler and does not earn its place. The meaningful part 'Convert currencies with Decimal precision.' is concise and front-loaded, so overall it is acceptable but not exemplary.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has five parameters, no output schema, and no annotations. The description provides almost no context about expected inputs, return values, rate behavior, or error conditions. It is far from complete for an agent to invoke it confidently.

  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 does not explain any of the five parameters. It does not clarify 'amount', 'from_currency', 'to_currency', 'date', or 'live'. The description adds no parameter-level meaning beyond what the schema field names imply.

  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 converts currencies and highlights Decimal precision, which is a specific action on a specific resource. It distinguishes itself from the financial calc sibling tools, though the leading 'COMPUTE.' adds no purpose information.

  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 such as calc_metric or calc_npv. The intent is implied by the tool name and description, but no explicit context or exclusions are given.

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

• decide_compare_twoC
  2.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of disclosing behavior. It only states the high-level purpose, not what the tool returns, whether it's read-only, how it processes criteria and scores, or any side effects. The 'head-to-head' hint is the only behavioral detail, insufficient for an agent to predict tool behavior.

  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 extremely concise with no wasted words, and it front-loads the action ('DECIDE'). However, it is under-specified to the point of being cryptic, as it lacks structure and detail. It is not verbose, but it fails to provide necessary context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 6 parameters (2 required), no output schema, and no annotations. The description is a single fragment that does not cover what inputs are needed, how they are structured, what the return value is, or any edge cases. An agent would be completely lost invoking this tool 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 does not explain any parameters. It mentions 'two options' but doesn't map to option_a, option_b, options, criteria, scores, or method. There is no information about required fields or how they relate to the decision process.

  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 states the tool's core function: deciding between exactly two options ('head-to-head'). The verb 'DECIDE' and the resource 'two options' are specific, and it distinguishes itself from siblings like sim_compare (which is simulation-based) and decide (which likely handles more options). However, it is terse and could be clearer about the decision output.

  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 implies the tool is for comparing two options but provides no explicit guidance on when to use it versus alternatives. It doesn't mention when not to use it or name sibling tools like 'decide' for other scenarios. The only clue is 'exactly two options,' which is a weak implicit constraint.

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

• decide_sensitivityC
  2.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears the full burden. It mentions the high-level behavior (winner robustness under weight changes) but does not disclose output format, side effects, required method, or execution details.

  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 text is concise and front-loaded with the domain verb 'DECIDE,' but it is a fragmentary under-specification rather than a well-structured description. It is short but not sufficiently informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 6 parameters, nested objects, no annotations, no output schema, and no parameter documentation, this single clause is completely inadequate for agent selection and 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?

  Schema coverage is 0% for all 6 parameters, and the description adds no meaning to options, criteria, scores, steps, method, or variation. The agent has no clue how to populate these fields from the description.

  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's purpose: assessing the robustness of the decision winner to criteria-weight changes. It is specific enough to distinguish it from sibling tools like decide or decide_score, though it does not delineate against sim_sensitivity.

  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?

  There is no guidance on when to use this tool versus alternatives such as sim_sensitivity, stress_test_decision, or decide. No exclusions, prerequisites, or situational context are provided.

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

• plan_to_valuationC
  2.4/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry full behavioral disclosure. It reveals the composite nature (simulate -> compute) and the valuation focus, but omits essential details: whether the simulation is stochastic, how the cash-flow line is derived, what side effects (if any) exist, and what the output structure looks like. This is insufficient for a tool that clearly chains multiple operations.

  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, front-loaded sentence that wastes no words. The 'COMPOSITE' prefix immediately signals multi-step behavior, and the rest states the core action. However, the extreme brevity borders on under-specification, but that is a completeness issue, not a conciseness defect.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (8 parameters, no output schema, no annotations, and a multi-step operation), the description is grossly incomplete. It fails to explain how simulation inputs are provided, what cashflow_metric options exist, how rate and horizon affect the calculation, or what the return value contains. This is a bare teaser rather than a functional specification.

  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 input schema has 0% description coverage across its 8 parameters, so the description must compensate. It does not. No parameter is explained: 'template', 'cashflow_metric', 'rate', 'inputs', 'horizon', 'currency', 'period_label', and 'initial_investment' remain opaque. The description only mentions 'cash-flow line' and 'NPV/IRR', which are outputs rather than inputs.

  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 identifies a composite simulate-then-compute workflow, explicitly mentioning NPV/IRR valuation of a cash-flow line. This is a clear verb+resource pairing and is distinguishable from sibling tools like sim_run or calc_npv because it chains both steps. However, the 'COMPOSITE (simulate -> compute)' phrasing is somewhat cryptic and doesn't fully specify the operation sequence.

  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 like sim_run, calc_npv, or calc_irr. The description implies a scenario projection followed by valuation but does not state exclusions or recommend this tool over separate sim+calc steps. Users must infer its niche from the tool name and sibling context.

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

• calc_loan_amortizationC
  2.5/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only says 'COMPUTE. Level-payment loan schedule.' and does not explicitly state whether the operation is read-only, what output format is returned, or how optional parameters like extra_payment affect results. 'COMPUTE' implies a pure calculation but lacks explicit confirmation.

  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 compact and front-loaded with the action, but the two fragments ('COMPUTE' and 'Level-payment loan schedule') are under-specified for a tool with six parameters. It is not verbose, but it lacks sufficient substance beyond a one-liner.

  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 no output schema, no annotations, and a six-parameter input schema, the description should explain return shapes and optional parameter semantics. It only names the high-level output, leaving important context for correct invocation missing.

  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 adds no meaning to principal, annual_rate, term_months, extra_payment, include_schedule, or currency. The agent must rely entirely on parameter names, which may be ambiguous for optional 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?

  The description clearly states the tool computes a 'level-payment loan schedule', with 'COMPUTE' as the specific action and 'loan schedule' as the resource. This distinguishes it from sibling calculators like calc_npv or calc_irr.

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

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives, when not to use it, or any prerequisites. The description does not mention fixed-rate loans, required inputs, or relationships to sim_* tools.

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

• sim_break_evenC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states the outcome (solving for an input value) but does not disclose whether the tool is read-only, what happens if no solution exists, whether it requires a web service call, or any side effects. The lack of detail is a significant gap.

  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 very concise—a single sentence that front-loads with 'SIMULATE' to set context. However, it is too brief to provide meaningful structure or guidance for a tool with 8 parameters, and the lack of segmentation makes it less useful than a slightly longer, organized description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the moderate complexity (8 parameters, nested objects, no output schema), this description is grossly incomplete. It gives no information about input semantics, expected output, error handling, or relationship to other simulation tools, making it impossible for an agent to reliably select and invoke the tool 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?

  The input schema has 8 parameters with 0% schema description coverage, and the description itself provides no explanation of any parameter. It does not clarify what 'template', 'solve_for', 'target_value', or other fields mean or how they relate to the break-even goal, leaving an agent with no semantic grounding.

  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: solving for an input value that causes a metric to hit a target. This distinguishes it from sibling tools like sim_sensitivity (which analyzes sensitivity) and sim_run (which runs simulations) by specifying the break-even objective.

  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?

  There is no guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, such as needing a template from sim_list_templates, or when it should be preferred over sim_sensitivity or sim_compare. No exclusions or alternative recommendations are provided.

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

• sim_sensitivityC
  2.6/5.0
  Behavior2/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 of behavioral disclosure. 'SIMULATE' implies a non-mutating analysis, but it doesn't explain whether it creates resources, requires authentication, modifies state, or how variations are applied. Minimal 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 short and front-loaded. However, 'SIMULATE.' is a filler word that repeats the tool's domain and adds no information; the second sentence alone would be sufficient. Still, no wasted length beyond that.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a nine-parameter sensitivity tool with no output schema and no annotations. The description omits how variations are applied, what the output shape looks like, prerequisites like the required template, and relationships among parameters. It is incomplete for reliable agent invocation.

  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 0% schema description coverage, the description must explain the many parameters. It only hints at 'scenario inputs' and 'target metric', leaving template, variables, variation, steps, horizon, and period_label unexplained. It does not compensate for the schema gap.

  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 identifies a sensitivity-analysis tool: vary scenario inputs to see impact on a target metric. It distinguishes from siblings like sim_run or sim_compare by emphasizing input variation and impact measurement, though it doesn't explicitly name alternatives.

  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 explicit when-to-use guidance or alternatives are provided. The phrase 'Vary scenario inputs...' implicitly suggests sensitivity analysis, but it doesn't state when to prefer this over sim_run, sim_compare, or sim_break_even.

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

• evaluate_options_with_scenariosC
  2.7/5.0
  Behavior2/5

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

  No annotations are present, so the description bears the full burden of disclosing behavioral traits. It only describes the high-level sequence (simulate, then decide) and the actions of projecting and ranking, but remains silent on side effects, read-only status, data handling, or any constraints. This gives minimal insight into what happens during execution.

  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, compact sentence that front-loads the composite nature and main actions. It is easy to scan and lacks redundancy, but the extreme brevity limits the amount of information conveyed, making it concise but not fully substantive.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity — 7 parameters, nested objects, no output schema, and no annotations — the description is highly incomplete. It does not specify the return format, how options and criteria should be structured, or the expected behavior of the composite pipeline. An AI agent would lack critical context to invoke the tool 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?

  The schema has 7 parameters with 0% description coverage, and the description itself does not explain the meaning or format of any parameter. It mentions 'option' but not 'criteria' or any other fields, leaving the required inputs undefined. The description fails to compensate for the schema's lack of explanatory text.

  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 labels the tool as a composite of 'simulate -> decide' and states it 'project[s] each option, rank[s] the outcomes,' which communicates a clear two-step purpose. It distinguishes itself from individual sim_* and decide_* sibling tools by presenting a combined workflow, though 'project' is somewhat vague and the required 'criteria' parameter is omitted.

  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 'COMPOSITE' prefix implies that this tool is appropriate when both simulation and decision-making are needed, but it does not explicitly specify when to use this over running sim_run and decide separately, nor does it describe any exclusions or prerequisites. The guidance is implied rather than explicit.

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

• stress_test_decisionC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full responsibility for disclosing behavior. It only provides a high-level summary ('Stress a scenario assumption and see if the winner holds') without explaining side effects, prerequisites, return format, or how the composite operation works. This is insufficient for a complex tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, but it is not appropriately sized for the tool's complexity. It under-specifies the tool's behavior and inputs, making it terse rather than genuinely concise. Essential information is sacrificed for brevity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (8 parameters, nested objects, no output schema, no annotations), the description fails to provide sufficient context for correct invocation. It lacks details on required inputs, the meaning of 'winner', how stress testing is performed, and what the result represents. The description is severely incomplete.

  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 8 parameters with 0% coverage (no descriptions), and the tool description does not mention any parameter names, meanings, or relationships. The description adds no value in explaining what 'options', 'criteria', 'stress', 'inputs', or 'method' mean, leaving users completely in the dark.

  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 with a specific verb ('stress') and resource ('scenario assumption'), and the outcome ('see if the winner holds'). The 'COMPOSITE (simulate x decide)' label distinguishes it from the separate sim_* and decide_* sibling tools, making the purpose unambiguous.

  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 combined simulation and decision tasks via the 'COMPOSITE (simulate x decide)' label, but it does not explicitly state when to use this tool instead of alternatives or provide exclusions. No specific sibling tools are named as alternatives, so the guidance is implicit rather than explicit.

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

• calc_metricC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full burden of behavioral disclosure, but it only says 'COMPUTE' and 'Exact.', implying a pure calculation without side effects. It does not describe return format, error behavior, or any side effects. 'Exact' hints at precision, but this is minimal context that does not adequately inform the agent about the tool's behavior.

  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, concise sentence with no wasted words. The leading 'COMPUTE.' verb is front-loaded, making the tool's primary action immediately clear. It is well-structured for its limited content, though it sacrifices detail 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 the tool's complexity (3 parameters, one a nested object, no output schema, no annotations), the description is severely incomplete. It does not mention what the tool returns, how to use the 'params' object, or what metrics are supported beyond a partial list. Sibling tools include a list function (calc_list_metrics) that might help, but the description does not reference it or provide enough context for correct invocation.

  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, so the description must compensate, but it only provides example values for the 'metric' parameter (ltv, cac, rule_of_40, nrr). It does not explain the structure or purpose of the 'params' object or the 'currency' parameter, leaving the agent without enough information to construct valid inputs.

  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's purpose: it computes exact business/SaaS/finance metrics, with examples like ltv, cac, rule_of_40, and nrr. This distinguishes it from more specific sibling tools (e.g., calc_npv, calc_irr) by serving as a generic metric calculator, though it could be more explicit that it accepts a metric name and computes the corresponding value.

  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 usage guidance is provided. The description does not mention when to use this tool versus alternatives like calc_npv or calc_irr, nor does it indicate any prerequisites or exclusions. Users are left to infer that it handles a range of business metrics, but there is no explicit when-to-use or 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.

• sim_runC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden. 'Deterministic' is a useful behavioral trait, but the description does not disclose side effects, prerequisites, output behavior, or whether it is read-only. This is minimal transparency for a simulation tool.

  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 sentence, front-loaded with the core action 'SIMULATE'. Every word adds value, making it highly concise and appropriately structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has five parameters, nested objects, no annotations, no output schema, and a minimal description. There is no information about how to construct inputs, what horizon/period_label mean, or what a successful simulation returns. This is far from complete for a tool of this complexity.

  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 does not explain any of the five parameters. It mentions 'template' and 'free-form metrics model' as concepts, but provides no meaning for 'inputs', 'horizon', 'period_label', or the exact structure of the metrics objects. The description fails to compensate for the undocumented 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 the verb 'SIMULATE' and a clear resource 'what-if projection', specifying scope via 'template or free-form metrics model'. This distinguishes it from siblings like sim_sensitivity or sim_compare, though no explicit alternative is named.

  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 deterministic what-if projections and indicates two input modes (template, metrics). It does not provide explicit when-to-use versus alternatives, nor any exclusions, so the guidance is implied rather than direct.

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

• sim_compareC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only states that the tool simulates and compares 2-3 scenarios, omitting any details about side effects, prerequisites, output format, or limits—leaving the agent with little understanding of what the tool actually does beyond its basic function.

  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 brief and front-loaded with the 'SIMULATE' label, with no wasted words. However, it leans toward under-specification rather than purposeful conciseness, so it isn't a perfect 5.

  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 4 parameters, no annotations, and no output schema, this description is far from complete. It omits parameter meanings, expected outputs, and relationship to sibling simulation tools, providing only a bare-bones function statement.

  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%, and the description only indirectly references the 'scenarios' parameter by adding the 2-3 count constraint. It does not explain 'goal', 'horizon', or 'compare_metric', so most parameters remain semantically undefined.

  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 core action—comparing 2-3 scenarios side by side—and the 'SIMULATE' prefix establishes the simulation domain, distinguishing it from decision or calculation tools. It lacks explicit differentiation from sibling tools like sim_run, but the core purpose is specific and clear.

  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 phrase 'Compare 2-3 scenarios side by side' implies the tool is for side-by-side comparison of a small number of scenarios, but it offers no explicit when-to-use guidance or mention of alternatives. This is minimal implied usage context, not explicit direction.

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

• calc_list_metricsB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description must carry the burden of behavioral disclosure. It only states the action without noting that it is read-only, non-destructive, or any limitations like response size. The 'COMPUTE.' prefix is unclear and adds no 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 extremely concise and front-loaded with the primary verb 'List'. However, the 'COMPUTE.' prefix is cryptic and could be removed without loss of meaning, slightly reducing structure quality.

  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?

  As a simple, parameterless list tool, the description gives the core function but lacks any explanation of the return format or how the output relates to the sibling calc_* tools. No output schema exists, so the description should clarify what 'metrics + schemas' means in practice; it does not.

  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 tool has zero parameters, so the baseline is 4. The description adds no parameter semantics, but none are needed since the input schema is empty and the action is parameterless.

  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 lists supported metrics and schemas, using a specific verb and resource. It distinguishes from calc_metric (which computes) and list_capabilities (which is broader), though it doesn't explicitly name alternatives.

  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?

  There is no guidance on when to use this tool versus the many sibling tools. The description is a bare command with no context for selection, such as 'use this to discover available metrics' or exclusions for list_capabilities.

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

• decide_list_methodsB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'List scoring methods,' which implies a read-only action but does not disclose the output format or any side effects. This is insufficient for a tool with no annotation support.

  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 extremely brief, using only a few words to convey the action. It is front-loaded with 'DECIDE.' but this prefix is somewhat cryptic. Nevertheless, every word is purposeful, and there is no wasted text.

  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 tool is simple with no parameters, but the description lacks details about what the list of scoring methods contains or how it relates to sibling decision tools. Without an output schema, more context about the return value would be beneficial.

  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 zero parameters, so there is nothing to document. The description does not need to elaborate on parameter meaning, and the baseline for zero-parameter tools is 4.

  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 verb 'List' and the resource 'scoring methods,' effectively indicating the tool's purpose. It distinguishes from sibling tools like decide_score or decide_sensitivity by focusing on enumeration rather than execution. However, it does not elaborate on what constitutes 'scoring methods,' so the clarity is good but not exhaustive.

  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. There are no conditions, scenarios, or comparisons to other tools, leaving the agent without context on appropriate usage.

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

• health_checkB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavioral traits. It hints at read-only aggregation but does not explicitly state side-effect-freeness, required permissions, or what 'health' checks entail. Minimal behavioral context is offered.

  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, front-loaded sentence that efficiently conveys the tool's purpose. No wasted words.

  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?

  For a simple no-parameter tool, the description is adequate but leaves gaps: it does not describe the shape, format, or granularity of the returned health data, and there is no output schema. Could be more explicit about what constitutes 'health'.

  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 tool has zero parameters, and the schema fully covers the empty parameter set (100% coverage). The description adds no parameter details, which is acceptable since there are none to document.

  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?

  Description identifies the tool as reporting aggregated health across the whole stack, which distinguishes it from unrelated siblings. However, it lacks an explicit verb and remains somewhat vague about what 'health' encompasses.

  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 about when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or typical use cases.

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

• list_capabilitiesB
  3.3/5.0
  Behavior2/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 of behavioral disclosure. It only says 'Discovery: ...' and does not state that it returns a simple list, is a read-only operation, or describe any side effects or output structure, leaving most behavioral traits undisclosed.

  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, front-loaded sentence with no wasted words. It is compact, though slightly telegraphic ('Discovery:'), which is acceptable for such a simple tool.

  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?

  For a zero-parameter discovery tool, this is close to adequate: it lists the main content categories. However, 'profiles' is vague, and there is no mention of output format or how the agent should use the returned information, which is valuable for a tool that helps orient the 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 tool has zero parameters and the schema is an empty object, so there is no parameter documentation burden. The description need not explain anything about inputs.

  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 identifies the tool as a discovery/list tool for namespaces, composite tools, and profiles. This distinguishes it from the many specific sibling tools, though 'Discovery' is a noun rather than an explicit verb.

  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 word 'Discovery' implies the tool is meant to be used to explore available capabilities before invoking specific siblings, but no explicit when-to-use or alternative guidance is provided. The context of many siblings makes this use case fairly clear.

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

• decideA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of disclosing behavior. It mentions the outputs (winner, ranking, breakdowns, explanation) but does not elaborate on how weights are applied, what breakdowns entail, or any potential side effects. It is a read-only calculation tool, but this is not explicitly clarified.

  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, front-loaded sentence that captures the core function and outputs. Every word contributes meaning, with no redundancy or filler.

  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?

  The description is too brief given the tool's complexity and the lack of output schema or annotations. It omits crucial details about parameter structure (especially the 'scores' object and 'method'), which are needed for correct invocation. The return value is at least partially described, but the input handling is unclear.

  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 compensate. It mentions 'options' and 'weighted criteria' but does not explain the structure of the required 'scores' object, the 'method' parameter, or how weights within criteria are represented. This leaves the agent without sufficient guidance to construct valid inputs.

  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 function: ranking options against weighted criteria and returning a winner, ranking, breakdowns, and explanation. This distinguishes it from sibling tools like decide_score or decide_compare_two, which focus on specific aspects.

  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 the use case (ranking options with weighted criteria) but does not explicitly state when to use this tool versus alternatives like decide_sensitivity or decide_compare_two. There is no exclusions or alternative guidance.

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

• sim_list_templatesA
  3.9/5.0
  Behavior4/5

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

  No annotations are provided, so the description must convey behavioral traits. The verb 'List' inherently indicates a read-only operation, and the description explicitly states the output includes 'every scenario template with inputs and outputs,' providing clear expectation of the result. However, it does not disclose details such as ordering, pagination, or potential performance implications, which is a minor gap.

  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 extremely concise and to the point. The 'SIMULATE.' prefix adds a category label but does not harm clarity; the core sentence 'List every scenario template with inputs and outputs' is 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 that this is a simple listing tool with no parameters and no output schema, the description adequately covers the essential information: what it lists (scenario templates) and what it includes (inputs and outputs). It lacks any further detail on return format, but the simplicity of the tool makes this 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?

  The input schema has zero parameters, and the description confirms that no input is required. This aligns with the baseline of 4 for a tool with no parameters, as there is no ambiguity about required inputs.

  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 the specific verb 'List' on the resource 'scenario template' and specifies the scope as 'every' with 'inputs and outputs.' This clearly distinguishes it from sibling tools like sim_run, which executes simulations rather than listing templates.

  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. It does not mention that this is a discovery tool to be used before running simulations with sim_run, nor does it state any exclusions or alternative scenarios.

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