Server Quality Checklist

Tool Scores

• ecourts_get_caseA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds value by detailing the comprehensive return fields (case status, parties, orders, etc.) and explaining how to discover order filenames, which goes beyond the 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 concise: three sentences that quickly convey the main purpose, return content, and usage guidance. No extraneous information is present, earning full marks.

  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 complexity of Indian court cases and the absence of an output schema, the description provides a thorough list of return fields and valuable guidance on using the tool in conjunction with sibling tools. This fully compensates for any missing structured information.

  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 schema already provides a 100% description coverage for the single parameter 'cnr', including an example. The description repeats the example but adds no new semantic detail beyond what the schema offers, so 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.

  Purpose5/5

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

  The description clearly states the action 'Retrieve comprehensive details' and the resource 'Indian court case by CNR'. It differentiates from siblings by explicitly noting that this tool should be used first to discover order filenames before calling ecourts_get_order or ecourts_get_order_ai.

  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 gives explicit guidance on when to use this tool: use it first to discover order filenames. However, it does not explicitly state when not to use it or mention alternatives beyond the sibling tools, leaving some room for improvement.

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

• ecourts_get_causelist_datesA
  4.4/5.0
  Behavior4/5

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

  Adds behavioral traits beyond annotations: 'Free endpoint (no credit charge, authentication required)' and 'At least one parameter is required' (a constraint not fully captured in schema). Annotations already declare readOnly, idempotent, and non-destructive, so the description complements 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?

  Three sentences, no wasted words. Purpose stated first, then usage constraints, then practical guidance. Extremely efficient for the information conveyed.

  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 appropriately explains the return value (dates) and its intended use. It also mentions authentication and free credit usage. It adequately covers the necessary context for a simple lookup tool.

  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 100% with descriptions like 'State code, e.g. DL'. The description adds meaning by explaining that at least one parameter is required and that the output dates are intended for use with ecourts_search_causelist, enhancing the understanding of parameter purpose.

  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?

  Clear verb-resource combination: 'Get dates for which cause list data is available'. The description explicitly states filtering by location, and the tool's purpose is distinct from sibling tools (ecourts_search_cases, ecourts_get_case), which deal with case data.

  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 explicit context: 'Use the returned dates with ecourts_search_causelist to avoid empty searches.' Also states the prerequisite that at least one parameter is required. However, it does not contrast usage with siblings or specify when not 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.

• ecourts_search_casesA
  4.4/5.0
  Behavior4/5

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

  Annotations indicate read-only, open-world, idempotent, non-destructive. Description adds details on parameter constraints (max page size, date format), facet counts, and return fields, complementing the safety profile 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 well-organized with bullet points, clear category headers, and no extraneous text. It efficiently conveys all necessary information for a complex tool.

  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 (32 parameters, no output schema), the description covers all parameter groups, constraints, and typical usage. It lacks explicit pagination or error details but is sufficient for agent 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?

  Schema has 100% description coverage. The description groups parameters into logical categories (text, filters, years, dates, controls), adding semantic structure that aids understanding beyond individual schema descriptions.

  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 for Indian court cases with various criteria, listing supported query types and return fields. It distinguishes from sibling tools (causelist dates, specific case retrieval) by focusing on search and filtering.

  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 requires at least one search term or filter, and categorizes parameters into text, filters, dates, etc. It does not explicitly compare to alternatives but the purpose is clear relative to sibling tool names.

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