Server Quality Checklist

Tool Scores

• trade_get_indicatorsA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds details on the read-only behavior ('computes nothing on live capital') and outlines the exact return schema and error handling. It does not mention rate limits or authentication, but these are likely system-level.

  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-organized with a clear summary, structured Args/Returns, examples, and a usage note. It is a bit lengthy but every section adds value. The return schema could be omitted if the output schema were visible, but the text version is helpful for quick reference.

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

  Completeness5/5

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

  Given the tool's simplicity (single symbol, read-only) and the wealth of annotations and input schema, the description covers all necessary aspects: purpose, input parameters with defaults, output format and schema, error handling, and usage examples. No obvious gaps remain.

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

  Parameters4/5

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

  The description reiterates parameter meanings (symbol, response_format) with examples like case-insensitivity and default format. Given that the input schema already contains descriptions and coverage is 0%, the description compensates adequately by adding practical context, though it does not introduce new constraints 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 retrieves the latest technical indicators for a single NSE symbol, with specific verb 'Get' and resource 'technical indicators'. It distinguishes from siblings (backtesting, portfolio, risk) by focusing on real-time indicator snapshots.

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

  Usage Guidelines4/5

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

  The description explicitly advises not to use the tool for placing trades, reinforcing its read-only nature. Examples illustrate appropriate queries, and the sibling tools cover different domains, making usage context clear. However, no direct comparison with specific sibling tools is provided.

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

• trade_get_portfolioA
  4.5/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint, idempotentHint, and destructiveHint false, which align with the description's 'Read-only snapshot' statement. The description further clarifies output structure (markdown/json) and error messages, adding value beyond annotations.

  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?

  Well-structured with separate sections for description, arguments, returns, and examples. Every sentence adds value, and the front-loaded purpose sentence immediately communicates the tool's function.

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

  Completeness5/5

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

  Covers all relevant aspects: purpose, single parameter, output schema in detail, error behavior, and usage examples. With no missing elements, it fully informs an AI agent for correct invocation.

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

  Parameters4/5

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

  The single parameter (response_format) is explained in the description with defaults and examples, complementing the schema's description. Although schema description coverage is listed as 0%, the actual schema includes descriptions, and the tool description enhances understanding.

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

  Purpose5/5

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

  The description explicitly states it retrieves the current portfolio with holdings, cash, equity, and unrealized P&L. It clearly distinguishes from sibling tools like trade_get_backtest or trade_get_indicators by focusing on the live portfolio snapshot.

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

  Usage Guidelines4/5

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

  Provides concrete examples ('How is my portfolio doing?', 'Give me my positions as JSON') that illustrate typical usage. Does not explicitly mention when not to use it, but the examples sufficiently convey appropriate context.

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

• trade_list_backtestsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds valuable behavioral context: pagination behavior (limit/offset), response format options (markdown/json), and error format. This goes beyond what annotations provide.

  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?

  Description is concise and well-structured: one-line purpose, then details, args, returns, and examples. Every sentence adds value, with no redundancy or fluff.

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

  Completeness5/5

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

  Given the tool's simplicity (3 parameters, output schema provided), the description covers all necessary aspects: purpose, usage guidelines, parameter details, return format, error handling, and examples. It is fully complete for an AI agent to use correctly.

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

  Parameters4/5

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

  Schema descriptions exist for each parameter, but the description adds default values (limit=10, offset=0, response_format='markdown') and explains the output format schema. The 'Args' section re-inforces parameter meaning, and the 'Returns' section details the JSON structure, adding significant value beyond the schema.

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

  Purpose5/5

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

  The description clearly states 'List available backtest runs, most useful for discovering run IDs' and distinguishes from sibling 'trade_get_backtest' by suggesting pairing. The verb 'list' is specific and the resource 'backtest runs' is well-defined.

  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 to pair with 'trade_get_backtest' for detailed metrics and gives concrete examples (default page vs offset=10). It tells the agent when to use pagination, though it doesn't explicitly state when not to use this tool vs alternatives.

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

• trade_get_portfolio_riskA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true. The description adds behavioral context: it discloses the tool is read-only, lists the metrics returned, describes the output format and failure response. No contradictions.

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

  Conciseness5/5

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

  The description is well-structured with first sentence, bullet points, Args/Returns sections, and examples. Every sentence provides useful information without redundancy.

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

  Completeness5/5

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

  The description covers the purpose, metrics, read-only nature, parameter details, output schema, failure handling, and usage examples. It is fully complete given the tool's complexity and the presence of an output schema.

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

  Parameters4/5

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

  The schema includes descriptions for params and response_format. The description adds value by explaining the default output format ('markdown') and the structure of the JSON response. It clarifies what the single parameter does 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 gets aggregate risk metrics for the current portfolio and lists specific metrics (concentration, beta, VaR, etc.). It distinguishes from sibling tools like trade_get_backtest and trade_get_portfolio by focusing on 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 provides example questions that trigger the tool, but does not explicitly state when to avoid it or mention alternatives. The context and sibling names help, but explicit guidance is missing.

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

• trade_get_backtestA
  5/5.0
  Behavior5/5

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

  The description discloses key behavioral traits beyond annotations: it explains the output format (markdown or JSON based on response_format), returns a detailed JSON schema, and describes error behavior (returns 'Error: <actionable message>' for failure). Annotations already indicate read-only, non-destructive, idempotent, which is consistent. No contradictions.

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

  Conciseness5/5

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

  The description is well-structured and concise: it starts with the purpose, then provides usage steps, parameter details, return schema, and examples. Every sentence adds value without redundancy. It is front-loaded with the most important information.

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

  Completeness5/5

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

  Given the tool's complexity (single parameter with nested options), schema coverage of 0%, and presence of output schema in description, the description is complete. It covers what the tool does, how to use it, input parameters, output format and schema, error handling, and examples. No gaps for the agent to infer.

  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?

  Despite the schema description coverage being listed as 0%, the description thoroughly explains both parameters: run_id ('Run identifier from trade_list_backtests') and response_format ('markdown' default) with context and examples. It adds meaning beyond the schema's property descriptions by showing usage and default behavior.

  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: 'Get full metrics for a single backtest run by its ID.' It uses a specific verb ('Get') and resource ('backtest run by ID'), and distinguishes from sibling tools like trade_list_backtests by advising to use that tool first to obtain a valid run_id.

  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?

  Explicit usage guidance is provided: 'Use trade_list_backtests first to find a valid run_id, then call this for the detailed performance breakdown.' It also warns against guessing run IDs and tells when not to use (e.g., don't use for listing). This clearly differentiates from sibling tools.

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