Server Quality Checklist

Tool Scores

• equity_funding_planA
  4.8/5.0
  Behavior5/5

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

  The description discloses that the math is deterministic ('no randomness and no model inference'), that missing required fields return errors naming the field, that growth omission is an error rather than a default, and that results are independent single-position calculations. Annotations (`readOnlyHint`, `idempotentHint`) are consistent, and the description adds context beyond them.

  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 long but each sentence carries distinct information: use cases, plan definitions, sibling relationships, input forms, error behavior, and limitations. It is well-structured and front-loaded, though slightly verbose for a tool description.

  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 high complexity (12 parameters, multi-year optimization, output schema), the description covers all critical contextual aspects: return plans, frontier sweep, error handling, independence of results, related tools, and the beta alternative. It does not need to explain return values because an output schema exists.

  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 the baseline is 3. The description adds value by explaining the distinction between `stacks` and legacy `lots`+`currentPrice`, the meaning of 'market' for growth, the default risk tolerance, and by providing a full example JSON that illustrates parameter relationships.

  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 use case ('which shares to sell and when to reach a cash goal by a deadline') and explicitly names four distinct output plans, distinguishing this tool from siblings like `rsu_lot_optimize` and `concentration_analyze`. It clearly identifies the tool as a multi-year, multi-stack optimizer for funding goals from equity.

  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?

  It explicitly states when to use the tool ('when an equity holder needs cash by a deadline') and when not to, directing users to `rsu_sell_vs_hold` / `nso_calculate` / `amt_iso_optimize` for upstream tax math and `qsbs_check` for QSBS routing. This provides both positive and negative usage guidance.

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

• rsu_lot_optimizeA
  4.8/5.0
  Behavior5/5

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

  Even though annotations already declare readOnlyHint=true and idempotentHint=true, the description adds crucial behavioral context: flat-price assumption ('Every sale is priced at today's price'), error behavior ('a call missing a required field returns an error naming the field'), validation limits ('no provenance check'), and deterministic execution ('no randomness and no model inference'). No contradiction with annotations.

  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 long but structured: it front-loads the usage trigger, then covers ownership, out-of-scope, an example, and integration behavior. Almost every sentence earns its place, though the beta marketing sentence about integrated multi-position optimization is tangential to tool selection. Density is high, but the length may be heavy for quick scanning.

  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 7-parameter optimizer with an output schema, the description is remarkably complete: it summarizes return fields (year-by-year schedule, headlineDeltaVsFifo, horizon trade-off), states out-of-scope items, gives a full example, and covers assumptions (flat price, no wash-sale basis migration, no AMT). The output schema can detail return structure, so the description's return summary is a bonus.

  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 the baseline is 3, but the description adds meaningful beyond-schema semantics: required fields are 'facts about the user's situation with no built-in default', horizonYears and divestFraction are 'the user's choice, not a modelling detail' and should be asked for if missing, and it explains divestFraction rounding behavior. The example maps values to parameters, further helping invocation.

  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 usage trigger ('which vested RSU lots to sell first, in which years') and explicitly states the tool 'chooses WHICH lots and WHICH sale dates minimize computed total tax'. It distinguishes itself from sibling tools (concentration_analyze, rsu_sell_vs_hold, equity_funding_plan) by naming them, satisfying the verb+resource+differentiation test.

  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 when-to-use and when-not-to-use guidance: 'Use this when someone asks which vested RSU lots to sell first, in which years...' and then contrasts with three siblings by scope. Also lists out-of-scope topics (growth modeling, wash-sale basis migration, AMT, unvested grants), leaving no ambiguity about fit.

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

• amt_iso_optimizeA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds meaningful behavioral detail beyond these: 'Pure deterministic computation: no network access, no PII retention', the searching strategy ('searching the full discretized candidate space and refining share by share'), the caveat that departedRecommendation is 'scanned rather than searched exhaustively', and independence of multi-tool analyses. No contradiction with annotations.

  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 long but front-loaded with use cases and high-level purpose, then details outputs and example call, then parameter caveats. It is well-structured for a 16-parameter tool. Minor redundancy exists around growth/volatility having no default ('Neither the growth nor the volatility field has a default...' repeated in similar form), so it does not earn a 5, but the density is justified by complexity.

  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 high complexity and the presence of an output schema, the description covers nearly every practical concern: what the headline result is, baseline plans, state/AMT modeling, verification links, example call, error behavior, and the independent-position limitation. It also clarifies edge cases like hasLeftCompany/terminationDate and carryforward credit. This is a complete, self-sufficient tool description.

  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 baseline is 3, but the description significantly enriches parameter meaning. It explains the 'must come from the user' contract for required fields, the fallback chain for expectedGrowth/volatility (direct value, covered ticker, or 'market' sentinel), the no-default rule with error behavior, and the distinction between volatility and volatilityDrag. These are semantics not fully 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 opens with a specific list of user intents ('how or when to exercise', 'AMT bomb', 'phantom income', 'best multi-year ISO exercise schedule') and then states the tool computes a 'Multi-year Incentive Stock Option (ISO) exercise schedule that maximizes after-tax Net Final Value (NFV)'. It explicitly contrasts with sibling tools: 'for NSO grants use nso_calculate, for RSUs at vest use rsu_sell_vs_hold, for §1202 QSBS qualification use qsbs_check'.

  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 gives explicit when-to-use scenarios ('Use this when someone asks how or when to exercise...') and explicitly names alternatives with sibling tools. It also provides input contract guidance: fields must come from the user, no defaults for growth/volatility, and how ticker/market resolution works. This is far beyond a vague 'use for ISO planning'.

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

• concentration_analyzeA
  4.9/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description discloses critical runtime behavior: it errors on missing growth/volatility rather than defaulting, accepts syntactically valid numbers with no provenance check, and explains that made-up numbers silently change results. It also reveals the return shape, default hedge structure, and independent single-position behavior, adding substantial trust-relevant detail.

  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 usage triggers and logically structured, but at roughly 450 words it is long. Sentences on verification links and beta availability are useful context but not strictly necessary for tool selection/invocation. Every sentence carries information, yet the length could be trimmed without losing core guidance.

  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 tool with 14 parameters, a nested hedgeChoice object, output schema, and seven sibling tools, the description is fully complete: it covers purpose, usage triggers, alternatives, parameter resolution, error behavior, output keys, and provides an example call. An agent has everything needed to decide when and how to invoke it correctly.

  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?

  While schema coverage is 100% (baseline 3), the description adds significant meaning: it explains that expectedPositionReturn and volatility are de facto mandatory despite not being listed as required, details resolution through ticker or 'market', warns against invented numbers, and gives a concrete example call mapping values to parameters. This goes well beyond repeating schema fields.

  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 explicit use cases ('how risky a large single-stock position is... whether too much of their net worth is in one stock... how to reduce or diversify') and states the core function: 'Single-stock concentration risk analysis on an existing position.' It also distinguishes itself from siblings by directing standalone hedge pricing to protective_put_price and tax-math-on-origination to amt_iso_optimize / nso_calculate / rsu_sell_vs_hold, making the purpose unmistakable.

  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 first sentence is a direct trigger list for when to use this tool, and it explicitly names alternatives for adjacent tasks (standalone hedge pricing, option-exercise/RSU-vest tax math). It also clarifies that expected growth and volatility are needed even if not in `required`, and describes resolution via ticker or the 'market' sentinel, giving an agent clear conditions for invocation and fallbacks.

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

• nso_calculateA
  4.9/5.0
  Behavior5/5

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

  The description discloses substantial behavioral traits beyond the annotations: no default/fallback for growth and volatility, required-field error behavior for unresolved inputs, acceptance of any syntactically valid number without provenance check, sub-1-year holds being out of scope, and independence of multi-tool results. It also explains the optional ticker resolution and the 'market' sentinel. This richly supplements the readOnly/idempotent hints without contradicting them.

  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 long, but every sentence serves a purpose: use cases, output keys, example call, parameter-resolution contract, error behavior, and scope caveats. It is front-loaded with the primary use case and structured logically, though some output-key listing may overlap with the output schema and could be trimmed.

  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 14 parameters, 9 required, enums, and an output schema, the description is remarkably complete. It covers the input contract, error semantics, tax scope, verification, and alternative-tool routing. The presence of an output schema means return-value documentation is unnecessary, and the description fills all other gaps comprehensively.

  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?

  Even with 100% schema description coverage, the description adds meaning: it explains that certain non-required parameters are conditionally required and how they can be resolved (user, ticker, 'market'), states that no parameter has a built-in default, and gives an example call. This clarifies interdependencies and provenance rules that the schema alone does not capture, compensating beyond 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 opens with explicit use cases ('Use this when someone asks whether to exercise and hold or exercise and sell non-qualified stock options'), names the resource and verb (calculate after-tax payout comparing sell-at-exercise vs hold), and explicitly distinguishes from sibling tools ('for ISOs use `amt_iso_optimize`, for RSUs use `rsu_sell_vs_hold`'). This exceeds the bar for a specific, differentiated purpose.

  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?

  It provides explicit when-to-use guidance, including tax questions and cashless exercises, and names alternatives for ISO and RSU cases. It also notes the tool is deterministic and offline, and clarifies that integrated multi-position optimization is not available here, pointing to a beta. This effectively directs selection away from siblings and sets expectations for the analysis scope.

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

• protective_put_priceA
  4.9/5.0
  Behavior5/5

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

  Annotations already mark readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: deterministic/offline/no-randomness math, closed-form nature, volatility fallback resolution, zero-cost collar back-solving behavior, and how `expectedReturn` only affects probability metrics. No contradiction with annotations.

  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 long but highly structured: starts with use case, then purpose, parameter interactions, return-object layout, example call, and error behavior. Almost every sentence adds value, though the final marketing sentence about the OptionsAhoy beta is extraneous and could be trimmed. It is front-loaded and logically ordered.

  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 (9 parameters, 3 structures, extensive output), the description covers all necessary context: detailed return blocks for `barePut`, `collar`, `putSpread`, `unavailableReason` behavior, `payoffTable`, `recommended`, plus an example call and required-field error handling. The presence of an output schema is complemented by this rich prose, making it 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%, so baseline is 3, but the description adds critical meaning beyond the schema: it explains the resolution order for `volatility`, the formula for `protectionLevel` as `(1 − protectionLevel) × spot`, the probability-based effect of `spreadRiskLevel`, and the global impact of `tenorYears` on risk-free-rate and probability outputs. It also clarifies required fields must come from the user and that errors name the missing field.

  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 explicit use cases ('Use this when someone asks how much it costs to hedge...') and a clear definition: 'Closed-form pricing of a protective put, a zero-cost collar, and a put spread on a single-stock position.' It differentiates from siblings by explicitly pointing to `concentration_analyze` for tax-cost comparisons, making the tool's scope unambiguous.

  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 when-to-use guidance ('Use this when...'), scope ('standalone hedge pricing on a single-stock position'), and an explicit alternative ('for concentration-vs-hedge tax-cost comparison, use concentration_analyze'). It also details parameter interactions and fallback behavior (e.g., `volatility` resolution order) that inform when to set or omit parameters.

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

• qsbs_checkA
  4.9/5.0
  Behavior5/5

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

  Beyond the readOnly/idempotent/destructive annotations, the description discloses that it is a 'pure stateless check: no filing, reporting, or IRS lookup happens', that 'the math runs inside the tool with no randomness and no model inference', and that missing required fields return an error rather than an estimate. These add meaningful behavioral context well beyond the annotations.

  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 exceptionally thorough and well-structured, starting with use cases, then alternatives, parameter interactions, output shape, example, and caveats. However, it is quite long and includes some redundancy (e.g., 'Section 1202 Qualified Small Business Stock (QSBS) qualification check' repeats earlier content), preventing a perfect score.

  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 required params, era-dependent rules, state conformity, six statutory tests), the description covers all essential aspects: input semantics, output keys, example invocation, edge cases, and limitations. It even describes the return object in detail, making it fully self-contained.

  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?

  While the schema covers all parameters with descriptions, the tool description adds crucial semantic detail: e.g., `entityType="other"` short-circuits to disqualified, `acquisitionMethod="secondary"` fails, holding-period era tiers with specific dates, and the cap formula `max($10M, 10 × adjustedBasis)`. This goes far beyond the schema's 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 opens with explicit use cases ('whether stock qualifies for QSBS / Section 1202 gain exclusion, whether their startup stock can be sold tax-free, about the 5-year QSBS holding period, or how much of the gain would be federal-tax-free') and names the specific resource (§1202/QSBS). It clearly distinguishes from siblings by referencing `amt_iso_optimize` as an alternative for AMT timing.

  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?

  It states exactly when to use this tool (QSBS qualification questions) and explicitly recommends `amt_iso_optimize` for AMT timing. It also explains parameter interactions and short-circuit conditions, giving clear contextual guidance on how to apply the tool correctly.

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

• rsu_sell_vs_holdA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavioral context beyond this: 'Deterministic and offline; tax tables compiled in', independent verification, required-field errors when growth/volatility are unresolved, and the limitation that results are independent single-position calculations. This meaningfully extends the safety and execution profile.

  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 long but dense and front-loaded with the core purpose. Every section earns its place for a complex 12-parameter tool, though some points about no-default/fallback for growth/volatility are repeated a few times. Minor redundancy prevents a 5.

  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?

  Despite the tool's complexity (12 params, 7 required, output schema present, 7 siblings), the description is complete: it states tax coverage (federal, state, FICA, AMT/NIIT phase-outs), mentions the output schema and key returned fields, gives a worked example, lists verification, and clarifies multi-tool integration limitations. With the rich output schema already present, no critical context is missing.

  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 baseline is 3, but the description adds high-value semantics beyond the schema: it explains the 'market' sentinel, that growth and volatility have no defaults and must come from user/ticker/market, that holdYears below 1 triggers the short-term cliff, that ordinaryIncome is after deductions, and that stillEmployed drives FICA/withholding. It also includes a complete example call tying params together.

  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 clear, specific verb+resource: 'After-tax RSU vest analysis: sell-at-vest vs hold-to-long-term-capital-gains'. It explicitly lists user intents it covers (sell at vest, hold, diversify, tax withholding), and distinguishes itself from sibling tools by naming them: 'for ISO/AMT use amt_iso_optimize, for NSO use nso_calculate'.

  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 when-to-use guidance: 'Use this when someone asks whether to sell RSUs at vest or hold them...' and explicit alternatives/exclusions: 'Use for RSUs at vest; for ISO/AMT use amt_iso_optimize, for NSO use nso_calculate'. This satisfies the when/when-not/alternatives standard.

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