Server Quality Checklist

Tool Scores

• list_partner_groupsC
  2.1/5.0
  Behavior1/5

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

  The description provides no behavioral details (e.g., authentication, pagination, performance). With no annotations, the description carries the full burden and fails to disclose any traits.

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

  Conciseness2/5

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

  The description is brief but under-specified; it is concise but lacks any substantive information beyond the title, wasting the opportunity to provide useful content.

  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?

  For a simple list tool with no parameters and no output schema, the description should at least state the scope or return format. It is incomplete and insufficient for an agent to understand full usage.

  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, and the schema coverage is 100%. Baseline for 0 parameters is 4, as no parameter information is needed. The description adds no value but is not required to do so.

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

  Purpose2/5

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

  The description 'Группы контрагентов' repeats the title and does not specify the action 'list'. It is a tautology, providing no additional purpose beyond the name.

  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 is given on when to use this tool versus sibling tools like list_partners or list_categories. The description lacks context for selection.

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

• list_categoriesC
  2.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 behavior. It only states the basic operation without mentioning side effects, permissions, or any other traits. The agent gets little insight beyond the tool name.

  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 very short (one line) and concise, but it sacrifices necessary detail. For a simple tool with one optional parameter, it is adequate but not optimally informative.

  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 lack of output schema and parameter details, the description is incomplete. It explains the basic purpose but omits return behavior and any behavioral specifics, which is insufficient for full comprehension.

  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 coverage is 0%, but the description clarifies that the pnlType parameter is for filtering. This adds some meaning beyond the schema, but it does not specify format or possible values, leaving gaps.

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

  Purpose3/5

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

  The description states the tool lists categories ('Статьи ОПиУ') with optional filtering by pnlType. However, the verb is implicit and the purpose is somewhat vague without more context. It does not clearly distinguish from sibling tools like list_partner_groups, though the resource is different.

  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?

  There is no guidance on when to use this tool versus alternatives such as list_partner_groups or list_partners. No exclusions or context provided.

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

• list_partnersC
  2.8/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 labels the tool as a 'directory'. It does not disclose whether the output is filtered, sorted, paginated, or any side effects. The burden falls entirely on the description, which fails to provide behavioral details.

  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 extremely concise at three words (in Russian). It is front-loaded and contains no unnecessary text. However, it sacrifices informativeness for brevity, which is acceptable for a zero-parameter tool.

  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 simplicity (no parameters, no annotations, no output schema), the description should at least hint at the output (e.g., list of partner names or IDs). It does not, leaving the agent without enough context about what the tool returns.

  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 zero parameters; the schema coverage is trivially 100% (empty properties). Per guidelines, baseline is 4 since the description adds no necessary parameter information beyond the schema.

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

  Purpose3/5

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

  The description 'Справочник контрагентов' (Directory of counterparties) indicates the resource but lacks an action verb like 'list' or 'get'. It is clear enough for a native speaker but does not explicitly state the operation, making it slightly ambiguous.

  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 is provided on when to use this tool versus sibling tools (e.g., list_categories, list_partner_groups). The absence of any usage context or alternatives reduces clarity for selection.

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

• fintablo_getA
  4.1/5.0
  Behavior3/5

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

  The description discloses read-only nature and that it accesses permitted paths under /v1, but lacks details on authentication requirements, error behavior, or response format. With no annotations, more transparency would be beneficial.

  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 very concise with two efficient sentences. The first sentence conveys the purpose, and the second provides a critical usage warning. No superfluous text.

  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?

  While the description covers the tool's purpose and usage boundaries, it does not explain the return format or pagination. Given no output schema, additional details would improve completeness, but the tool is simple and context is adequate for exploration.

  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 provides an example for the path parameter ('/deal или /transaction'), adding meaning beyond type. The query parameter lacks description, and the tool description does not elaborate further. 50% schema coverage is partially compensated by the example.

  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 it is a read-only GET request to allowed Fintablo /v1 paths for data exploration. It distinguishes from sibling get_nzp by warning not to use results for final figures.

  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 description explicitly states when not to use the tool ('НЕ используйте результаты как основу для итоговой цифры') and points to the alternative get_nzp, providing clear usage guidance.

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

• get_nzpA
  4.2/5.0
  Behavior5/5

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

  No annotations provided, so description carries full burden. It details the calculation components (operations, liabilities, salary, taxes on open stages, minus VAT) and notes the salary tax layer is estimated. This provides clear behavioral insight.

  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?

  Two sentences, front-loaded with the main verb and purpose, each sentence adds specific detail without redundancy. Very concise.

  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?

  Despite lacking output schema, the description explains the calculation sufficiently. The complexity is moderate with one parameter, and the description covers what the tool does and how it works, leaving only return format unspecified.

  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 description coverage is 100% and the tool description repeats the same example format. No additional semantic value beyond the schema is added, 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 calculates WIP for a single transaction by its code, with an example format. It is specific and distinct from sibling tools which are generic list/get operations.

  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 when to use (for one deal's WIP) but does not explicitly state when not to use or compare with siblings. No alternative tools are mentioned.

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