Server Quality Checklist

Tool Scores

• get_holdings_summaryB
  3.3/5.0
  Behavior1/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Fetch holdings summary.' It discloses no details about authentication requirements, data scope, return structure, or side effects, leaving the agent without essential behavioral context.

  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, compact sentence with no filler. 'Fetch holdings summary' is direct, and 'via DhanHQ SDK' adds useful implementation context without verbosity.

  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 simple (no parameters) and has an output schema, but the description is minimal. It does not explain prerequisites, response contents, or typical use cases, making it the bare minimum viable. Annotations would have compensated, but none are provided.

  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 tool has no parameters, so the schema fully covers parameter semantics (coverage 100%). The description correctly adds nothing about parameters, and the baseline for zero-parameter tools is 4.

  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 a specific action ('Fetch') and a specific resource ('holdings summary'). This distinguishes it from the sibling tools which operate on orders, trade history, and token renewal, making the purpose unambiguous.

  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 the sibling alternatives. It does not mention conditions, exclusions, or refer to other tools, so an agent must infer usage solely from the tool name.

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

• get_all_ordersA
  3.8/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 of behavioral disclosure. It does disclose the return type (a list of orders with fields like ID, status, quantity, price), which is useful. However, it does not explicitly state read-only behavior, authentication needs, or potential limits such as pagination, so it is only partially transparent.

  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, with two sentences that front-load the primary action and follow with a useful detail about the return content. There is no unnecessary repetition or filler.

  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 simplicity (zero parameters) and the presence of an output schema (which covers return structure), the description adequately conveys the core function. It could mention that it returns all orders without filtering, or note potential pagination, but for this tool it is reasonably complete.

  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 input schema has zero parameters, so the baseline of 4 applies. The description correctly has no parameter information to add, and the schema is already 100% covered by virtue of having no required or optional 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 uses a specific verb ('Fetch') and a specific resource ('all orders from DhanHQ account'), clearly stating the tool's scope. It distinguishes itself from siblings like get_trade_history (focused on trade history) and get_holdings_summary (holdings summary), making the purpose unambiguous.

  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 such as get_trade_history or get_holdings_summary. There are no exclusions, prerequisites, or conditions mentioned, leaving the agent to infer usage context.

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

• get_trade_historyA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description discloses return details (trade ID, order ID, quantity, price, time, settlement status) and implies a read-only operation via 'Fetch.' However, it lacks explicit mention of auth requirements or pagination behavior.

  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 a concise purpose sentence, parameter explanations, and return details. Every sentence adds value without unnecessary fluff.

  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 simple tool with an output schema, the description covers purpose, parameters, and returns sufficiently. It omits usage alternatives and auth context, but the tool's simplicity keeps it adequate.

  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 descriptions (0% coverage) beyond string types, but the description fully compensates by specifying 'YYYY-MM-DD' format and examples for both from_date and to_date.

  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 'Fetch trade history within a date range,' identifying a specific verb, resource, and scope. It naturally distinguishes from sibling tools like get_all_orders (orders) and get_holdings_summary (holdings).

  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 a clear context for use (trade history in a date range) but does not explicitly mention alternatives or when not to use this tool. Sibling tools exist but are not referenced.

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

• renew_access_tokenA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden. It clearly discloses that the tool expires the current token (destructive effect) and provides a new token, plus instructs to update environment variables. This goes beyond typical descriptions.

  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, each serving a distinct purpose: action, effect, and limitation/instruction. No fluff; the main action is front-loaded.

  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 purpose, behavioral effect, return value, and a key restriction. With zero params and an output schema present, it is fully sufficient for an AI agent to invoke the tool 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?

  There are no parameters, so the baseline is 4. The description does not need to add parameter details, and it correctly omits them.

  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 uses a specific verb 'renew' with a clear resource 'DhanHQ access token' and defines the exact duration (24 hours). It also implicitly distinguishes itself from the sibling tools, which are data retrieval operations.

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

  Usage Guidelines5/5

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

  The note 'Only works with tokens generated from Dhan Web' explicitly states a when-not-to-use condition. The context of token renewal for a fixed expiry window gives a clear reason to use the tool.

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