Server Quality Checklist

Tool Scores

• si_comp_get_decisionB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description must fully disclose behavioral traits. However, it only states the core function and does not mention permissions, error handling, response format, or any side effects. This is insufficient for safe and effective agent decision-making.

  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, clear sentence with an example. It is front-loaded and easy to parse. While it could benefit from more detail, it remains appropriately concise without verbosity.

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

  Completeness2/5

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

  Given the absence of an output schema and annotations, the description should provide more context about the returned decision object. It also lacks behavioral or usage context, making it incomplete for a tool with one critical input and no output schema.

  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 100% for the single parameter, so the description adds little beyond the schema. It provides an example case number format, but this is already implied by the schema description. Baseline moderate score 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 retrieves a specific AVK decision by case number and provides an example format. This distinguishes it from sibling tools like si_comp_search_decisions (which searches) and si_comp_get_merger (which gets mergers), 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 does not provide any guidance on when to use this tool versus its alternatives, such as si_comp_search_decisions. No explicit context for usage or exclusion is given, leaving the agent to infer based solely on the name and sibling list.

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

• si_comp_get_mergerB
  3.3/5.0
  Behavior3/5

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

  Description indicates a retrieval operation but does not disclose any behavioral traits such as error handling, authentication requirements, or rate limits. Since annotations are absent, more detail would be beneficial, but the simplicity of a 'get' tool mitigates the gap.

  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?

  Single sentence, no wasted words, front-loaded with purpose. Very concise.

  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 simple tool with one parameter and no output schema, the description is mostly adequate but lacks mention of what is returned or any usage context. It does not cover potential errors or alternative tools, leaving some gaps.

  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 100%, so baseline is 3. The description provides an example ('306-K-1/2023') that adds modest value beyond the schema description. No other parameter details are missing.

  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?

  Clearly states verb 'Get' and resource 'specific AVK merger control decision' with an example case number. While it distinguishes from siblings implicitly by specifying 'by case number', it does not explicitly differentiate from si_comp_search_mergers or si_comp_get_decision.

  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 guidance on when to use this tool versus alternatives like si_comp_search_mergers or si_comp_get_decision. The context is implied by the case number parameter but no explicit when/when-not advice is given.

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

• si_comp_search_decisionsA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It only describes the search functionality and return fields, but fails to mention whether the tool is read-only, any authentication requirements, rate limits, or idempotency. This is insufficient for a search tool.

  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 two sentences: first states the core functionality and scope, second lists return fields. No redundant information, efficient and front-loaded.

  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?

  With 5 parameters, no output schema, and no annotations, the description explains what the tool does and returns. However, it lacks behavioral info (read-only, idempotency), default limits, pagination, and error handling. Somewhat incomplete but covers essential purpose.

  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 100% with descriptions for all 5 parameters. The description adds minimal extra value beyond the schema, only mentioning return fields that are not directly about parameter usage. Baseline score of 3 is appropriate as the schema already explains parameters well.

  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 specifies the tool's purpose: full-text search across AVK enforcement decisions. It explicitly mentions the scope (abuse of dominance, cartel, sector inquiries) and return fields (case number, parties, outcome, fine amount, ZPOmK articles), distinguishing it from sibling tools like si_comp_search_mergers.

  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 searching enforcement decisions but does not explicitly state when to use this tool versus alternatives like si_comp_get_decision for retrieving a single decision or si_comp_search_mergers for mergers. No explicit when-not-to-use guidance is provided.

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

• si_comp_search_mergersA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, and the description only mentions return fields. It does not disclose behavior such as whether the tool is read-only, authentication requirements, rate limits, or any side effects. For a tool with no annotations, more transparency 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.

  Conciseness5/5

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

  The description is two sentences, concise and front-loaded. Every word provides value, with no unnecessary detail.

  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 (4 parameters, no output schema), the description adequately covers what it returns. However, it could mention pagination behavior or result limits, which are implied by the 'limit' parameter but not explained. Overall it is mostly 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?

  All 4 parameters are described in the schema with 100% coverage. The description adds no extra meaning beyond the schema; it only lists some return fields. Baseline score of 3 is appropriate as the schema already conveys parameter semantics.

  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 this tool searches AVK merger control decisions and specifies the return fields (acquiring party, target, sector, outcome). It is distinct from sibling tools like si_comp_search_decisions, which likely covers broader decisions.

  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?

  Usage is implied by the tool name and description, but there is no explicit guidance on when to use this over si_comp_search_decisions or other siblings. The description does not mention when not to use the tool or provide alternatives.

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

• si_comp_aboutA
  4.5/5.0
  Behavior4/5

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

  No annotations, but the description is straightforward: a read-only query returning metadata. It doesn't mention side effects, which are absent. Could list exact metadata fields but sufficiently 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?

  Single sentence, front-loaded with the verb 'Return', no wasted words. Perfectly concise.

  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?

  For a simple metadata tool with no parameters and no output schema, the description is complete. It explains purpose and output, and the sibling list provides context.

  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?

  No parameters exist, so schema coverage is 100%. The description adds value by explaining what the output includes, which is beyond what the empty 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 returns metadata about the server, listing specific items (version, data source, coverage, tool list). This distinguishes it from sibling tools that deal with specific data like decisions or mergers.

  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?

  No explicit when-to-use or alternative guidance, but the context makes it clear this is for server metadata, while siblings are for specific data queries. The use case is obvious.

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

• si_comp_list_sectorsA
  4.5/5.0
  Behavior4/5

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

  The description discloses that the tool lists all sectors and includes decision and merger counts, providing sufficient behavioral context. No contradictions with annotations (none provided), though it could mention if there are any limits or data freshness.

  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-formed sentence that efficiently conveys the tool's function without unnecessary words.

  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 no parameters and no output schema, the description fully informs the agent of what to expect: a list of sectors with enforcement activity, decision counts, and merger counts. The sibling tools handle specific entity lookups.

  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?

  No parameters exist, so the description does not need to add param information. Schema coverage is 100% (trivially), and the baseline for 0 params 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 uses specific verbs and resources ('List all sectors') and clearly distinguishes the tool from sibling tools which focus on specific decisions, mergers, or general information.

  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 implicitly indicates use when sector-level aggregate data is needed, and sibling tools are for specific entities, making the usage context clear. However, it does not explicitly state when not to use.

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