Ein FastMCP-stdio-Server, der die CiNii Research API — Japans nationale akademische Datenbank, betrieben vom National Institute of Informatics (NII) — als sieben Tools für die Verwendung mit Claude Desktop und anderen MCP-Clients bereitstellt.
CiNii Research aggregiert Metadaten aus KAKEN, CiNii Articles, CiNii Books, IRDB, Crossref, DataCite, PubMed und NDL Search. Es gibt kein etabliertes offenes MCP-Tooling dafür, daher schließt dieser Server diese Lücke für Forscher, die japanischsprachige Wissenschaft abfragen.
CiNii Research indexiert japanische Wissenschaft über fünf Arten von Datensätzen, und dies bringt alle in eine Claude-Konversation: Zeitschriftenartikel, Bücher und Monografien, Doktorarbeiten, KAKEN-Förderprojekte und Forscherprofile, plus Einzeldatensatz-Abfrage per CRID. Stellen Sie eine Frage auf Englisch und erhalten Sie japanischsprachige Wissenschaft zurück, wobei der tatsächlich gesendete japanische Begriff neben den Ergebnissen angezeigt wird.
KAKEN verdient besondere Aufmerksamkeit — es erfasst, was gefördert wurde, und bringt daher laufende Projekte, sich bildende Kooperationen und Forschung ans Licht, die einen Förderbericht erreichte, bevor sie im Druck erschien.
Jedes Ergebnis trägt den gesendeten Begriff, seine Schrift, wie CiNii ihn abgeglichen hat, und eine Quittung, die die Abfrage fixiert, sodass eine Suche, die hinter einer Fußnote steht, benannt, zitiert und von jemand anderem erneut ausgeführt werden kann.
Related MCP server: CiNii MCP Server
Tool | Zweck |
| Zeitschriftenartikel (JALC, Crossref, PubMed, IRDB) |
| Bücher und Monografien (NACSIS-CAT, NDL Search) |
| Doktorarbeiten japanischer Universitäten |
| KAKEN (科研費) geförderte Forschungsprojekte |
| Typübergreifende Suche über alle Inhaltstypen |
| Forscherprofile und Zugehörigkeiten |
| Einzeldatensatz-Abfrage per URL oder CRID |
Ergebnisse stammen aus der CiNii Research OpenSearch v2 API als JSON-LD und werden als ein typisierter JSON-Antwortumschlag zurückgegeben — siehe Antwortformat unten. (Versionen vor v2.0.1 gaben formatierten Markdown-Text zurück; das ist eine breaking change, keine Formatierungspräferenz.)
Jedes Tool gibt einen JSON-Antwortumschlag zurück, erstellt von mediation.py und definiert in response-schema.json. Schema-Version 2.3.0. Dasselbe Modul und Schema sind byte-identisch über die Serverfamilie hinweg gebündelt, sodass ein Umschlag von einem Server von einem Client gelesen werden kann, der für einen anderen geschrieben wurde.
Der Umschlag berichtet, wie die Suche durchgeführt wurde, nicht nur, was sie gefunden hat:
searched_for — bei Suchvorgängen der tatsächlich gesendete Begriff, seine erkannte Schrift und der Abgleichmodus, an die Spitze des Umschlags gehoben, damit ein weiterleitender Client ihn nicht fallen lassen kann. Abrufvorgänge (cinii_get_record) lassen ihn weg: Sie erhielten eine Kennung und wählten keinen Begriff.
query — input_terms wie geliefert, normalized wie gesendet und die erkannte script. Dieses Paar ist die Aufzeichnung jeder Umsetzung, die zwischen der Sprache des Aufrufers und dem Korpus stattgefunden hat.
matching_mode — metadata_conjunction für diesen Server. Es sagt Ihnen, wie result.total zu lesen ist.
result.breadth — none, narrow (1–50), broad (51–1000), very_broad (>1000). Schwellenwerte sind bewusst niedrig: ein paar hundert Treffer, die wie eine Literatur aussehen, werden markiert, statt ungeprüft durchgereicht zu werden.
items[].matched_in — in welchem Feld der Abgleich pro Datensatz erfolgte.
receipt — ein ISO-8601-Zeitstempel, ein SHA-256 über die normalisierte Abfrage und ihre Parameter sowie die zurückgegebenen Kennungen. Der Hash verifiziert einen Begriff, den Sie bereits besitzen; er kann nicht umgekehrt werden, um einen zu erzeugen, also ist die Einheit der Hinterlegung der Umschlag, nicht die Quittung.
attribution — die erforderliche Quellenangabe, in jeder Antwort.
Typisiert und geschlossen. Eine Diagnose ist niemals Prosa, die der Client parsen muss.
Code | Stufe | Bedeutung |
| info | Datensätze zurückgegeben; nichts zu melden. |
| warning | Keine Datensätze. CiNii gleicht katalogisierte Metadaten ab und verknüpft eine mehrwortige Abfrage mit UND, sodass eine nicht indexierte Zusammensetzung null zurückgibt, selbst wo verwandte Arbeit existiert. Variieren Sie die Umsetzung, bevor Sie schlussfolgern, die Literatur fehle. |
| warning | Die Abfrage war in lateinischer Schrift, also hat sie nur romanisierte und englische Metadaten abgeglichen. Die japanische Schriftform erreicht ein anderes, größeres Korpus. |
| error | Die API hat geantwortet, und zwar mit einem Fehler. |
| error | Die Anfrage wurde nicht abgeschlossen. Von |
| info | Die Antwort wurde nicht in das Abfrageprotokoll geschrieben, weil kein Quittungsziel konfiguriert ist. Die Suche ist davon unberührt; keine Quittung überlebt sie. |
| warning | Ein Quittungsziel ist gesetzt, der Schreibvorgang wurde versucht und ist nicht angekommen. Unterscheidet sich von der Zeile oben, weil das eine eine Wahl und das andere ein Fehler ist. |
Jeder Umschlag kann von ledger.py in ein append-only, hash-verkettetes JSONL-Protokoll hinterlegt werden. Es ist aus, außer MCP_RECEIPT_DIR (oder das veraltete MCP_RECEIPT_LOG) ist gesetzt, und ein Protokollierungsfehler wird verschluckt statt ausgelöst — eine Suche ist wichtiger als die Aufzeichnung davon. Geheimnisse werden redigiert, bevor eine Zeile erstellt wird.
Seit Schema 2.3.0 sagt der Umschlag das. Wenn eine Antwort nicht hinterlegt wird, hängt emit() RECEIPT_NOT_DEPOSITED an, wenn die Variable nicht gesetzt ist, oder RECEIPT_WRITE_FAILED, wenn sie gesetzt ist und der Schreibvorgang nicht landete. Die Lücke ist dann in dem Artefakt sichtbar, das zur Aufzeichnung wird, statt nur in einer Konfigurationsdatei. mediation.deposit_enabled() meldet dieselbe Tatsache auf Anfrage.
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 setEin Ordner und eine Datei pro Server. MCP_RECEIPT_DIR zeigt auf ein Verzeichnis,
und jeder Server schreibt seine eigene <server>.jsonl darin. Das ist keine Ordnungsliebe.
Anhängen bedeutet letzter-Hash-lesen-dann-schreiben, und die Sperre darum ist eine Thread-Sperre,
die innerhalb eines Prozesses gilt und nicht zwischen mehreren — sechs Server sind
sechs Prozesse, und wenn zwei gleichzeitig antworten, lesen beide denselben
Vorgänger und beide beanspruchen ihn. Gemessen, nicht theoretisiert: sechs Prozesse, die 150
Zeilen in eine Datei schreiben, erzeugten vierzehn Verzweigungen. MCP_RECEIPT_LOG funktioniert weiterhin und ist
für einen einzelnen Server weiterhin korrekt; es ist die falsche Form für eine Familie.
install.ps1 richtet dies für alle sechs ein und schreibt eine README in den Ordner.
Überprüfen Sie eine Kette oder den gesamten Ordner:
cinii-mcp-ledger verify receipts/cinii.jsonl
cinii-mcp-ledger verify-dir receipts
cinii-mcp-ledger manifest receipts # writes receipts/manifest.jsonverify beendet sich bei einem Fehler mit einem Nicht-Null-Status und sagt, welche Art es gefunden hat: eine Verzweigung (gleichzeitige Schreiber — ein Konfigurationsfehler, und jede Zeile ist trotzdem noch da), eine fehlende Zeile, eine Umordnung oder Manipulation (eine Zeile, die nicht auf ihren eigenen Inhalt hasht). Nur das Letzte ist eine Aussage über Ehrlichkeit, und sie gleich zu melden würde einen Leser einladen, das eine mit dem anderen zu verwechseln. Das Manifest ist das Objekt, das zu zitieren ist: eine Beschreibung der gesamten Hinterlegung — Zeilenzahlen pro Datei, erste und letzte Zeitstempel, End-Hashes und kombinierte Summen nach Server, Schrift und Sitzung.
Python 3.10+ im PATH.
Eine CiNii Web API Anwendungs-ID (appid) — kostenlos; erforderlich.
Die CiNii Research API erfordert eine registrierte Anwendungs-ID, die bei jeder Anfrage als Parameter gesendet wird.
Registrieren Sie sich auf der Seite CiNii Web API Developer Registration und erhalten Sie Ihre Anwendungs-ID.
Stimmen Sie den API-Bestimmungen des NII zu: den Nutzungsbestimmungen für den Academic Content Service, den detaillierten Nutzungsbestimmungen für CiNii Research und den detaillierten Nutzungsbestimmungen für die Academic Content Service Web API.
Für kommerzielle Nutzung senden Sie vor der Bewerbung eine E-Mail an ciniiadm@nii.ac.jp.
Dieselbe Anwendungs-ID funktioniert auch für die KAKEN API, die cinii_search_kaken verwendet.
Das Paket installiert ein cinii-mcp-Konsolenskript. Es ist namespaced, sodass es
eine Umgebung mit dem Rest dieser Serverfamilie teilen kann.
python3 -m venv .venv
.venv/bin/pip install .Unter Windows:
py -3.11 -m venv .venv
.venv\Scripts\pip.exe install .Oder direkt aus dem Repository, ohne Klonen:
uvx --from "git+https://github.com/ckgerteis/cinii-mcp" cinii-mcpÜberprüfen Sie die Installation:
.venv/bin/python -c "import cinii_mcp; print(cinii_mcp.__version__)"Das schlägt laut fehl, wenn das Paket oder eines seiner gebündelten Module fehlt. Verwenden Sie
cinii-mcp --help nicht als Prüfung: unbekannte Argumente werden ignoriert, der
Server startet, liest das Dateiende und beendet sich mit 0, also meldet er Erfolg, egal
in welchem Zustand der Code ist.
Sechs unabhängige Pakete. Keines importiert ein anderes, keines hängt von einem anderen ab, und
jedes installiert und antwortet für sich — pip install . in diesem Verzeichnis ist eine
vollständige Installation dieses Servers und sonst nichts.
Sie teilen sich drei Dinge: einen Antwortumschlag, ein Abfrageprotokoll und — wenn Sie
mehr als eines ausführen — einen Quittungsordner. install.ps1 ist byte-identisch
in alle sechs gebündelt und übernimmt das. Es installiert standardmäßig diesen Server,
weil das Klonen eines Repositorys keine Anfrage nach fünf weiteren ist.
.\install.ps1 # this server
.\install.ps1 -All # all six
.\install.ps1 -Servers cinii,cinii # a chosen subsetWelche Teilmenge Sie auch nennen, sie wird gegen einen Quittungsordner registriert, einmal
abgefragt. Das Skript bevorzugt einen Schwester-Checkout gegenüber dem Netzwerk, übernimmt
bereits registrierte Anmeldedaten, statt erneut zu fragen, lässt Server, nach denen es nicht
gefragt wurde, in Ruhe und stoppt, statt zu raten, wo die bereits registrierten Server
bezüglich des Ordners oder des Sitzungs-Slugs uneins sind. Es stellt außerdem sicher, dass
ledger.py und mediation.py byte-identisch über alles sind, was es
installiert hat, sodass nicht unbemerkt zwei Umschlagversionen in einer Umgebung landen können.
Der Server liest Ihre Anwendungs-ID aus der Umgebungsvariablen CINII_APPID. Kopieren Sie die Beispieldatei und füllen Sie sie aus (committen Sie niemals den echten Wert):
cp .env.example .envCINII_APPID=your_application_id_hereFügen Sie einen Eintrag in %APPDATA%\Claude\claude_desktop_config.json unter
mcpServers hinzu, der auf das Konsolenskript in der Umgebung zeigt, in die Sie
installiert haben. Unter macOS oder Linux verwenden Sie den absoluten Pfad zu .venv/bin/cinii-mcp.
{
"mcpServers": {
"cinii": {
"command": "C:\\path\\to\\.venv\\Scripts\\cinii-mcp.exe",
"env": {
"CINII_APPID": "your_application_id_here"
}
}
}
}Geändert in 3.0.0. Frühere Versionen wurden per Pfad registriert —
"command": "…\\python.exe", "args": ["…\\server.py"]. Dieser Eintrag wird diese
Version nicht starten, weil server.py jetzt ein Modul innerhalb eines Pakets ist, statt
ein Skript neben seinen Importen. Ersetzen Sie ihn durch das obige Konsolenskript.
Starten Sie Claude Desktop neu. Die sieben Tools sollten unter „cinii" in der Werkzeugliste erscheinen.
NII setzt Nutzungsregeln durch; deren Verletzung kann dazu führen, dass Ihr Zugriff blockiert oder Ihre Registrierung storniert wird. Dieser Server sendet Ihre appid bei jeder Anfrage (erforderlich) und ist darauf ausgelegt, die Regeln zu respektieren, aber Sie bleiben für die Nutzung verantwortlich:
Senden Sie nicht innerhalb kurzer Zeit eine hohe Anzahl von Anfragen. Übermäßiger Zugriff, der andere Nutzer beeinträchtigt, kann ohne Vorankündigung blockiert werden.
Die appid ist ausschließlich für API-Anfragen bestimmt; geben Sie sie nicht in für Nutzer sichtbaren Links zu CiNii-Seiten preis.
Beachten Sie bei der Nutzung der abgerufenen Daten das Urheberrecht gemäß den Bestimmungen von NII.
Wenn diese Software Ihre Forschung unterstützt, zitieren Sie sie bitte. Siehe CITATION.cff oder verwenden Sie die Schaltfläche „Dieses Repository zitieren“ auf GitHub.
MIT © 2026 Christopher Gerteis.
Diese Lizenz erstreckt sich nur auf den Servercode. Sie gewährt keine Rechte an den CiNii-Daten oder an der CiNii-API; beide unterliegen weiterhin den oben verlinkten Bedingungen von NII.
Ein Forschungswerkzeug, das nach bestem Bemühen gepflegt und „wie besehen“ ohne Gewährleistung bereitgestellt wird. Weder mit dem National Institute of Informatics verbunden noch von ihm unterstützt.
Dr Christopher Gerteis, SOAS University of London. Daten bereitgestellt von CiNii Research, National Institute of Informatics.
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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that it returns the unified envelope with operation 'get_record', which is mild context, but says nothing about error behavior for a bad CRID, unknown URLs, or result size.
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 short sentences, front-loaded with the action and resource. The second sentence about the envelope is partly redundant given a full output schema exists, keeping it from a 5.
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 one-parameter read tool with annotations and an output schema present, the description covers the essentials: what it fetches, the input formats accepted, and the return envelope. Only failure modes and CRID format details are missing.
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 reported as 0% for the single parameter, so the description must carry some weight; it does clarify that either a full URL or a CRID is accepted. However, it gives no format examples, no valid CRID pattern, and no guidance on the 2000-character limit.
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?
States a specific verb and resource ('Fetch a single CiNii record') and distinguishes itself from the search siblings by emphasizing a single record looked up by URL or CRID rather than a query. It does not name a sibling explicitly, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent infers this is the follow-up call after a search returns a record URL/CRID. There is no explicit statement of when to prefer it over re-searching, and no note about what to do if the lookup fails.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds non-obvious behavioral context: it returns a unified envelope and may emit records with a default record_type of 'article' because CiNii does not always disambiguate mixed types.
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 three tight sentences: purpose first, return envelope second, and a key caveat third. There is no filler, and the important type-disambiguation warning is front-loaded enough to be useful.
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?
Annotations cover safety behavior and an output schema exists, so the description needn't explain return values in full. However, with 0% schema description coverage, the missing parameter guidance and lack of explicit sibling routing leave meaningful gaps for correct invocation.
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 undocumented parameters, but it says nothing about query syntax, lang, count limits, start/pagination, or from_year/to_year filtering. The parameter names are mostly self-explanatory, but semantic meaning is left largely to inference.
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 and resource: 'Cross-type search across all CiNii content.' The word 'all' implicitly distinguishes it from the type-specific sibling tools, though it does not explicitly name them.
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 phrase 'across all CiNii content' implies this tool is for broad, cross-type queries, but the description gives no explicit when-to-use guidance, exclusions, or named alternatives such as cinii_search_articles or cinii_search_books.
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 readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: AND-semantics across catalogue metadata, two named diagnostics (ZERO_CONJUNCTION, SCRIPT_LATIN_QUERY), and a pointer to the unified envelope return shape.
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?
Front-loaded with the core purpose, then layered diagnostics and scope boundaries. Dense but nearly every sentence carries distinct information; the em-dash clause about ZERO_CONJUNCTION is slightly compressed but earns its space.
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?
Output schema exists, so omitting return-value detail is fine, and the diagnostic behavior is well covered. However, a tool with eleven optional filter fields whose 0% schema coverage leaves them undocumented needs the description to say more about what those filters do to results.
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 only illuminates the query parameter (multi-word AND behavior, romanized metadata). It says nothing about the title, author, journal, from_year/to_year, data_source, lang, sort, count, or start fields, which are the bulk of the input object.
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?
States a specific verb and resource (search CiNii Research for journal articles) and explicitly excludes the sibling cinii_search_books ('Foundational monographs sit in cinii_search_books, not the article index'). It also contrasts against J-STAGE, so an agent can route queries without opening any 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?
Gives concrete when-to guidance: a zero result from a compound query should prompt re-rendering rather than a conclusion that literature is absent, and monograph searches belong to cinii_search_books. It stops short of explicit routing guidance against cinii_search_all or cinii_search_dissertations, which are also siblings.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds only that it 'Returns the unified envelope,' which is vague and adds little behavioral context beyond what the annotations and output schema already provide.
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 sentences, front-loaded with the main action and resource. It is appropriately concise, though the phrase 'unified envelope' is jargon that does not earn much informational value.
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 tool has many search parameters, a nested input object, and no schema descriptions, so the description needs to compensate for parameter semantics and usage guidance. Instead it only names the resource, leaving significant gaps for correct invocation despite the presence of an output 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?
Schema description coverage is 0%, and the description says nothing about the many available filters (query, title, author, ISBN, year range, pagination, lang). It does not explain how required 'query' interacts with optional filters or what the parameters mean beyond their field names.
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 and resource ('Search CiNii Research for books and monographs'), making it distinguishable from the sibling article, dissertation, and researcher search tools. It does not explicitly name those alternatives, but the resource scope is clear.
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?
Usage is implied by the resource ('books and monographs'), but the description gives no explicit guidance on when to choose this over cinii_search_all or other sibling search tools, nor any prerequisites or exclusions. An agent can infer the use case but is not routed explicitly.
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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The one behavioral claim offered, 'Returns the unified envelope,' is undefined jargon that tells the agent nothing about result shape, matching behavior, or pagination.
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 short sentences with the purpose front-loaded and no filler. The second sentence is borderline waste, but overall size is appropriate.
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?
An output schema exists so return values need not be described, but with seven optional filters at 0% schema description coverage and no usage guidance, an agent cannot tell how to constrain or paginate the search from this description 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 actual inputs (query, lang, count, start, author, from_year, to_year). Field titles and defaults give partial self-documentation, but the description contributes zero semantic meaning for any parameter.
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?
States a concrete verb (Search) plus a specific resource scope (CiNii Research doctoral dissertations), which implicitly separates it from the sibling article/book/kaken/researcher searchers. It never explicitly names the sibling it replaces, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to pick this over cinii_search_all or the other typed searchers, no prerequisites, and no exclusions. The only hint is the resource name in the first sentence, which the agent must infer from.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that results use the unified envelope with record_type 'project', but it does not explain pagination, result ordering, query behavior, or filtering constraints beyond what the schema and annotations provide.
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 sentences with no wasted language, and the core purpose is front-loaded. It efficiently covers what the tool searches and the result envelope shape.
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?
This is a search tool with several meaningful filters and 0% schema description coverage, yet the description explains none of the filter semantics or query expectations. Although an output schema exists and the envelope note is useful, an agent lacks enough context to use the filters 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%, and the description adds no meaning for the nested KakenSearchInput fields such as query, lang, count, start, from_year, to_year, researcher, or institution. The schema exposes these parameters by name only, so the description does not compensate for the missing parameter documentation.
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 and resource: "Search KAKEN research projects." This clearly distinguishes the tool from siblings such as cinii_search_articles, cinii_search_books, cinii_search_dissertations, and cinii_search_researchers.
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 intended use is implied by the resource name, but the description gives no explicit when-to-use guidance or comparison to alternatives such as cinii_search_all or cinii_search_researchers. An agent can infer that this tool is for projects, but not when another tool would be preferable.
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 readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely useful structural disclosure beyond annotations: the unified envelope shape (record_type 'researcher') and the key caveat that affiliation is absent and name lives in title while profile URL is in ids.url_ja. This is real behavioral context an agent would otherwise miss.
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?
Front-loaded with the core purpose, followed by a compact and high-value note about record structure. No wasted sentences, though the note is slightly dense.
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?
An output schema exists, so return values needn't be fully explained. The description covers the essential caveats an agent needs (envelope type, affiliation absence, field placement). The main remaining gap is behavioral detail on pagination (start/count), which is minor given the rich schema constraints.
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 nested object has five fields (query, lang, count, start, institution) with no textual descriptions. The description says nothing about these parameters or their semantics, so it fails to compensate for the low coverage. The field-mapping note concerns output, not input parameters.
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?
States a specific verb and resource: 'Search for researchers in CiNii'. The 'record_type researcher' clarifies the return. It doesn't explicitly differentiate from siblings like cinii_search_articles or cinii_search_all, but the resource is distinct enough that selection is clear.
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?
Usage is only implied by the resource name 'researchers'. There is no explicit 'use this when...' guidance, no mention of when to prefer cinii_search_all or cinii_get_record, and no prerequisites. Adequate but with clear gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v3.2.0cinii_get_record1 field changedInput schema / $defs / RecordLookupInput / properties / record_url / maxLengthAdded value: +2000cinii_search_all1 field changedInput schema / $defs / CrossSearchInput / properties / query / maxLengthAdded value: +2000cinii_search_articles5 fields changedInput schema / $defs / ArticleSearchInput / properties / author / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / $defs / ArticleSearchInput / properties / data_source / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / $defs / ArticleSearchInput / properties / journal / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / $defs / ArticleSearchInput / properties / query / maxLengthAdded value: +2000Input schema / $defs / ArticleSearchInput / properties / title / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]cinii_search_books5 fields changedInput schema / $defs / BookSearchInput / properties / author / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / $defs / BookSearchInput / properties / isbn / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / $defs / BookSearchInput / properties / publisher / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / $defs / BookSearchInput / properties / query / maxLengthAdded value: +2000Input schema / $defs / BookSearchInput / properties / title / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]cinii_search_dissertations2 fields changedInput schema / $defs / DissertationSearchInput / properties / author / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / $defs / DissertationSearchInput / properties / query / maxLengthAdded value: +2000cinii_search_kaken3 fields changedInput schema / $defs / KakenSearchInput / properties / institution / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / $defs / KakenSearchInput / properties / query / maxLengthAdded value: +2000Input schema / $defs / KakenSearchInput / properties / researcher / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]cinii_search_researchers2 fields changedInput schema / $defs / ResearcherSearchInput / properties / institution / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2000,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / $defs / ResearcherSearchInput / properties / query / maxLengthAdded value: +2000v3.0.0cinii_get_recordcinii_search_allcinii_search_articlescinii_search_bookscinii_search_dissertationscinii_search_kakencinii_search_researchersScored across 7 tools
The six search tools are separated by clear content type (articles, books, dissertations, KAKEN, researchers, all), so an agent can generally pick the right one. The only mild overlap is cinii_search_all versus the type-specific searches, but its cross-type role is explicit.
All tools use a consistent cinii_ prefix followed by a predictable verb_noun pattern: search_<content-type> or get_record. There are no mixed conventions or vague names.
Seven tools is a well-scoped set for a search-oriented CiNii API. Each content type earns its own search tool, plus one cross-search and one record-fetch tool.
The surface covers the major CiNii Research content types—articles, books, dissertations, KAKEN projects, researchers—and includes cross-type search plus direct record retrieval by URL or CRID. No obvious retrieval operation is missing for this domain.
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.
Search and read the aicoolies catalog of AI and developer tools via a remote MCP knowledge graph.
