一个 FastMCP stdio 服务器，将 CiNii Research API — 日本国家学术数据库，由国立情报学研究所（NII）运营 — 以七个工具的形式提供给 Claude Desktop 和其他 MCP 客户端使用。
CiNii Research 聚合了来自 KAKEN、CiNii Articles、CiNii Books、IRDB、Crossref、DataCite、PubMed 和 NDL Search 的元数据。目前没有成熟的开放 MCP 工具支持它，因此这个服务器填补了研究人员查询日语学术文献的空白。
CiNii Research 索引了五种类型的日语学术记录，这个服务器将所有这些记录带入 Claude 对话中：期刊论文、图书和专著、博士论文、KAKEN 科研费资助项目、研究人员简介，以及通过 CRID 进行的单条记录查询。用英语提问，得到日语学术文献，实际发送的日语术语会与结果一起显示。
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 文本；这是一个破坏性变更，而非格式偏好。）
每个工具返回一个 JSON 响应信封，由 mediation.py 构建，定义于 response-schema.json。Schema 版本 2.3.0。同一模块和 schema 在服务器家族中以字节完全相同的方式内置，因此一个服务器的信封可以被为另一个服务器编写的消费者读取。
信封报告的是搜索是如何进行的，而不仅仅是找到了什么：
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），否则默认关闭，日志记录失败会被吞掉而不是抛出——搜索比记录更重要。在组成一行之前，机密信息会被脱敏。
自 schema 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一个文件夹，每个服务器一个文件。 MCP_RECEIPT_DIR 指向一个目录，每个服务器在其中写入自己的 <server>.jsonl。这不是为了整洁。追加操作是先读最后一个哈希再写入，而围绕它的锁是线程锁，只在单个进程内有效，不跨多个进程——六个服务器是六个进程，两个同时响应的服务器会读取同一个前驱并都声称拥有它。这是实测而非理论：六个进程向一个文件写入 150 行产生了十四个分叉。MCP_RECEIPT_LOG 仍然可用，对单个服务器仍然正确；但对一个家族来说形状不对。
install.ps1 为全部六个服务器设置此配置，并在文件夹中写入一个 README。
验证一条链，或整个文件夹：
cinii-mcp-ledger verify receipts/cinii.jsonl
cinii-mcp-ledger verify-dir receipts
cinii-mcp-ledger manifest receipts # writes receipts/manifest.jsonverify 在失败时以非零退出码退出，并说明发现的类型：分叉（并发写入者——配置故障，但每一行仍然存在）、缺失行、重排，或篡改（一行无法哈希到其自身内容）。只有最后一种是对诚实性的断言，将它们同等报告会引导读者混淆两者。清单（manifest）是应引用的对象：对整个存入内容的一份描述——每个文件的行数、首尾时间戳、终端哈希，以及按服务器、文字体系和会话的合计总数。
Python 3.10+ 在 PATH 中。
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 控制台脚本。它是命名空间的，因此可以与这个服务器家族的其余部分共享一个环境。
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__)"如果包或其内置模块之一缺失，这会大声失败。不要使用 cinii-mcp --help 作为检查：未知参数会被忽略，服务器启动、读取输入结束并退出 0，因此无论代码状态如何都会报告成功。
六个独立包。没有一个导入另一个，没有一个依赖另一个，每个都独立安装和响应——在此目录中执行 pip install . 是对此服务器的完整安装，仅此而已。
它们确实共享三样东西：响应信封、查询账本，以及——如果你运行多个——收据文件夹。install.ps1 以字节完全相同的方式内置到全部六个中，并处理这些。它默认安装此服务器，因为克隆一个仓库并不是对另外五个的请求。
.\install.ps1 # this server
.\install.ps1 -All # all six
.\install.ps1 -Servers cinii,cinii # a chosen subset无论你指定哪个子集，都会注册到一个收据文件夹，只询问一次。脚本优先使用同级检出而不是网络，沿用已注册的凭据而不是再次询问，不碰未被要求处理的服务器，并且在已注册的服务器对文件夹或会话 slug 意见不一致时停止而不是猜测。它还断言 ledger.py 和 mediation.py 在其安装的所有内容中字节完全相同，因此两个信封版本不可能在一个环境中不被察觉地共存。
服务器从 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。七个工具应出现在工具列表中的 "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 University of London）。数据由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
