Server Quality Checklist

Tool Scores

• calculate_acbA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the calculation method (average-cost, not FIFO), the types of outputs, and that it is a tax aid requiring verification. It does not mention potential limitations (e.g., number of trades) or errors, but the disclosed behaviors are clear and sufficient for basic usage.

  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 structured in three paragraphs: purpose, outputs, and input format. It is concise with no fluff, but it could be slightly shortened by combining sentences. The key information is front-loaded.

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

  Completeness4/5

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

  Given the complexity of a tax calculation tool with 2 parameters and no output schema, the description provides detailed output types, input formats, and a warning. It covers the major aspects, though it lacks details on error handling, maximum trade counts, or currency handling. Overall, it is sufficiently complete for most use cases.

  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 description coverage is 0%, so the description must compensate. It does so extensively: it defines 'csv_path' as a file path for CSV/JSON, and 'transactions' as an array of objects with detailed structure (date, action, security, shares, price, etc.), adding critical meaning beyond the schema's minimal typing.

  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 it computes adjusted cost base and capital gains for trades under Canadian rules, using the CRA average-cost method. It specifies the outputs (holdings, gains, summaries, warnings). However, it does not explicitly differentiate itself from sibling tools like 'acb_summary' or 'capital_gains_report', leaving some ambiguity about when to use this tool over alternatives.

  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 explains how to pass trades (inline or file path) and provides transaction structure. It includes a disclaimer about being a calculation aid. However, it does not give explicit guidance on when to use this tool vs. siblings, such as whether to use this for full calculations or 'acb_summary' for summaries.

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

• capital_gains_reportA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It transparently explains the tool accepts inline transactions or a CSV path, applies superficial losses, and produces a detailed report. It also includes a disclaimer that it is not tax advice. However, it does not mention error handling, rate limits, or permissions.

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

  Conciseness5/5

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

  The description is concise, well-structured, and front-loaded with the primary purpose. Each sentence adds value, covering what the tool does, input options, output details, and a cautionary note, without unnecessary verbosity.

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

  Completeness4/5

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

  The description explains the output (dispositions with proceeds, ACB, etc., plus totals) despite no output schema. It covers the key input parameters and limitations. However, it lacks discussion of error scenarios or edge cases, which would enhance completeness for a tool with no external schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description compensates well. It explains the tax_year parameter, the choice between csv_path and transactions, and provides a detailed breakdown of the transaction object format (date, action, security, shares, price, optional fields). This adds meaning beyond the schema's basic type definitions.

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

  Purpose5/5

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

  The description clearly states it produces a capital-gains report for a single tax year (Schedule 3 style), listing dispositions with proceeds, ACB, outlays, and totals. It distinguishes from sibling tools (acb_summary, calculate_acb, check_superficial_losses) by focusing on a comprehensive report rather than just ACB or loss 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 does not provide explicit guidance on when to use this tool over siblings or alternatives. It only mentions it is a calculation aid and advises verifying results, but lacks context for selection criteria.

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

• acb_summaryA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It explains input formats (transactions or csv_path) and output (holdings, shares, ACB). However, it does not disclose what happens with empty inputs, error behavior, or the exact output structure beyond general fields.

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

  Conciseness4/5

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

  The description is well-structured with two paragraphs: first states purpose, second gives parameter details. It is informative without being verbose. Minor improvement could be front-loading the comparison earlier, but overall concise.

  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 no output schema, the description covers inputs thoroughly and explains what the output shows (holdings, shares, ACB). It lacks mention of error handling or edge cases, but is reasonably complete for the tool's complexity.

  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 0% (parameters anyOf without description), but the description fully details both parameters: 'transactions' as an array of objects with required and optional fields (date, action, security, shares, price, etc.) and 'csv_path' as a path. This adds essential meaning beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool shows current holdings (shares, total ACB, ACB per share) and distinguishes itself from the sibling tool 'calculate_acb' by noting it's a lighter view for current book cost. Purpose is specific and differentiated.

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

  Usage Guidelines4/5

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

  The description explicitly says when to use this tool: 'when you only want the current book cost of what is still held' and contrasts it with 'calculate_acb'. It does not exclude other siblings but provides a clear context for usage.

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

• normalize_broker_csvA
  4.2/5.0
  Behavior4/5

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

  Discloses key behaviors: maps common column aliases, keeps only buy/sell rows (including DRIP as buys), cleans number formats, and returns both 'transactions' and 'skipped' lists with reasons. No annotations, so description bears full burden; adequately transparent.

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

  Conciseness4/5

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

  Well-structured with front-loaded purpose followed by details. Each sentence adds value, though slightly verbose. Could be trimmed without losing meaning.

  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 two parameters, no output schema, and sibling tools that are downstream, the description fully explains the output format (transactions, skipped list) and integration flow. No gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so description must add value. It explains that 'csv_path' accepts CSV/TSV/JSON file paths and 'rows' can be inline array, and mentions common column aliases. However, it does not detail the exact structure required for each row object, leaving some ambiguity.

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

  Purpose5/5

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

  Clearly specifies verb 'normalize' and resource 'broker CSV', explaining it converts raw exports into transactions for other tools. Distinguishes from siblings by describing its role as a preprocessing step.

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

  Usage Guidelines4/5

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

  Explicitly states when to use (raw broker CSV with mismatched headers) and directs output to downstream tools (calculate_acb, capital_gains_report, unrealized_gains). Lacks explicit when-not-to-use or alternatives, but context is clear.

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

• unrealized_gainsA
  4.6/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It thoroughly explains input formats, handling of missing prices (listed in missing_prices and excluded), and output structure. It does not mention side effects, but for a compute-only tool, this is adequate.

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

  Conciseness5/5

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

  The description is about 150 words, well-organized into purpose/output in first paragraph and parameter details in second. Every sentence adds value, no fluff.

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

  Completeness5/5

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

  Given 3 parameters, nested objects, and no output schema, the description explains inputs and outputs sufficiently, including special cases like missing prices. It mentions the output structure clearly.

  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 0%, but the description fully details all parameters: csv_path (optional path), transactions (array of objects with all fields), and market_prices (required object with number or {price, fx_rate} per security). This compensates completely.

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

  Purpose5/5

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

  The description clearly states it computes unrealized gains using ACB against market prices, listing outputs per security and totals. It implicitly distinguishes from siblings like calculate_acb (which computes ACB without market prices) and capital_gains_report (realized gains).

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

  Usage Guidelines4/5

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

  The description explains what the tool does and how to format inputs, but does not explicitly state when to use it versus alternatives like capital_gains_report for realized gains. It provides clear context but no exclusions.

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

• check_superficial_lossesA
  4.8/5.0
  Behavior5/5

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

  Fully discloses the tool's behavior: scans dispositions, identifies losses under the 30-day rule, and reports security, date, denied amount, and allowable portion. Also explains that denied amount is added to ACB of substitute shares. No annotations provided, so the description carries the full burden and does so excellently.

  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?

  Front-loaded with purpose in the first sentence. Structured logically: rule explanation, output description, then input format. Every sentence adds value; no redundancy. Efficient and clear.

  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 no output schema and no annotations, the description provides everything needed: input format, behavior logic, and output fields. The complexity of the CRA superficial loss rule is well-explained, making the tool fully understandable for an AI agent.

  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 has 0% description coverage, but the description fully compensates by explaining both parameters: csv_path for file input and transactions for inline data. It also defines the transaction object structure in detail (date, action, security, shares, price, optional fields), adding significant meaning beyond parameter names.

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

  Purpose5/5

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

  Clearly states it flags superficial losses under the CRA 30-day rule. Uses specific verb 'Flag' and resource 'superficial losses'. Distinguishes from sibling tools like acb_summary and calculate_acb, which handle general ACB or capital gains, not superficial loss detection.

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

  Usage Guidelines4/5

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

  Describes what the tool does in detail, including the rule it applies and the input formats. Provides clear context but does not explicitly state when to use versus alternatives or when not to use. However, the purpose is distinct from siblings, so the guidance is adequate.

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

• schedule3_summaryA
  4.8/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses key behaviors: applies the superficial-loss rule, provides per-column totals, and includes a caution that it's a calculation aid. However, it does not explicitly state whether the tool is read-only or describe error handling, but the specifics given are substantial.

  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 well-structured and information-dense without fluff. Each sentence adds value: output shape, aggregation details, sibling distinction, input options, transaction schema, and a disclaimer. It is front-loaded with the core purpose and then elaborates.

  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, the description is complete. It covers what the tool does, how it behaves (superficial-loss rule), what inputs are accepted, what outputs look like (columns and totals), and includes a necessary legal caution. No critical aspect 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?

  The schema provides no parameter descriptions, but the description compensates fully. It explains tax_year as an optional filter, csv_path versus transactions as alternative inputs, and details the transaction object structure with all fields and examples (e.g., fx_rate 1.35 for USD).

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

  Purpose5/5

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

  The description clearly states the tool's purpose: it aggregates dispositions into one line per security for Schedule 3. It uses a specific verb ('aggregates') and identifies the resource ('dispositions'), and distinguishes itself from the sibling capital_gains_report.

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

  Usage Guidelines5/5

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

  It explicitly says when to use this tool versus the alternative: 'capital_gains_report lists every individual disposition; use this tool when the user wants the aggregated filing lines instead.' It also explains that it accepts inline transactions or a csv_path, giving clear input options.

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