Server Quality Checklist

Tool Scores

• find_similar_patentsA
  3.9/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 burden. It discloses that each result includes the matching method (provider similarity vs semantic search), which is helpful behavioral context. However, it does not mention other important traits like whether the operation is read-only, data source behavior, or rate limits, leaving partial transparency.

  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, well-structured, and front-loaded with the main purpose followed by usage guidance. Every sentence contributes value, and the formatting makes the key distinctions easy to scan.

  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 has 11 parameters and an output schema, the description covers the essential decisions: the starting point, the combination of inputs, and how to interpret results. It does not repeat schema details, and the schema already documents parameters thoroughly. The description is adequately complete for this complexity.

  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 description coverage is 100%, giving a baseline of 3. The description adds value beyond the schema by explaining how publication_number and text interact when both are provided ('narrow around that patent from a text perspective'), which is not readily apparent from individual parameter descriptions.

  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 clearly states the tool finds patents similar to an existing patent or free text, specifically for prior art/infringement searches. This is a specific verb+resource, but it does not explicitly distinguish itself from sibling tools like search_patents, 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage patterns: pass publication_number for an existing patent, pass text for unpatented ideas, or both to narrow around a patent. This is clear context for when to use each parameter, but it does not name alternatives or exclusions relative to sibling tools, so it earns a 4.

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

• get_patentA
  4/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the burden of behavioral disclosure. It adds context about token consumption and section selection, but does not discuss output behavior, error handling, or data freshness. The description is not misleading, but it only partially discloses the tool's behavior beyond the name/schema.

  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—two short sentences in the first paragraph and a brief guiding note in the second. It is front-loaded with the primary action, and every sentence adds value without redundancy.

  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 has an output schema and a detailed input schema, the description adequately covers purpose and usage. It may not explain return format or provider selection, but those are either in the schema or exposed via sibling tools. Overall, it provides sufficient context for an agent to select and invoke the tool effectively.

  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 each parameter has detailed descriptions (e.g., sections list, max_chars bounds, publication_number normalization). The tool description reinforces the context-saving aspect of section selection but does not add much beyond the schema. 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 '公開番号を指定して特許の中身を取得する' (get patent contents by publication number), which is a specific verb+resource combination. It further lists distinct use cases like checking claims, reading specification, and understanding citations/family, which differentiates it from sibling tools like search_patents and find_similar_patents.

  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 specifies when to use the tool ('請求項の文言確認、明細書の読み込み、引用関係やファミリーの把握に使う') and advises to select only needed sections to avoid wasting context. It lacks explicit exclusions or direct comparisons to alternatives, but the provided use cases give clear situational guidance.

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

• search_patentsA
  4.2/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 accurately discloses the main behavior: searching and returning bibliographic info and excerpts. It does not mention potential side effects like rate limits or default provider behavior, but the core behavior is clear and 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.

  Conciseness5/5

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

  The description is two short paragraphs. The first sentence states the function; the subsequent sentences give usage guidance. Every sentence earns its place, and the layout is front-loaded.

  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 rich set of 12 parameters (all documented in the schema) and the presence of an output schema, the description is sufficient. It explains the core purpose and directs to the appropriate sibling for full-text needs, though it could briefly mention filtering capabilities.

  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 description adds a usage context note but does not add parameter-specific semantics beyond what the schema already provides for each 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 searches patents by keyword and returns bibliographic information and excerpts. It distinguishes from siblings by specifying this is keyword-based search, and explicitly mentions get_patent for full claims/specifications.

  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 provides explicit usage context (finding prior art lead based on technical themes or applicants) and an explicit alternative (get_patent when full claims/specifications are needed). It does not mention find_similar_patents as an alternative, which slightly reduces completeness.

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

• list_patent_providersA
  4.3/5.0
  Behavior3/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. It explains the tool's purpose and usage context but does not disclose additional behavioral traits such as whether it is read-only, if authentication is needed, or any limitations. The description is not misleading but is minimal.

  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, front-loaded with the core function and followed by practical usage scenarios. Every sentence earns its place with no wasted 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 the tool is a simple listing operation with no parameters and an output schema exists, the description sufficiently covers what it does and when to use it. It is complete for this level of complexity.

  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 zero parameters and the schema coverage is 100% trivially, so the baseline is 4. The description adds no param details, which is acceptable since no parameters exist.

  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 returns available patent data sources and the functions each supports, using the specific verb '返す' (returns). This distinguishes it from siblings like get_patent and search_patents, which are about retrieving or searching patents.

  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 explicitly tells when to use: 'when the tool answers unsupported or when you want to switch to a different data source.' It lacks an explicit when-not statement, but the context is clear and distinguishes from sibling tools.

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