Server Quality Checklist

Tool Scores

• get_supplier_statsA
  3.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It adds meaningful detail: the official site requires a machine exchange token, and without it the tool returns an explicit refusal with a reason rather than empty zero values. This helps an agent interpret failures correctly, though it does not describe the summary contents or any side effects.

  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 short sentences with no filler. The core purpose is stated first, and the important availability/failure caveat earns its place immediately after.

  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?

  An output schema exists, so return values need not be explained in the description. The token requirement and failure behavior are useful context, but the description omits guidance on choosing between parameters and leaves period semantics unclear. For a low-complexity tool this is adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 50%, with inn and ogrn described but period_from and period_to left undocumented. The description adds no parameter-level meaning, does not clarify date format or semantics, and does not compensate for the undocumented period parameters.

  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 identifies the resource as a supplier summary ('Сводка по поставщику'), which distinguishes it from sibling tools focused on tenders, customer history, or OKPD2. However, it lacks an explicit verb explaining the operation being performed, so it falls short of a 5.

  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 token caveat gives a clear condition under which the tool will not work and what to expect instead, but it does not explicitly state when to prefer this tool over alternatives or mention any sibling tool. Usage is implied by the 'supplier summary' purpose rather than directly guided.

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

• get_tenderA
  3.6/5.0
  Behavior3/5

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

  No annotations provided, so description must carry full burden. It states 'get full tender card' but does not elaborate on read-only nature, rate limits, or default parameter behaviors (e.g., include_documents defaults true). Minimal but not misleading.

  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?

  Single sentence, front-loaded with purpose. No wasted words, but could include brief usage context. Still appropriate for a simple retrieval tool.

  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?

  Given the existence of an output schema (context says yes), the description need not detail return values. However, it lacks mention of document/protocol inclusion flags despite them being in schema. Adequate but could be more informative.

  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 clear descriptions for all three parameters. The description adds no extra meaning beyond the schema, only referencing 'registr number' which matches the required parameter. Baseline score 3 as schema already suffices.

  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 verb (get), resource (full tender card), and identifier (registr number of EIS). It distinguishes from sibling tools like search_tenders (search vs specific retrieval) and get_customer_history (different entity).

  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?

  No explicit when-to-use or when-not-to-use guidance. It is implied to use when you have a specific registry number, but no comparison with search_tenders or prerequisites are mentioned.

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

• get_customer_historyA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full disclosure burden. It does indicate a read-only style behavior by saying 'Отдаёт реквизиты' and adds a useful limitation about volume summaries requiring a machine-exchange token. However, the token sentence is ambiguous about whether the base card also requires a token and what happens when the token is absent.

  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 short sentences with the main purpose front-loaded, followed by the returned content and a limitation caveat. Each sentence contributes meaningful information and there is no padding.

  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 output schema covers return values, so that part is not a gap. The main missing context is that the schema allows all parameters to be omitted, while the description implies lookup by INN or OGRN but never requires at least one. It also does not clarify whether the token limitation affects the whole call or only the volume summary.

  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 covers all four parameters with formats and defaults (100% coverage), so the baseline is 3. The description adds little beyond naming INN or OGRN as identifiers, which duplicates the schema and does not clarify whether at least one identifier is required or how the period parameters relate to the volume summary.

  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 names a specific resource, 'Карточка заказчика' (customer card), and states that it returns requisites and RNP status from the official EIS site using INN or OGRN. This is clear enough to distinguish the tool from siblings like get_tender or search_tenders. However, the tool name says 'history' but the description never explains what the history aspect is, and it does not explicitly differentiate from get_supplier_stats.

  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 a clear lookup context: use this tool when you need a customer card from EIS by INN or OGRN. It does not provide explicit when-not-to-use guidance or name alternative sibling tools, but the context is sufficiently clear for tool selection.

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

• pingA
  4.1/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 carry the full burden of behavioral disclosure. It only states the tool verifies server availability but does not describe the nature of the request, timeout behavior, any potential side effects, or what the output looks like. This is insufficient for a tool with no annotation coverage.

  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, concise sentence that front-loads the purpose. Every word earns its place with no extraneous information.

  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 ping tool with no parameters, an existing output schema, and a straightforward purpose, the description is complete. It covers the essential information needed to understand when and why to use the 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?

  The input schema has no parameters, and schema description coverage is 100%. The description adds no additional parameter meaning, which is acceptable since there are none to document. The baseline for zero parameters 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 it is a diagnostic tool to check if the server is running and available. It uses a specific verb and resource, and effectively distinguishes itself from the sibling tools which deal with customer, supplier, and tender 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?

  The description implies the tool's usage context (checking server availability), but does not explicitly state when to use it or when not to use it, nor does it mention any alternatives. However, given the simplicity and lack of similar sibling tools, the context is clear enough.

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

• lookup_okpd2A
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description adequately discloses behavioral traits: offline operation and data source (vendored vs full directory). It adds value beyond the schema by clarifying the offline nature, though it could mention that results are limited to available codes.

  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 three sentences, front-loads the purpose, and contains no unnecessary words. Every sentence contributes essential context.

  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 simple lookup tool, given the presence of an output schema and full parameter descriptions. It explains the data source and offline nature, but could briefly mention return format or result behavior.

  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%, so the baseline is 3. The tool description does not add new meaning beyond what the input schema already provides for parameters (query, limit, code_type).

  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 finds OKPD2/KTRU codes via full-text search. It specifies the verb 'Найти' and the resource 'код ОКПД2 / КТРУ', distinguishing it from unrelated sibling tools.

  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 that the tool uses a vendored directory (top codes) or full directory after CI-upload, and that it requires no network calls. It does not explicitly state when not to use or alternatives, but the context is clear given unrelated siblings.

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

• search_tendersA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description explains pagination (up to 100 objects, next_page_token) and how filters combine (AND). It does not cover rate limits or authentication, but provides sufficient 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 concise with three clear sentences, front-loaded with purpose, and contains no unnecessary information.

  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 complexity (18 parameters, output schema exists), the description covers core behavior: search, pagination, AND combination. It could mention permissions or data freshness but is largely 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?

  Schema description coverage is 67%, and the description does not add significant parameter-specific details beyond what the schema already provides. 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 tool searches tenders by filters in EIS, specifying the applicable laws (44-ФЗ, 223-ФЗ, 615-ПП). It distinguishes from sibling tools like get_tender (single tender) and lookup_okpd2 (code lookup).

  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 implies usage for filtering tenders but does not explicitly state when to use this tool versus alternatives or provide exclusions. It is clear enough for a search tool.

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