Server Quality Checklist

Tool Scores

• analyze_correlationB
  3.3/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. It describes outputs but discloses no behavioral traits such as read-only nature, rate limits, authentication needs, or error handling. Payment is mentioned but not behavioral.

  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?

  Two sentences efficient in stating purpose and outputs. Payment line is unconventional but informative. Could be slightly more structured, but it's concise and front-loaded.

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

  Completeness4/5

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

  No output schema, so description explains return values (correlation matrix, avg pairwise correlation, diversification ratio, asset-class pair correlations). It covers core outputs and the payment caveat. Could clarify how data is fetched (schema covers this), but sufficient for basic understanding.

  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 83%, with detailed parameter descriptions in the schema. The description adds no new parameter meaning beyond summarizing outputs. Baseline of 3 applies as schema does most of the work.

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

  Purpose5/5

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

  Description clearly states it returns a correlation matrix and diversification ratio, specifying exact outputs (N×N matrix, avg pairwise correlation, DR>1 benefit, asset-class pair correlations). Distinguishes from sibling tools like analyze_diversification by focusing on correlation-specific 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 explicit guidance on when to use vs. alternatives like analyze_factors or analyze_compare. Does not mention prerequisites or scenarios where this tool is preferred. The payment mention hints at cost but does not guide selection.

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

• analyze_regimeA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description bears full responsibility. It lists the outputs (regime, confidence, signals, portfolio-fit score, suggested adjustments) and cost, but it does not disclose data sources, processing details, or any side effects. The behavioral transparency is adequate but not thorough.

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

  Conciseness4/5

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

  The description is concise with four sentences, front-loading the purpose and outputs. It is clear and free of extraneous information, though it could be slightly restructured for better readability.

  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 tool with 6 parameters, nested objects, and no output schema, the description explains the returned items and cost but lacks details on interpretation or examples. It is moderately complete given the schema's good param descriptions.

  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 high (83%), so the schema already documents most parameters. The description adds value by noting that marketIndicators improve confidence, but it does not provide additional meaning beyond the schema for other 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 it performs market regime detection from macro indicators and portfolio signals, listing the possible regimes and the outputs. It distinguishes itself from sibling tools like analyze_correlation or analyze_risk by focusing specifically on regime detection.

  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 advises providing marketIndicators for higher confidence and mentions the cost, but it does not explicitly state when to use this tool versus alternatives or when not to use it. It lacks comparison to sibling tools.

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

• analyze_factorsA
  3.8/5.0
  Behavior4/5

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

  The description discloses a behavioral trait: the tool charges $0.02 USDC. It also explains auto-fetching of live data for known tickers. However, it does not specify whether the operation is read-only or any side effects, though analysis tools are typically read-only. With no annotations, the description provides useful context but could be more thorough.

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

  Conciseness4/5

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

  The description is a single sentence that lists key factors and the payment. It is fairly concise and front-loaded with the main purpose. However, it could benefit from clearer structure, such as bullet points for factors.

  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 complex with many parameters, a nested object, and no output schema. The description does not explain what the tool returns (e.g., a report or scores). While it mentions the factors analyzed, missing output details reduces completeness. The payment note and auto-fetching help but are not enough.

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

  Parameters3/5

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

  The input schema covers 83% of parameters with descriptions. The tool description does not add significant new meaning beyond what the schema already provides; it only mentions the auto-fetching behavior for holdings. Since schema coverage is high, a score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool performs factor exposure analysis, listing specific factors (beta, asset-class contributions, region/sector breakdown, duration, dividend yield, currency exposure). This distinguishes it from siblings like analyze_correlation or analyze_risk, which focus on different 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 usage for factor analysis but provides no explicit guidance on when to use this tool versus alternatives like analyze_risk or analyze_diversification. There is no mention of when not to use it or prerequisite conditions.

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

• analyze_reportA
  3.8/5.0
  Behavior3/5

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

  The description mentions cost and includes 8 modules, but lacks disclosure of side effects, authentication needs, rate limits, or error behaviors. Without annotations, more detail on behavioral traits is needed.

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

  Conciseness4/5

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

  The description is two sentences, concise and front-loaded with the core functionality and list of modules. 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?

  Given the complexity (6 params, nested objects), the description provides a good overview of the output (executive summary) but does not explain score interpretation, error handling, or constraints beyond cost.

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

  Parameters3/5

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

  Schema coverage is 83%, so most parameters are already described. The tool description does not add significant value beyond what the schema provides.

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

  Purpose5/5

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

  The description clearly states the tool runs all 8 analysis modules in one call and provides an executive summary with score and grade. It distinguishes itself from sibling tools that only offer individual modules.

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

  Usage Guidelines4/5

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

  It implies usage contexts by labeling itself as the 'most cost-effective option for comprehensive analysis,' but does not explicitly state when to avoid it or when to use siblings instead.

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

• analyze_varA
  3.8/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 live data fetching from CoinGecko, auto-population for known tickers, and a payment cost of $0.02 USDC. However, it omits potential side-effects like error handling, rate limits, or required permissions, preventing a perfect score.

  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 (3 sentences) and front-loaded with the core purpose. Every sentence adds value, including payment details, with no redundancy or filler. Excellent structure for quick comprehension.

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

  Completeness4/5

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

  For a moderately complex tool with no output schema, the description covers key outputs (VaR/CVaR, worst-case loss, interpretation) and essential behavior (auto-fetch). It misses details on parameter interactions (e.g., profile, rebalanceMethod), but overall provides sufficient context for basic usage.

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

  Parameters3/5

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

  Schema coverage is high (83%), so the baseline is 3. The description adds context about auto-fetching for known tickers, which is already in the schema. It doesn't add significant new meaning beyond what the input schema provides, resulting in a neutral score.

  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 VaR and CVaR at specific confidence levels, auto-fetches data for crypto tickers, and returns key metrics including daily/annual values and interpretation. This distinguishes it from sibling tools like analyze_risk or analyze_stress which cover broader or different risk aspects.

  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 prerequisites, exclusions, or contextual suggestions, leaving the agent without decision support for tool selection.

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

• analyze_compareA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It discloses the cost ($0.05 USDC) and implies a read-only operation (no mention of modification). However, it lacks explicit statement about non-destructive nature or any side effects. Score is adequate but not exceptional.

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

  Conciseness5/5

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

  The description is three sentences covering purpose, return value, and use cases/cost. Very concise with no redundant information. Front-loaded with key points.

  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 (nested portfolio objects, 9 metrics, cost), the description provides a good summary. It lacks details on parameter structure, but the comprehensive input schema covers that. The output (winner per metric and delta) is stated. Could mention required fields but schema already does.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline is 3. The description adds no parameter-specific details beyond what the schema already provides. It focuses on the output (metrics and delta values) rather than input 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 performs a side-by-side comparison of two portfolios across 9 specific metrics, matching the tool name 'analyze_compare'. It also distinguishes from sibling tools (correlation, diversification, etc.) by focusing on direct comparison.

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

  Usage Guidelines4/5

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

  The description provides concrete use cases: 'A/B testing portfolio strategies' and 'comparing current vs. rebalanced allocation'. However, it does not explicitly mention when not to use this tool or suggest alternatives, but the context is clear.

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

• analyze_diversificationA
  4/5.0
  Behavior4/5

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

  With no annotations, the description bears the full burden. It discloses the key behavioral aspects: returns specific outputs, auto-fetches data for known tickers, and requires a payment. No contradictory or missing critical disclosures.

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

  Conciseness5/5

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

  Three sentences, no wasted words. Key information (HHI analysis, outputs) is front-loaded, followed by payment detail. Efficient and well-structured.

  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 (6 parameters, nested objects, no output schema), the description covers the main outputs and payment. It lacks details on interpreting results (e.g., grade meanings) but is adequate for a well-named tool with high schema coverage.

  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 high (83%), so baseline is 3. The description adds value with the payment note and auto-fetch hint but does not elaborate on each parameter beyond what the schema provides.

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

  Purpose5/5

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

  The description clearly states it performs portfolio diversification analysis using HHI, listing specific outputs like concentration grade, effective number of assets, and breakdowns. It distinguishes itself from sibling tools (e.g., analyze_risk, analyze_correlation) by focusing on diversification.

  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 diversification analysis but does not explicitly state when to use it versus alternatives or provide exclusions. The sibling tools cover other aspects, but no direct guidance is given.

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

• analyze_rebalanceA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description must cover behavioral traits. It discloses auto-enrichment of tickers and a payment of $0.02 USDC, but does not explicitly state that the operation is non-destructive or mention data freshness, rate limits, or side effects. Adequate but not comprehensive.

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

  Conciseness5/5

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

  The description is extremely concise—three sentences capturing purpose, methods, output, and special features. No redundant or unnecessary information. Front-loaded with the core action.

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

  Completeness4/5

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

  Given the complexity (nested objects, multiple optional parameters) and no output schema, the description covers the essential output fields (target weight, current weight, action, delta) and the auto-enrichment feature. It could mention how market indicators affect results, but overall it's sufficient for an agent to use the tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 83%, so the schema already documents parameters well. The description adds context about live data and payment but does not enhance parameter meaning beyond what the schema provides. Baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool provides portfolio rebalancing recommendations using live market data, lists four distinct methods, and describes the output structure. This is highly specific and easily distinguishes it from sibling tools like analyze_correlation or analyze_risk.

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

  Usage Guidelines4/5

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

  The description specifies four rebalancing methods and notes that known crypto tickers are auto-enriched, giving context for when to use the tool. It doesn't explicitly state when not to use it or mention alternatives, but the sibling names make the choice clear. Lacks explicit exclusions.

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

• analyze_riskA
  4.4/5.0
  Behavior4/5

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

  No annotations exist, so the description must itself disclose behavior. It covers key aspects: auto-fetches live data, computes specific ratios, and notes payment ($0.01 USDC, ~500ms). No contradictions, though it could mention potential side effects or auth needs.

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

  Conciseness5/5

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

  The description is concise (6 sentences), well-structured, and front-loaded with the core purpose. Every sentence adds essential information without redundancy.

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

  Completeness4/5

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

  For a tool with nested objects, 6 parameters, and no output schema, the description covers inputs, required vs optional, auto-fetched fields, return values (ratios and risk scores), and payment. Missing explicit output structure details but adequate overall.

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

  Parameters4/5

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

  Schema coverage is 83%, high, so baseline 3. The description adds value by clarifying that for known tickers only asset and weight are required, while others are auto-fetched. This goes beyond the schema's distinction of optional vs required.

  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: 'Crypto portfolio risk profiling using live CoinGecko market data.' It specifies the verb (analyze/profiling), resource (portfolio risk), and distinguishes from siblings (e.g., analyze_factors, analyze_regime) by focusing on risk ratios and per-asset scores.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use: for portfolio risk profiling with known tickers, auto-fetching data. It explains inputs needed (asset, weight) but does not explicitly exclude when not to use or mention sibling tools as alternatives.

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

• analyze_stressA
  4.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 the full burden. It discloses that real portfolio volatility data is used, scenarios are sector-aware, and payment is required. It does not cover error handling, data freshness, or authentication, but for a stress test tool, the behavioral context is robust.

  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, well-structured paragraph that front-loads the core function. Every sentence adds information (scenarios, data source, output, payment) without redundancy.

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

  Completeness4/5

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

  Given the tool's complexity (6 parameters, nested objects), the description explains the scenarios and output format adequately. It could elaborate on the return structure (e.g., data types) since no output schema is provided, but it gives sufficient context for an agent.

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

  Parameters4/5

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

  Schema description coverage is 83%, so the schema already documents parameters well. The description adds value by listing the 10 scenarios and noting that known tickers auto-fetch data, which aids parameter understanding 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 it performs stress testing across 10 named macro scenarios with specific impacts, and specifies the output (P&L per scenario with worst/best asset). This distinguishes it from sibling tools like analyze_risk (general risk) or analyze_regime (market regime 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?

  The description provides context on when to use (portfolio stress testing) but does not explicitly state when not to use or compare to alternatives. The detailed scenario list and output description imply its purpose, yet exclusion criteria are absent.

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