Skip to main content
Glama

jp_lit_search_fulltext

Search for keywords in the OCR full-text of Japan's Next Generation Digital Library collections. Specify search field, result range, or filter by NDC classification.

Instructions

external read / local bookkeeping write(非破壊)。次世代デジタルライブラリー収録資料を対象に OCR 全文テキストからキーワード検索する。デジコレ本体の全文検索画面/APIではなく、デジコレ本体の「ログインなしで閲覧可能」資料全体も対象ではない。館内限定・送信サービス限定資料を含め、公式検索画面の全文ヒットは網羅しない。網羅性が必要な調査では、この結果だけで「デジコレ全文にヒットなし」と断定せず、公式画面でのブラウザ検索・手動確認を併用する。searchfield=contentonly で本文のみ、metaonly でメタデータのみ、all で両方を検索。結果には pid が含まれ、特定資料内のページ特定は jp_lit_search_pages、ページ画像と OCR 座標確認は jp_lit_get_text_coordinates で行う 外部sourceは変更しない。cache hitでもlocal session履歴を更新し、cache missまたはforce_refreshではlocal cacheを作成・置換する。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromNo検索結果の offset。0 始まり。
sizeNo返す資料候補の最大件数。最大 100。
f_ndcNo次世代デジタルライブラリー Book API の f-ndc filter。上位分類は 9* のような前方一致で指定する。9 のような1-2桁の数字だけを渡した場合は 9* に正規化する。空文字・空白だけの値は未指定扱いにする。
keywordYesNDL デジタルコレクション公開範囲の OCR / メタデータから探す語。
session_idYes調査案件を識別��る application state handle。jp_lit_start_session が返した値を渡す。形式は YYYY-MM-DD-HHMMSS-8桁hex(旧形式 YYYY-MM-DD-HHMMSS も可)。MCP transport の接続IDや cache_key とは別物。
searchfieldNo検索対象。contentonly は本文 OCR、metaonly はメタデータ、all は両方。contentonly
fc_is_classicNo古典籍フラグで絞る場合に指定する。
force_refreshNotrue の場合はローカル cache を使わず upstream API から再取得する。false の場合は保存済み cache を優先する。

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rawYes
fromYes
cacheNo
itemsYes
totalYes
keywordYes
searchfieldYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.14.0
    • changedInput schema / properties / session_id / description
      Previous value: -"調査案件を識別する application state handle。jp_lit_start_session が返した値を渡す。形式は YYYY-MM-DD-HHMMSS-8桁hex(旧形式 YYYY-MM-DD-HHMMSS も可)。MCP transport の接続IDや cache_key とは別物。"New value: +"調査案件を識別��る application state handle。jp_lit_start_session が返した値を渡す。形式は YYYY-MM-DD-HHMMSS-8桁hex(旧形式 YYYY-MM-DD-HHMMSS も可)。MCP transport の接続IDや cache_key とは別物。"
  2. Changed2 schema fields changedv0.13.0
    • addedInput schema / properties / session_id
      Added value: +{
      +  "description": "調査案件を識別する application state handle。jp_lit_start_session が返した値を渡す。形式は YYYY-MM-DD-HHMMSS-8桁hex(旧形式 YYYY-MM-DD-HHMMSS も可)。MCP transport の接続IDや cache_key とは別物。",
      +  "pattern": "^\\d{4}-\\d{2}-\\d{2}-\\d{6}(?:-[0-9a-f]{8})?$",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "keyword"
      -]New value: +[
      +  "session_id",
      +  "keyword"
      +]
  3. Changed1 schema field changedv0.7.10
    • changedInput schema / properties / f_ndc / description
      Previous value: -"NDL デジタルコレクションの NDC filter。分かっている場合だけ指定する。"New value: +"次世代デジタルライブラリー Book API の f-ndc filter。上位分類は 9* のような前方一致で指定する。9 のような1-2桁の数字だけを渡した場合は 9* に正規化する。空文字・空白だけの値は未指定扱いにする。"
  4. Changed7 schema fields changedv0.7.1
    • addedInput schema / properties / f_ndc / description
      Added value: +"NDL デジタルコレクションの NDC filter。分かっている場合だけ指定する。"
    • addedInput schema / properties / fc_is_classic / description
      Added value: +"古典籍フラグで絞る場合に指定する。"
    • addedInput schema / properties / force_refresh / description
      Added value: +"true の場合はローカル cache を使わず upstream API から再取得する。false の場合は保存済み cache を優先する。"
    • addedInput schema / properties / from / description
      Added value: +"検索結果の offset。0 始まり。"
    • addedInput schema / properties / keyword / description
      Added value: +"NDL デジタルコレクション公開範囲の OCR / メタデータから探す語。"
    • addedInput schema / properties / searchfield / description
      Added value: +"検索対象。contentonly は本文 OCR、metaonly はメタデータ、all は両方。"
    • addedInput schema / properties / size / description
      Added value: +"返す資料候補の最大件数。最大 100。"
  5. Changed2 schema fields changedv0.6.0
    • addedInput schema / properties / force_refresh
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / cache
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "cache_key": {
      +      "type": "string"
      +    },
      +    "hit": {
      +      "type": "boolean"
      +    },
      +    "refresh_hint": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "saved_at": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "hit",
      +    "cache_key",
      +    "saved_at",
      +    "refresh_hint"
      +  ],
      +  "type": "object"
      +}
  6. First observedv0.1.9

TDQS

A4.9/5.0
Behavior5/5

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

The description clearly discloses side effects: it is an external read with local bookkeeping writes, it is non-destructive, it does not modify the external source, and it describes cache behavior on hit, miss, and force_refresh. This is consistent with the annotations readOnlyHint=false and destructiveHint=false.

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 well organized and front-loaded with the core purpose, followed by limitations, parameter behavior, related tools, and cache semantics. It is slightly repetitive in the caveats about not covering the entire main NDL Digital Collections corpus, which could be condensed, but the structure remains clear and useful.

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 the complexity of the tool, the description is complete: it covers scope, exclusions, comprehensiveness limitations, searchfield behavior, cache side effects, and how the output relates to other tools. No critical missing context prevents an agent from calling the tool correctly.

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

Parameters5/5

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

All eight parameters are covered by the schema, and the description adds valuable semantics: searchfield values are explained, f_ndc normalization is specified, session_id is distinguished from transport IDs and cache keys, and force_refresh/cache behavior is clarified. The description also notes that results include pid, linking to the intended downstream tools.

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 explicitly states the tool's purpose: keyword search over OCR full text in the Next Generation Digital Library collection. It also clarifies what it is not (the main NDL Digital Collections full-text search) and distinguishes related tools for page-specific and coordinate-specific 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 gives concrete guidance on when to use this tool versus alternatives: it warns against treating results as exhaustive for comprehensive research and directs users to the official UI when full coverage is required. It also explicitly points to jp_lit_search_pages for page identification and jp_lit_get_text_coordinates for OCR coordinate confirmation.

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