Server Quality Checklist

Tool Scores

• ndl_search_digital_openB
  3.2/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHintfalse, so the safety profile is covered. The description adds value by clarifying the data set scope and licensing: only open-data records are included, and the wider collections are 'displayable, not redistributable'. This is useful behavioral context about what the tool can return, though it does not describe response format or limits.

  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 compact and well-structured: a one-line purpose statement in Japanese, then a concise English explanation of the key scope constraint and licensing nuance. It front-loads the main action and does not waste words, though the language mix is slightly awkward for an English-first agent.

  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 tool has an output schema and annotations cover read-only/idempotent behavior, the description’s main job is scoping and usage guidance. It handles scoping well and adds useful licence context, but it leaves out any explicit guidance on when to choose this over siblings like ndl_search_books or ndl_search_all, and it does not mention pagination or result count controls (though those are in the schema). Overall it is adequate but not thorough.

  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?

  The tool description contains no parameter information. Context signals report 0% schema description coverage, so the description must compensate but does not. The nested schema fields have some descriptions, but the top-level 'params' parameter is undocumented in the description, leaving an agent to delve into the $ref to construct a query. The description's licence discussion gives no help with the many search fields.

  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 states a clear verb and resource: 'Search 国立国会図書館デジタルコレクション（オープンデータ）', reinforced by the annotation title 'Search NDL Digital Collections (Open Data)'. It distinguishes from the wider Digital Collections by explicitly saying 'The open-data set only', so an agent can tell this tool is scoped to the open subset. It does not name sibling search tools, but the scoping qualifier differentiates enough.

  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 gives context about when to use this tool: it searches only the open-data set, and the wider collections are explicitly excluded. It does not name alternative tools or say 'use X for the wider collections', but the scope limitation clearly implies this tool is for open data. The licence discussion adds context about the data set, but no explicit when-not-to-use or alternative routing.

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

• ndl_search_national_bibliographyA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempoentHint=true, openWorldHint=true, and destructiveHint=false, covering safety and side-effect profile. The description adds only the data-quality trait (authority of imprint data), which is contextual but not a behavioral disclosure such as result ordering, matching semantics, or limits. It adds some value beyond annotations but does not carry new behavioral information.

  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, zero redundancy. The resource and action are front-loaded, and the second sentence earns its place by explaining why this tool exists and when it matters.

  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?

  An output schema exists, every parameter is documented in the schema, and annotations cover the operational profile, so the description need not explain return values or side effects. What it adds — the authority positioning and the when-to-use rule — completes the picture for correct selection. A brief note distinguishing it from ndl_search_books or ndl_search_all would make it complete, hence not a 5.

  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 description coverage is 0% — the tool description contributes nothing about the 12 parameters, though the schema itself documents each property well. The phrase "publication date, publisher or edition statement" faintly hints at which search fields matter, but that is indirect and does not compensate for the coverage 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?

  The description states a specific verb and resource — "Search 国立国会図書館全国書誌情報" — and then sharpens the scope by positioning this as the authoritative source for Japanese imprint data. The "authority" framing distinguishes it from sibling search tools without ambiguity: this is the tool to trust for dates, publishers, and edition statements.

  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 clear when-to-use guidance: choose this tool when a publication date, publisher, or edition statement must be authoritative rather than merely plausible. It stops short of naming alternative siblings or stating when NOT to use it, so a score of 5 would overstate its completeness.

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

• ndl_search_allA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the description doesn't need to restate safety. It adds the useful behavioral context that one call hits all five provider sets at once. It doesn't disclose behaviors like result merging, duplication, or pagination, but with strong annotations and an output schema this is acceptable.

  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 with no filler: the core action is front-loaded, and the usage guidance follows immediately. Every sentence carries meaning.

  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 an aggregate search tool with read-only annotations, rich nested parameter descriptions, and an output schema, the description covers the key decision (when to use all vs. narrower). It would be slightly stronger if it named the five provider sets or the narrower sibling tool names, but the sibling list and schema supply that context.

  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?

  The description says nothing about parameters. Reported schema description coverage is 0% at the top level, and the description does not compensate by explaining search fields or constraints. The nested schema does contain useful per-field descriptions (ndc, isbn, title, year, etc.), which prevents this from being a 1.

  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 opens with a specific verb and resource: 'Search all five declared provider sets at once.' This distinguishes it from the narrower sibling search tools by scope (all sets vs. one set), so an agent can tell it apart from ndl_search_books, ndl_search_articles, etc. without opening the schema.

  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?

  It gives an explicit use condition — 'Use when the material type is unknown' — and an explicit alternative condition: 'For a bibliographic check, the narrower tools return a cleaner set.' The alternative names aren't listed verbatim, but the sibling list makes them identifiable.

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

• ndl_search_articlesA
  4.2/5.0
  Behavior4/5

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

  Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds useful behavioral context: it includes the online-materials set, covers articles often missing from CiNii/J-STAGE, and explicitly does not provide full text. No contradiction with annotations.

  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, purposeful sentences with no filler. The action and resource are front-loaded, followed by scope and a clear limitation. 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 search tool with a rich schema and an output schema, the description adequately explains what is searched, the coverage scope, and the key limitation (no full text). It could be more explicit about sibling routing, but overall it is complete enough for correct invocation.

  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 tool description itself does not describe any parameters, but the nested SearchInput schema gives detailed descriptions for each field (e.g., partial match, date formats, bounds). The description adds no extra parameter meaning, and the structured schema already carries the burden.

  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 opens with a specific verb and resource: 'Search 国立国会図書館雑誌記事索引', then clarifies that it covers Japanese periodical articles and indexes articles, not full text. This makes it easy to distinguish from sibling tools like ndl_search_books or ndl_search_national_bibliography.

  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 gives clear context on when this tool is relevant: for Japanese periodical article records, including coverage beyond CiNii and J-STAGE. It does not explicitly name sibling tools or state when not to use them, but the scope is clear enough for an agent to route correctly.

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

• ndl_search_booksA
  4.2/5.0
  Behavior5/5

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

  Annotations already mark the tool read-only and idempotent, and the description adds meaningful behavioral detail: fields are combined with AND, title/creator/publisher/subject match partially, it returns the unified response envelope, and records are displayed but not stored. This clearly communicates side effects and result shaping, and it does not contradict any annotation.

  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 terse sentences: the first states purpose, the second states matching behavior, the third states output and side-effect semantics. No filler words, no repetition of schema details, and the most important information 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?

  The description, together with a rich input schema and an output schema, gives an agent enough to invoke the tool correctly: scope, query combination semantics, return envelope, and non-storage behavior. It falls short only in not explicitly routing the agent away from sibling search tools or mentioning pagination parameters, though those are documented in the 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?

  The description names a few parameters (title, creator, publisher, subject) and notes they match partially, but the input schema already documents each field with equivalent or richer descriptions. The main addition beyond the schema is 'fields are combined with AND', which is useful but modest. Given the schema descriptions are strong, 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 states a specific action ('Search'), a concrete resource ('国立国会図書館蔵書'), and a clear scope ('books and monographs'). This distinguishes it from sibling tools like ndl_search_articles or ndl_search_digital_open without needing to inspect their schemas.

  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 this tool is for searching books and monographs rather than articles or digital collections, but it never explicitly names alternatives or says when to prefer this tool over sibling searches. It does provide practical query semantics (AND combination, partial matching), but not exclusion guidance.

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

• ndl_get_recordA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond annotations by explaining that the envelope omits 'searched_for' because no search term is chosen, which gives the agent insight into the response format.

  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 convey the purpose and the key operational distinction. The description is front-loaded with the primary action, and every sentence adds relevant information with no filler.

  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 single-record fetch tool, the description is complete: it covers the identifier requirement, the fetch-vs-search distinction, and a response envelope nuance. The output schema and annotations handle return format and safety, so nothing essential is missing for the agent to invoke this tool correctly.

  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?

  With schema description coverage reported at 0%, the description partially compensates by naming both accepted identifier types: NDL bibliographic ID and 全国書誌番号. It also adds the critical constraint that exactly one identifier is required, which is not enforced by the schema (both params are individually optional). However, it does not elaborate on identifier format or which identifier should be preferred when both are known.

  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: 'Retrieve a single record by NDL bibliographic ID or 全国書誌番号 (JP number).' It further distinguishes itself from the search sibling tools by explicitly stating 'A fetch, not a search,' so an agent can clearly tell it apart.

  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 clear context: this tool is for fetching by a known identifier, not for searching. It also provides a key usage requirement, 'Exactly one identifier is required,' which helps the agent avoid invalid calls. It does not explicitly name alternative tools, but since all siblings are search tools, the contrast is sufficient.

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