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: article-mcp
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 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
