CiNii Research API（CiNii Research API）を公開するFastMCP stdioサーバーです。CiNii Researchは、国立情報学研究所（NII）が運営する日本の学術データベースで、Claude Desktopやその他のMCPクライアントで利用できる7つのツールとして公開しています。
CiNii Researchは、KAKEN、CiNii Articles、CiNii Books、IRDB、Crossref、DataCite、PubMed、NDL Searchのメタデータを集約しています。これに対する確立されたオープンなMCPツールは存在しないため、このサーバーは日本語の学術文献を検索する研究者向けにそのギャップを埋めます。
CiNii Researchは、5種類のレコードにわたって日本の学術情報を索引化しており、これをすべてClaudeの会話内に取り込むことができます。雑誌記事、書籍・モノグラフ、博士論文、KAKEN科研費プロジェクト、研究者プロフィールに加え、CRIDによる単一レコードの検索も可能です。英語で質問すると、日本語の学術情報が返ってきて、実際に送信された日本語の用語が結果の横に表示されます。
KAKENは特に注目に値します。KAKENは助成された研究を記録しているため、進行中のプロジェクト、形成されつつある共同研究、そして印刷物になる前に助成報告書に到達した研究を浮き彫りにします。
すべての結果には、送信された用語、その文字種、CiNiiがどのようにマッチングしたか、そしてクエリを確定するレシートが含まれているため、脚注の背後にある検索を特定し、引用し、他の誰かが再度実行することができます。
Related MCP server: article-mcp
ツール | 目的 |
| 雑誌記事（JALC、Crossref、PubMed、IRDB） |
| 書籍・モノグラフ（NACSIS-CAT、NDL Search） |
| 日本の大学からの博士論文 |
| KAKEN（科研費）助成研究プロジェクト |
| すべてのコンテンツタイプにわたる横断検索 |
| 研究者プロフィールと所属機関 |
| URLまたはCRIDによる単一レコードの検索 |
結果はCiNii Research OpenSearch v2 APIからJSON-LDとして取得され、型付きのJSONレスポンスエンベロープとして返されます。詳細は下記のレスポンス形式を参照してください。（v2.0.1より前のリリースでは整形されたMarkdownテキストを返していました。これは破壊的な変更であり、書式設定の好みではありません。）
すべてのツールは、mediation.pyによって構築され、response-schema.jsonで定義された1つのJSONレスポンスエンベロープを返します。スキーマバージョン2.3.0。同じモジュールとスキーマはサーバーファミリー全体でバイト単位で同一にベンダリングされているため、あるサーバーからのエンベロープは、別のサーバー用に書かれたコンシューマーで読むことができます。
エンベロープは、何が見つかったかだけでなく、検索がどのように行われたかを報告します。
searched_for — 検索操作では、実際に送信された用語、検出された文字種、マッチングモードがエンベロープの先頭に引き上げられ、中継クライアントがそれを落とすことができません。フェッチ操作（cinii_get_record）では省略されます。識別子を渡され、用語を選択しなかったためです。
query — input_termsは指定されたとおり、normalizedは送信されたとおり、そして検出されたscript。このペアは、呼び出し元の言語とコーパスの間で行われたレンダリングの記録です。
matching_mode — このサーバーではmetadata_conjunction。result.totalの読み方を示します。
result.breadth — none、narrow（1〜50）、broad（51〜1000）、very_broad（>1000）。しきい値は意図的に低く設定されています。数百件のヒットが文献のように見える場合は、そのまま通過させるのではなく、マークされます。
items[].matched_in — レコードごとに、マッチが行われたフィールド。
receipt — ISO 8601タイムスタンプ、正規化されたクエリとそのパラメータに対するSHA-256、および返された識別子。ハッシュは既に保持している用語を検証します。ハッシュから用語を生成することはできないため、預託の単位はレシートではなくエンベロープです。
attribution — すべてのレスポンスに必要なクレジット行。
型付きで閉じています。診断はクライアントが解析する必要のある散文ではありません。
コード | レベル | 意味 |
| info | レコードが返されました。フラグはありません。 |
| warning | レコードがありません。CiNiiはカタログ化されたメタデータをマッチングし、複数語のクエリをANDで結合するため、関連する研究が存在する場合でも、索引化されていない複合語はゼロを返します。文献が存在しないと結論する前に、レンダリングを変えてください。 |
| warning | クエリがラテン文字だったため、ローマ字化されたメタデータと英語のメタデータのみにマッチしました。日本語表記の形式は、異なる、より大きなコーパスに到達します。 |
| error | APIが応答し、エラーで応答しました。 |
| error | リクエストが完了しませんでした。失敗した検索は結果が不明であり、欠如として書き留めてはならないため、 |
| info | レシートの宛先が設定されていないため、レスポンスはクエリ台帳に書き込まれませんでした。検索には影響ありません。レシートは残りません。 |
| warning | レシートの宛先が設定され、書き込みが試行されましたが、着地しませんでした。一方は選択であり、他方は障害であるため、上記の行とは区別されます。 |
すべてのエンベロープは、ledger.pyによって追記専用のハッシュチェーンJSONLログに預託できます。MCP_RECEIPT_DIR（またはレガシーのMCP_RECEIPT_LOG）が設定されていない限りオフであり、ロギングの失敗は発生させるのではなく飲み込まれます。検索はその記録よりも重要です。シークレットは行が構成される前に編集されます。
スキーマ2.3.0以降、エンベロープはそれを明示します。レスポンスが預託されない場合、emit()は、変数が未設定の場合はRECEIPT_NOT_DEPOSITEDを、設定されていて書き込みが着地しなかった場合はRECEIPT_WRITE_FAILEDを追加します。そのギャップは、設定ファイルだけでなく、記録となる成果物に表示されます。mediation.deposit_enabled()は、要求に応じて同じ事実を報告します。
MCP_RECEIPT_DIR=C:\path\to\receipts # a folder, not a file
MCP_RECEIPT_SESSION=project-or-article-slug
MCP_RECEIPT_STRICT=1 # optional: make logging failure raise
MCP_RECEIPT_LOG=C:\path\to\receipts.jsonl # legacy single file; ignored when _DIR is setフォルダ1つ、サーバーごとにファイル1つ。 MCP_RECEIPT_DIRはディレクトリを指し、
各サーバーはその中に独自の<server>.jsonlを書き込みます。これは整理整頓ではありません。
追記は「最後のハッシュを読んでから書き込む」であり、その周りのロックはスレッドロックです。
これは1つのプロセス内で保持され、複数のプロセス間では保持されません。6つのサーバーは
6つのプロセスであり、同時に応答する2つは同じ先行者を読み取り、両方ともそれを主張します。
測定されたものであり、理論ではありません。6つのプロセスが1つのファイルに150行を書き込むと、
14のフォークが生成されました。MCP_RECEIPT_LOGは引き続き機能し、単一のサーバーでは正しいままです。
ファミリーにとっては間違った形です。
install.ps1はこれらすべてを6つすべてに設定し、フォルダにREADMEを書き込みます。
1つのチェーン、またはフォルダ全体を検証します：
cinii-mcp-ledger verify receipts/cinii.jsonl
cinii-mcp-ledger verify-dir receipts
cinii-mcp-ledger manifest receipts # writes receipts/manifest.jsonverifyは失敗時に非ゼロで終了し、見つかった種類を報告します：フォーク（同時書き込み — 設定の欠陥であり、すべての行はまだ存在します）、欠落行、並べ替え、または改ざん（自身の内容にハッシュ化されない行）。最後のものだけが誠実さに関する主張であり、それらを同様に報告すると、読者が一方を他方と誤解する恐れがあります。マニフェストは引用する対象です。預託全体の1つの説明 — ファイルごとの行数、最初と最後のタイムスタンプ、終端ハッシュ、およびサーバー、スクリプト、セッションごとの合計。
PATHにPython 3.10以上。
CiNii Web APIのアプリケーションID（appid）— 無料。必須。
CiNii Research APIを使用するには、登録済みのアプリケーションIDが必要で、すべてのリクエストでパラメータとして送信されます。
CiNii Web API開発者登録ページで登録し、アプリケーションIDを取得します。
NIIのAPI規約に同意します：学術コンテンツサービス利用規約、CiNii Research利用細則、学術コンテンツサービスWeb API利用細則。
商用利用の場合は、申請前にciniiadm@nii.ac.jpにメールで連絡してください。
同じアプリケーションIDは、cinii_search_kakenが使用するKAKEN APIでも機能します。
このパッケージはcinii-mcpコンソールスクリプトをインストールします。名前空間化されているため、このサーバーファミリーの残りと1つの環境を共有できます。
python3 -m venv .venv
.venv/bin/pip install .Windowsの場合：
py -3.11 -m venv .venv
.venv\Scripts\pip.exe install .または、クローンせずにリポジトリから直接：
uvx --from "git+https://github.com/ckgerteis/cinii-mcp" cinii-mcpインストールを確認します：
.venv/bin/python -c "import cinii_mcp; print(cinii_mcp.__version__)"パッケージまたはそのベンダリングされたモジュールの1つが欠落している場合、これは大きな音を立てて失敗します。チェックとしてcinii-mcp --helpを使用しないでください。不明な引数は無視され、サーバーが起動し、入力の終わりを読み取って0で終了するため、コードの状態に関係なく成功を報告します。
6つの独立したパッケージ。どれも他をインポートせず、どれも他に依存せず、それぞれが単独でインストールして応答します。このディレクトリでのpip install .は、このサーバーとそれ以外の何もない完全なインストールです。
ただし、3つのものを共有しています：レスポンスエンベロープ、クエリ台帳、そして複数を実行する場合はレシートフォルダ。install.ps1は6つすべてにバイト単位で同一にベンダリングされており、それを処理します。デフォルトでこのサーバーをインストールします。1つのリポジトリをクローンすることは、さらに5つを要求することではないからです。
.\install.ps1 # this server
.\install.ps1 -All # all six
.\install.ps1 -Servers cinii,cinii # a chosen subset名前を付けたサブセットは、1つのレシートフォルダに対して1回だけ要求され、登録されます。スクリプトはネットワークよりも兄弟チェックアウトを優先し、既に登録されている資格情報を再度尋ねるのではなく引き継ぎ、要求されなかったサーバーには触れず、既に登録されているサーバーがフォルダまたはセッションスラッグについて異なる場合、推測するのではなく停止します。また、インストールしたすべてのものにわたってledger.pyとmediation.pyがバイト単位で同一であることをアサートするため、2つのエンベロープバージョンが1つの環境に気付かれずに存在することはありません。
サーバーはCINII_APPID環境変数からアプリケーションIDを読み取ります。サンプルファイルをコピーして記入してください（実際の値をコミットしないでください）：
cp .env.example .envCINII_APPID=your_application_id_here%APPDATA%\Claude\claude_desktop_config.jsonのmcpServersの下にエントリを追加し、インストールした環境のコンソールスクリプトを指すようにします。macOSまたはLinuxでは、.venv/bin/cinii-mcpへの絶対パスを使用します。
{
"mcpServers": {
"cinii": {
"command": "C:\\path\\to\\.venv\\Scripts\\cinii-mcp.exe",
"env": {
"CINII_APPID": "your_application_id_here"
}
}
}
}3.0.0で変更されました。 以前のバージョンはパスで登録されていました — "command": "…\\python.exe", "args": ["…\\server.py"]。そのエントリはこのバージョンを起動しません。server.pyは現在、インポートの隣にあるスクリプトではなく、パッケージ内のモジュールだからです。上記のコンソールスクリプトに置き換えてください。
Claude Desktopを再起動します。7つのツールがツールリストの「cinii」の下に表示されるはずです。
NIIは利用規則を施行しています。違反すると、アクセスがブロックされたり、登録が取り消されたりする可能性があります。このサーバーは、すべてのリクエストでappidを送信し（必須）、規則を尊重するように設計されていますが、使用についてはお客様が責任を負います：
短時間に大量のリクエストを送信しないでください。他のユーザーに影響を与える過剰なアクセスは、予告なくブロックされる場合があります。
appid はAPIリクエスト専用です。CiNiiページへのユーザー向けリンクに公開しないでください。
NIIの規約に従い、取得したデータを使用する際は著作権を尊重してください。
このソフトウェアが研究に役立つ場合は、引用してください。CITATION.cff を参照するか、GitHubの「Cite this repository」ボタンを使用してください。
MIT © 2026 Christopher Gerteis.
このライセンスはサーバーコードのみを対象としています。CiNiiデータまたはCiNii APIに対する権利は付与されません。これらは上記のNIIの利用規約に従います。
研究ツールであり、ベストエフォート方式で保守され、「現状のまま」提供され、保証はありません。国立情報学研究所とは提携しておらず、その承認も受けていません。
Dr Christopher Gerteis、ロンドン大学SOAS。データ提供: CiNii Research、国立情報学研究所。
Fetch a single CiNii record by URL or CRID. Returns the unified envelope (operation 'get_record').
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, covering the safety profile. The description adds value by stating the return envelope format (operation 'get_record'), which is not in annotations. No contradiction; it contextually enriches what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences: the first states the action and input, the second the expected output. Front-loaded with the core purpose and no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-record fetch with a straightforward input and an output schema provided, the description covers the essential behavior. It mentions the envelope and the operation. The only omission is potential error handling or edge cases, but given the output schema and annotations, it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% because the tool description does not discuss parameters. The single parameter 'record_url' is described in the schema as 'Full CiNii URL or CRID', but the description does not compensate for the low coverage. It adds nothing beyond the schema, so the agent must rely solely on the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch'), a resource ('single CiNii record'), and the two identifier forms ('by URL or CRID'), which clearly distinguishes it from the sibling search tools (cinii_search_*). It also notes the return envelope with operation 'get_record', making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you need a specific URL or CRID, which differentiates it from the search siblings. However, it does not explicitly say 'use this when you have an identifier' nor name the alternatives. The context of siblings makes it clear enough, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-type search across all CiNii content. Returns the unified envelope.
Records are emitted with record_type 'article' as a default; the cross search mixes types and CiNii does not always disambiguate them in the OpenSearch response.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the annotations: records default to record_type 'article', mixed types are not always disambiguated, and a unified envelope is returned. This is exactly the kind of caveat an agent needs before relying on the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose first, then output envelope, then the critical record_type caveat. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema and annotations cover return shape and safety, and the description covers the important cross-type ambiguity. Parameter semantics are missing from the description, but the schema's property names, defaults, and constraints make invocation reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain query, lang, count, start, from_year, or to_year. With no parameter guidance in the description, it fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific operation: cross-type search across all CiNii content. 'All CiNii content' distinguishes this from the type-specific sibling tools without needing to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this for cross-type/all-content searching. It does not explicitly name alternatives or state when not to use it, but the scope is sufficiently explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search CiNii Research for journal articles. Returns the unified envelope.
CiNii matches catalogued metadata and ANDs a multi-word query, so an un-indexed compound returns zero even when related work exists — a ZERO_CONJUNCTION diagnostic marks this; vary the rendering rather than concluding the literature is absent. A SCRIPT_LATIN_QUERY diagnostic means the query searched romanized metadata only. The same string may behave very differently on J-STAGE (full text). Foundational monographs sit in cinii_search_books, not the article index.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety. The description adds substantial behavioral detail: it explains the ANDing of multi-word queries, the ZERO_CONJUNCTION diagnostic suggesting the query may be unindexed, the SCRIPT_LATIN_QUERY diagnostic for romanized-only searches, and the difference from J-STAGE full-text searching. This goes well beyond the annotations and gives the agent critical insights for interpreting results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs. The first sentence states the purpose and return envelope. The second paragraph packs three sentences of useful caveats. It is front-loaded with the core purpose and each subsequent sentence earns its place by clarifying search behavior or pointing to the right sibling tool. There is no fluff or repetition, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavioral quirks that could lead an agent astray (zero results, romanized search, J-STAGE differences) and routes monographs to the correct tool. It does not explain the 'unified envelope' return format, but an output schema exists so that is acceptable. It also does not detail pagination or sorting semantics, but those are likely standard and inferable from the schema. The description is sufficient for effective use given the existing schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a description for the 'query' parameter, but the overall schema coverage is low (0% per signals, though query has a description). The description compensates by explaining how the query is interpreted (ANDs multi-word queries, may hit romanized metadata), which directly affects how to construct the query. It does not explain other parameters like sort, count, or filters, but those are standard and have defaults. Given the low coverage, the description adds meaningful semantic value for the most critical parameter, so a 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search CiNii Research for journal articles' — a specific verb and resource, clearly distinguishing it from the other CiNii tools. It also explicitly notes that monographs belong in cinii_search_books, reinforcing the boundary to sibling tools. This is unambiguous and immediately tells an agent what the tool does and what it does not cover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use context: it tells the agent that the article index is for journal articles and that monographs should be searched in cinii_search_books. It also warns about behavioral differences from J-STAGE, which helps the agent decide if this is the right search. However, it does not explicitly name all alternatives (e.g., cinii_search_all) nor provide a comprehensive when-not-to-use list, so it slightly lacks in guiding against other nearby tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search CiNii Research for books and monographs. Returns the unified envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide safety information (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds only the phrase 'Returns the unified envelope', which hints at the output format but is redundant given the output schema exists. It does not add behavioral context such as pagination limits, potential delays, or any special handling. Since annotations are present, the bar is lower, but the description still contributes almost nothing beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that is easy to read. It is appropriately sized for a simple search tool, but it is overly sparse — it does not elaborate on scope or usage. It is concise without being informative, so it earns a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a rich schema with 10 parameters and is part of a family of similar search tools, the description is insufficient. It does not mention which parameters to use for common scenarios, does not clarify the 'unified envelope' output structure beyond the schema, and omits any guidance on how this tool differs from its siblings. The presence of an output schema covers return format but not usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the description does not explain any of the parameters (query, isbn, title, author, etc.). While some parameter names are self-explanatory, the description offers no guidance on how they interact or which are mutually exclusive. With low coverage, the description must compensate, but it does not, leaving the agent to rely on the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and a clear resource ('CiNii Research for books and monographs'). It implicitly differentiates from sibling search tools by specifying 'books and monographs', which is distinct from articles, dissertations, and researchers. However, it does not explicitly name a sibling or contrast them, so a 4 is appropriate rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention that this is the tool for book/monograph searches or that other tools are for different document types. No prerequisites, exclusions, or alternative tools are referenced, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search CiNii Research for doctoral dissertations. Returns the unified envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly, openWorld, idempotent, and non-destructive behavior, so the description need not repeat those. However, the only additional behavioral information, 'Returns the unified envelope,' is cryptic and unexplained, leaving the agent unsure about the actual output structure. This adds little transparent value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (a single sentence), so it is concise in word count, but that brevity comes at the cost of essential detail. It lacks any structure (e.g., bullets, sections) to organize information, and the sentence itself is too terse to be complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and a 7-field nested input schema, the description provides almost no context. It does not explain how to form queries, what the 'unified envelope' contains, or how filters work. An agent cannot confidently call this tool without additional documentation, making it severely inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description has the full burden of explaining parameters. It mentions none of the seven parameters (lang, count, query, start, author, to_year, from_year) nor their meaning. The agent must rely solely on field titles and defaults, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search'), the resource ('CiNii Research'), and the specific scope ('doctoral dissertations'). It inherently distinguishes itself from sibling tools that target articles, books, researchers, etc., through the explicit mention of dissertations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the alternative search tools (e.g., cinii_search_all, cinii_search_articles). The use case is only implied by the tool name and scope, with no explicit 'use this when' or 'for other content types use...' instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search KAKEN (科研費) research projects. Returns the unified envelope (record_type 'project').
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and side-effect expectations. The description adds that it returns the unified envelope with record_type 'project', which is a useful behavioral detail. However, it doesn't disclose pagination behavior, result ordering, or potential rate limits. With annotations covering the main traits, the added value is modest but non-trivial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the core purpose and the key return-type detail efficiently, which is ideal for an AI agent that needs to quickly parse tool intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has multiple optional parameters and 0% schema coverage, the description is under-specified. It doesn't explain how to construct a valid query, how filters interact, or any constraints. An output schema exists but is not visible in the prompt; the description only hints at the return envelope. An agent would likely need to inspect the schema or make trial calls to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the meaning of parameters like query, lang, count, start, from_year, to_year, researcher, and institution. The description only mentions the search action and return type, providing no explanation of how to use the filters. Field names are self-explanatory to some degree, but without any description guidance, an agent may not know parameter formats or combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and a clear resource ('KAKEN research projects'), and it distinguishes itself from sibling search tools by specifying the record_type 'project' in the unified envelope. This makes the tool's purpose unambiguous even without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for KAKEN projects but does not explicitly contrast with alternatives such as cinii_search_articles or cinii_search_all. There is no 'use this when' or 'not for' guidance. The sibling list is provided in context but the description itself doesn't reference it, so an agent must infer when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for researchers in CiNii. Returns the unified envelope (record_type 'researcher').
Note: researcher affiliation is not carried by the record schema; the researcher name occupies the title field and the profile URL the ids.url_ja field.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds a useful, non-obvious note about field mapping (name in title, profile URL in ids.url_ja) that goes beyond the schema. No contradictions; the note clarifies result interpretation without repeating annotation information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence followed by a clearly separated note. The main purpose is front-loaded, and the note is relevant without bloating the text. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema has no parameter descriptions and the tool has multiple parameters (query, institution, pagination controls), the description is incomplete. The field-mapping note is helpful, but it doesn't cover parameter semantics or usage context. An agent would need to infer most functional details from parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the parameters (query, lang, count, start, institution). The tool requires more than one parameter in practice (via the nested 'params' object), yet the description provides no semantic help, leaving the agent to guess from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for researchers in CiNii' with a specific verb and resource, and mentions the record_type 'researcher'. It differentiates from siblings like cinii_search_articles by resource type, though it doesn't explicitly name alternatives. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus cinii_search_all or other sibling search tools. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each search tool explicitly targets a distinct content type (articles, books, dissertations, KAKEN projects, researchers, and a cross-type search), with no overlap in purpose. The get_record tool is clearly separate as a single-record fetcher by URL or CRID.
All tools follow the identical pattern 'cinii_search_<type>' for searches, plus 'cinii_get_record' for retrieval, maintaining consistent snake_case and verb-noun ordering throughout.
Seven tools is well-scoped for a literature search MCP server, covering the major CiNii content types without redundancy or unnecessary bloat. Each tool earns its place.
The surface covers all primary search categories (articles, books, dissertations, KAKEN, researchers) plus an all-search and a record fetch, leaving no obvious gaps for the stated purpose of querying CiNii Research.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
Citable retrieval across papers, books, patents, Wikipedia, and live social sources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ckgerteis/cinii-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
