Server Quality Checklist

Tool Scores

• search_by_krsA
  3.7/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 says 'look up' without disclosing potential errors, authentication requirements, or whether the result includes the full entity data or just confirmation of existence.

  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 concise sentence that is front-loaded with the action and resource, no redundant words.

  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 simple one-parameter lookup, the description is mostly sufficient, but it lacks a description of the return value or behavior for invalid KRS numbers, and the absence of an output schema leaves the agent to guess what 'look up' 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?

  The schema only defines 'krs' as a string, but the description adds critical format detail ('10-digit court-register number'), which compensates for the 0% schema description coverage.

  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?

  Description states 'Look up a Polish business entity by KRS (10-digit court-register number)', which clearly identifies the resource (Polish business entity), the specific identifier (KRS), and the unique scope (court-register number), distinguishing it from siblings that search by REGON/NIP.

  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 when a KRS is available but does not explicitly discuss alternatives like search_by_regon or search_by_nip, nor when to prefer search_bulk.

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

• search_by_regonA
  3.7/5.0
  Behavior2/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 only states the lookup purpose and does not disclose whether it is read-only, what the response looks like, or any constraints or 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 a single sentence that is concise, direct, and free of unnecessary detail. Every word adds value, focusing on the essential purpose.

  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 one-parameter lookup tool, the description covers the core purpose but lacks information about the return format, error handling, or any usage context. With no output schema, the description should at least hint at what the tool returns upon success.

  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 schema only declares a string property 'regon' with no description. The description compensates by explaining that REGON is a 9- or 14-digit statistical id, which clarifies the expected format and meaning for the single parameter.

  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's action ('look up'), the resource ('Polish business entity'), and the specific identifier ('REGON'). It effectively distinguishes this from siblings like search_by_nip and search_by_krs by focusing on the REGON id.

  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 the tool is for when you have a REGON, but it doesn't explicitly state when to prefer this over alternatives or mention any exclusions. No guidance on context or when-not-to-use is provided.

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

• get_full_reportA
  4.2/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. It adds useful context that report_type depends on entity type and silo_id, and clarifies it's a single-entity fetch. However, it does not disclose response format, error behavior, or any potential side effects, leaving gaps.

  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, front-loaded with the core purpose and followed by essential usage guidance. No filler, every sentence earns its place.

  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 two-parameter tool with no output schema, the description covers the necessary invocation steps and prerequisite dependencies. It omits explicit return format or error cases, but the name and 'detailed report' convey the basic output expectation adequately.

  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 0%, but the description compensates by explaining that regon is the entity identifier and report_type should be selected from list_report_types(). This gives meaningful meaning to both parameters beyond their bare string types, though it doesn't specify exact formats.

  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 and resource: 'Fetch a detailed REGON report for one entity by REGON.' This clearly differentiates it from sibling search tools and list_report_types, and states exactly what the tool does.

  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?

  It explicitly tells the user to choose report_type from list_report_types() based on the entity's type and silo_id returned by a search, establishing a clear usage workflow. It doesn't explicitly state when not to use it, but the prerequisite and selection guidance are strong.

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

• search_bulkA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses response fields (`requested` and `unmatched`) that clarify partial result behavior, and it highlights a KRS-specific quirk where `unmatched` is null. It also mentions the 20-entity limit. This adds meaningful behavioral context beyond a simple search tool, though it does not cover error handling or rate limits.

  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 compact and front-loaded with the main purpose. Each sentence adds value: the limit/type constraint, the allowed id_type values, and the response field explanation. There is no redundancy or 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?

  Given no output schema or annotations, the description covers the core functionality, limits, and response fields, including an important edge case (KRS unmatched behavior). It is complete enough for an agent to select and invoke the tool correctly, though it omits details like error handling or full response schema.

  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 0%, so the description must compensate. It explicitly lists allowed id_type values and states the same-identifier-type requirement. It also implies identifiers is a list of IDs (via 'requested ids') and caps it at 20. This provides essential semantics not in the schema, though it doesn't detail identifier format or normalization rules.

  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's function: 'Look up up to 20 entities of the same identifier type in one call.' It uses a specific verb ('look up'), identifies the resource ('entities'), and distinguishes itself from sibling single-entity tools by emphasizing the bulk nature and identifier-type constraint.

  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 batching multiple lookups of the same identifier type, contrasting with sibling single-entity search tools. It also explicitly restricts id_type to specific values. However, it does not explicitly say 'use this instead of multiple search_by_* calls' or state when not to use it, so it lacks explicit alternative guidance.

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

• search_by_nipA
  4.4/5.0
  Behavior4/5

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

  No annotations, so description carries full burden; it discloses return fields (name, REGON, address, entity type) and relationship to get_full_report. Does not mention error handling or input formatting edge cases, but for a simple lookup this is adequate.

  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 concise sentences with front-loaded action and clear structure: first sentence states what is looked up and input format, second states output and suggested next step. No filler or repetition.

  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?

  No output schema, but description lists returned fields and points to get_full_report for richer data. With only one parameter and clear purpose, it is adequate, though it omits not-found behavior or NIP formatting variations.

  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?

  Input schema has no description for the single nip parameter (0% coverage); description adds essential meaning by specifying it is a 10-digit tax id and clarifies how the returned REGON is used. This meaningfully compensates for the schema gap.

  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?

  Description uses specific verb 'Look up' and identifies resource 'Polish business entity by NIP', explicitly distinguishing from sibling search_by_regon/search_by_krs by identifier and from get_full_report by noting basic vs. detailed 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?

  Clear context: use when you have a NIP and need basic registry data, with explicit follow-up to get_full_report for the detailed record. Does not explicitly rule out sibling search tools, but the identifier-specific scope is unambiguous.

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

• list_report_typesA
  4.6/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 full burden of behavioral disclosure. It explicitly states that the tool lists valid values, identifies these as 'BIR1.1 report names', and explains the mapping logic. While it doesn't mention side effects or return format, the operation is inherently read-only and the description adds meaningful context about the semantic relationships between types and reports.

  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 somewhat verbose but each sentence and line earns its place. It front-loads the purpose ('List valid report_type values') and then provides structured guidance in a readable mapping format. The length is appropriate given the complexity of the type-to-report mapping, and there is no fluff or repetition.

  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 tool is simple in function but complex in the mapping it documents. The description fully covers the report type selection logic, including all relevant type indicators and silo_id branches. There is no output schema, but the description explains the essential semantics and the relationship to get_full_report(), making it complete for an agent to invoke or understand the result.

  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 0 parameters and the schema description coverage is 100%, so the baseline is 4. The description adds no parameter-specific information because there are no parameters to describe. It does discuss the output values, which is beyond parameter semantics but still useful. Since there is no schema to clarify, the description fully compensates by explaining the meaning of the report types.

  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's function: 'List valid report_type values for get_full_report()'. It uses a specific verb ('List') and a specific resource ('report_type values for get_full_report()'), and it distinguishes itself from sibling search tools by focusing on report type enumeration rather than entity lookup.

  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 provides explicit guidance on when to use each report type through the 'Picking the right report' section, including a breakdown by type ('P' vs 'F') and silo_id. This is not just context; it gives decision criteria and references the companion tool get_full_report(), making it clear where this tool fits in the workflow.

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