Server Quality Checklist

Tool Scores

• moneycontrol_get_indexA
  3.8/5.0
  Behavior4/5

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

  The description discloses the return shape in JSON mode and error behavior ('Returns "Error: ..." on failure'). Annotations already declare readOnlyHint and idempotentHint; the description adds context about index resolution and output details, 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.

  Conciseness3/5

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

  The description is structured with paragraphs for purpose, fast-path names, args, and returns. It is somewhat verbose but clear and front-loaded. Some repetition of schema details could be trimmed.

  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 tool is simple (get index level) and the description covers usage, output shape, and error handling. Annotations provide safety guarantees. The description is mostly complete, though it could note that the output may vary for unrecognized indices.

  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 already contains descriptions for both parameters (index and response_format). The description restates these with similar wording, adding little new meaning. Given schema coverage is effectively high, a baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool retrieves current level and movement for a market index, listing built-in fast-path names. It is specific but does not explicitly differentiate from sibling tools like moneycontrol_get_quote or moneycontrol_get_fundamentals.

  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 the tool by listing built-in index names and mentioning automatic resolution via Moneycontrol search. It does not explicitly state when not to use or provide alternatives, but the guidance is clear.

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

• moneycontrol_get_historyA
  3.9/5.0
  Behavior4/5

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

  Annotations indicate read-only, non-destructive, idempotent behavior. The description adds details on error messages ('Error: ...' on failure), ordering (oldest to newest), and output structure, providing useful behavioral context 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.

  Conciseness4/5

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

  The description is structured with Args and Returns sections, making it easy to scan. It is slightly verbose but every sentence adds context. No redundancy with the schema.

  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 has no output schema in the provided context, the description compensates by specifying the return format and example. Error handling is mentioned. For a data retrieval tool, this is sufficiently complete.

  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 already describes each parameter (symbol, interval, count, response_format) with details. The description adds narrative examples and clarifies default values, but the schema already covers the essentials, so the description adds moderate value.

  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 retrieves historical OHLCV price bars for NSE stocks, specifying intervals and output format. It distinguishes from sibling tools by focusing on price history versus news, fundamentals, etc.

  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 does not explicitly state when to use this tool over alternatives or provide exclusion criteria. However, the tool's name and purpose imply it is for historical price data, which differentiates it from siblings.

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

• moneycontrol_fii_diiA
  4.1/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds value by explaining the meaning of positive and negative values, the structure of the return data, segments, and error handling. 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, starting with a clear purpose, then elaborating on segments, parameter details, and return format. Every sentence adds necessary information, and there is 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 comprehensive input schema and the detailed description of the return format (including JSON structure with fields and explanations), the tool is fully documented. It covers purpose, parameters, behavior, segments, units, and error handling.

  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 has detailed descriptions for all parameters (days, segment, response_format), covering 100% of parameter semantics. The description repeats these (e.g., 'days (int): Recent trading days to return (1-60, default 10)') with minor additions like 'The cash market is the headline figure.' The added value is minimal beyond the schema, so baseline 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 'Get FII (foreign) and DII (domestic) institutional net activity, in INR crore.' This is a specific verb-resource combination. While it does not explicitly differentiate from siblings, the focus on institutional activity and the mention of cash and F&O segments make its purpose unique among the listed siblings.

  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 provides context (e.g., 'The cash market is the headline figure most analysts watch') but does not explicitly state when to use this tool versus alternatives or when not to use it. There is no mention of sibling tools or conditions for choosing this tool.

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

• moneycontrol_get_fundamentalsA
  4.2/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds error behavior ('Returns Error: ... on failure') and a detailed output shape, which provides context 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?

  The description is well-structured with clear sections: purpose, coverage, Args, Returns. It is concise without superfluous text, front-loading the main purpose.

  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 presence of annotations, output shape in description, and sibling context, the description is fairly complete. It covers input, output format, error cases, and parameter details. Minor gap: could explicitly contrast with siblings, but not critical.

  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?

  Although schema description coverage is 0% by metric, the description includes an 'Args' section that explains the purpose of each parameter (symbol, exchange, response_format) and provides default values and constraints, adding 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 gets valuation ratios, per-share metrics, sector and trailing returns for a stock. It specifies 'fundamentals' which distinguishes it from sibling tools like moneycontrol_get_history or moneycontrol_get_technicals.

  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 stock fundamentals but does not explicitly state when to use this tool versus other sibling tools like moneycontrol_get_quote or moneycontrol_get_technicals. No 'when not to use' or alternatives are mentioned.

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

• moneycontrol_get_quoteA
  4.2/5.0
  Behavior3/5

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

  Annotations already set readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the error handling behavior ('Returns Error: ...') and the return shape, but this is minimal additional behavioral context 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.

  Conciseness4/5

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

  The description is well-structured with sections for Args and Returns, using bullet points. It front-loads the purpose sentence. While it is somewhat lengthy, it earns its space by providing essential details 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?

  Given the tool's simplicity and the presence of a detailed output schema in the description, all necessary information is covered: purpose, parameters, error handling, and return format. No 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?

  Schema coverage is 0% per context, but the description compensates by explaining each parameter: symbol (sc_id or name), exchange (nse/bse), response_format (markdown/json). It adds nuances like 'preferred' for sc_id, which is helpful beyond the schema's basic types.

  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 'Get a live equity quote' and lists the data points (price, change, OHLC, etc.). It clearly distinguishes from sibling tools like moneycontrol_get_fundamentals and moneycontrol_get_history, which serve different purposes.

  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 instructions on how to use the parameters (symbol as sc_id or name, exchange defaults to nse, response_format options). However, it does not explicitly state when to use this tool versus alternatives, though the context of siblings makes it somewhat implicit.

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

• moneycontrol_searchA
  4.4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description adds value by explaining the return format, the meaning of sc_id, and the behavior on no matches. 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.

  Conciseness4/5

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

  The description is well-structured with Args and Returns sections and is front-loaded with the core purpose. Every sentence adds value, though it is slightly longer than strictly necessary.

  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 is complete for a search tool: it explains inputs, outputs (including example return), and how the result is used downstream. The presence of an output schema (not shown) further reduces the need for description, but the description already covers it.

  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 0% schema coverage, the description thoroughly documents all four parameters in the Args section, adding context like default values (kind defaults to 'stock', limit defaults to 10) and the purpose of sc_id for sibling tools. This more than compensates for schema gaps.

  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 searches Moneycontrol for a stock or index and resolves identifiers, specifically mentioning it's the first step to obtain sc_id for other tools. It distinguishes from siblings by positioning itself as the initial lookup tool.

  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 'Use this FIRST' and explains why (to obtain sc_id or index name). It does not mention when not to use it, but the context is clear and sufficient for typical use cases.

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

• moneycontrol_get_technicalsA
  4.6/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context: returns OHLC and pivot tables, supports two output formats ('markdown' or 'json'), and returns error messages ('Error: ...'). It does not contradict annotations. It discloses important behavior beyond what annotations provide, but could include more about potential rate limits or auth.

  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 compact, uses bullet points for parameters, and clearly separates Args and Returns. Every sentence adds value without redundancy. It is front-loaded with the core purpose.

  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 that an output schema exists (context signal indicates true) and annotations cover safety, the description provides sufficient context: it specifies the return type (str), describes the content (OHLC and pivot tables), and explains error handling. No critical information 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?

  Despite the context signal indicating 0% schema description coverage, the description thoroughly explains all parameters: symbol (sc_id or company name), exchange (nse default or bse), period (D, W, M), and response_format (markdown or json). It adds value by clarifying that sc_id is preferred and noting defaults. This fully compensates for the lack of schema coverage.

  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 'Get pivot points and support/resistance levels for a stock.' This is a specific verb ('Get') and resource ('pivot points and support/resistance levels'), and it distinguishes the tool from siblings like moneycontrol_get_fundamentals (which retrieves financial data) and moneycontrol_get_quote (which gets current price).

  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 explicit guidance on the input parameters (symbol, exchange, period, response_format) and return format. It implies when to use this tool (for technical analysis data) but does not explicitly mention when not to use it or compare with alternatives. However, it covers the context well.

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

• moneycontrol_get_newsA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds context on return format (markdown or json), the structure of returned articles, and the empty response message, enhancing transparency without contradiction.

  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 (three paragraphs) with clear sections (Args and Returns). It is front-loaded with the main purpose and uses bullet-like structure to list parameters, making it easy to scan.

  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 four parameters, detailed schema descriptions, and an output schema, the description covers all essential aspects: query vs category behavior, limit range, response format, and return format. It is complete for an 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?

  The description explains the meaning and interaction of 'query' and 'category', and mentions 'limit' and 'response_format'. Although the input schema provides detailed descriptions for nested parameters, the tool description adds practical usage context and the relationship between 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 'Get current Moneycontrol news headlines for a topic, stock, or category.' It uses a specific verb and resource, and the examples distinguish it from sibling tools like moneycontrol_get_quote or moneycontrol_search.

  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 when to use 'query' vs 'category' and the default category. It provides clear internal usage context but does not explicitly tell when to avoid this tool in favor of siblings, though the purpose is distinct enough.

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