jstage-mcp
jstage-mcp
Ein FastMCP- Stdio-Server, der die J-STAGE WebAPI als drei Tools für die Verwendung mit Claude Desktop bereitstellt.
Wozu das dient
J-STAGE enthält die Volltexte von Zeitschriften, die von japanischen wissenschaftlichen Gesellschaften veröffentlicht werden, und dieses Tool durchsucht die Artikel selbst und nicht einen Katalog. Ein Begriff, den kein Katalogisierer als Schlagwort gewählt hat, ist dennoch auffindbar, wenn ein Autor ihn in einem Argument verwendet hat – das macht dies zum Weg für Konzepte, die zirkulieren, bevor sie benannt werden.
Lösen Sie eine J-STAGE-DOI direkt zu ihrem Datensatz auf, oder gehen Sie die Band- und Heftfolge einer Zeitschrift durch, um einen vollständigen Jahrgang zu sehen.
Führen Sie einen Begriff hier und auf cinii-mcp aus und lesen Sie die Differenz: Eine große Abweichung zeigt Ihnen, ob Ihre Terminologie zur Katalogbeschreibung gehört oder zur Prosa des Fachgebiets – ein Befund über die Literatur, bevor er ein Befund in ihr ist.
Related MCP server: Japan Data MCP
Tools
Tool | Zweck |
| Volltext-/Autoren-/Titel-/Zeitschriftensuche über J-STAGE-Artikel |
| Band- und Heftfolge für einen bekannten Titel, eine ISSN oder |
| Löst eine J-STAGE-DOI zum vollständigen Artikel-Datensatz auf |
Alle Tools geben ein typisiertes JSON-Antwort-Envelope mit zweisprachigen (Englisch/Japanisch) Titeln, Autoren und Zeitschriftennamen zurück, sofern J-STAGE sie liefert – siehe Antwortformat unten. Die JST-Namensnennungspflicht wird durch das attribution-Feld des Envelopes erfüllt, das in jeder Antwort enthalten ist.
Antwortformat
Jedes Tool gibt ein JSON-Antwort-Envelope zurück, das von mediation.py erstellt und in response-schema.json definiert ist. Schema-Version 2.3.0. Dasselbe Modul und dasselbe Schema sind byte-identisch über die Serverfamilie hinweg gebündelt, sodass ein Envelope von einem Server von einem Client gelesen werden kann, der für einen anderen geschrieben wurde.
Das Envelope 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 Envelopes gehoben, damit ein weiterleitender Client ihn nicht verwerfen kann. Abrufoperationen (jstage_get_article_by_doi,jstage_list_issues) lassen ihn weg: Sie haben eine Kennung erhalten und keinen Begriff gewählt.query—input_termswie angegeben,normalizedwie gesendet und das erkanntescript. Dieses Paar ist die Aufzeichnung jeder Umsetzung, die zwischen der Sprache des Aufrufers und dem Korpus vorgenommen wurde.matching_mode—full_text_broadfür diesen Server. Es sagt Ihnen, wieresult.totalzu lesen ist.result.breadth—none,narrow(1–50),broad(51–1000),very_broad(>1000). Die Schwellenwerte sind bewusst niedrig: ein paar hundert Treffer, die wie ein Literaturbestand wirken, werden markiert und nicht unbeanstandet durchgereicht.items[].matched_in— in welchem Feld der Treffer erzielt wurde, pro Datensatz.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 das Envelope, nicht der Beleg.attribution— die erforderliche Quellenangabe, in jeder Antwort.
Diagnosecodes
Typisiert und abgeschlossen. Eine Diagnose ist nie Prosa, die der Client parsen muss.
Code | Level | Bedeutung |
| info | Datensätze zurückgegeben; nichts zu beanstanden. |
| warning | Der Treffer wurde im Volltext erzielt, wo mehrteilige Begriffe lose abgeglichen werden, daher ist ein hoher |
| warning | Die Abfrage verwendete lateinische Schrift, daher wurden nur romanisierte und englische Metadaten abgeglichen. Führen Sie die Suche erneut in Kanji oder Kana aus. |
| warning | Keine Datensätze für diese Schreibweise. Versuchen Sie einen emischen oder Komponentenbegriff oder eine alternative japanische Schreibweise. |
| error | Die API hat geantwortet, und zwar mit einem Fehler. |
| error | Die Anfrage wurde nicht abgeschlossen. Von |
| info | Die Antwort wurde nicht in das Abfragejournal geschrieben, weil kein Belegziel konfiguriert ist. Die Suche ist davon nicht betroffen; es überlebt kein Beleg. |
| warning | Ein Belegziel ist gesetzt, der Schreibvorgang wurde versucht und ist nicht angekommen. Unterscheidet sich von der obigen Zeile, weil das eine eine Entscheidung und das andere ein Fehler ist. |
Abfragebelege
Jedes Envelope kann von ledger.py in ein Append-only-JSONL-Log mit Hash-Verkettung hinterlegt werden. Es ist aus, sofern nicht MCP_RECEIPT_DIR (oder das veraltete MCP_RECEIPT_LOG) gesetzt ist, und ein Protokollierungsfehler wird verschluckt statt ausgelöst – eine Suche ist wichtiger als ihre Aufzeichnung. Geheimnisse werden geschwärzt, bevor eine Zeile erstellt wird.
Seit Schema 2.3.0 macht das Envelope dies deutlich. 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 angekommen ist. Die Lücke ist dann in dem Artefakt sichtbar, das zur Aufzeichnung wird, statt nur in einer Konfigurationsdatei. mediation.deposit_enabled() meldet denselben Sachverhalt 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 sein eigenes <server>.jsonl hinein. Das ist keine Ordnungsliebe. Anhängen bedeutet „letzten 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 zwei, die im selben Moment antworten, lesen beide denselben Vorgänger und beanspruchen beide ihn. Gemessen, nicht theoretisiert: Sechs Prozesse, die 150 Zeilen in eine Datei schreiben, erzeugten vierzehn Forks. 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.
Prüfen Sie eine Kette oder den gesamten Ordner:
jstage-mcp-ledger verify receipts/jstage.jsonl
jstage-mcp-ledger verify-dir receipts
jstage-mcp-ledger manifest receipts # writes receipts/manifest.jsonverify beendet sich bei einem Fehler mit einem Exitcode ungleich Null und teilt mit, welche Art es gefunden hat: einen Fork (gleichzeitige Schreiber – ein Konfigurationsfehler, und jede Zeile ist trotzdem noch vorhanden), eine fehlende Zeile, eine Umordnung oder Manipulation (eine Zeile, deren Hash nicht zu ihrem eigenen Inhalt passt). Nur Letzteres ist eine Aussage über Ehrlichkeit, und sie gleich zu melden, würde einen Leser dazu einladen, eines für das andere zu halten. Das Manifest ist das anzuführende Objekt: eine Beschreibung der gesamten Hinterlegung – Zeilenzahlen pro Datei, erste und letzte Zeitstempel, End-Hashes und kombinierte Summen nach Server, Schriftsystem und Sitzung.
Installation
Das Paket installiert ein Konsolenskript mit dem Namen jstage-mcp. Es ist in einen Namensraum eingebettet, sodass es sich 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/jstage-mcp" jstage-mcpInstallation prüfen:
.venv/bin/python -c "import jstage_mcp; print(jstage_mcp.__version__)"Das schlägt laut fehl, wenn das Paket oder eines seiner gebündelten Module fehlt. Verwenden Sie nicht jstage-mcp --help als Prüfung: unbekannte Argumente werden ignoriert, der Server startet, liest das Eingabeende und beendet sich mit Exitcode 0, sodass er unabhängig vom Zustand des Codes Erfolg meldet.
Installation weiterer Pakete
Sechs unabhängige Pakete. Keins importiert ein anderes, keins 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 jedoch drei Dinge: ein Antwort-Envelope, ein Abfragejournal und – wenn Sie mehr als einen ausführen – einen Belegordner. install.ps1 ist byte-identisch in alle sechs eingebettet und übernimmt das. Es installiert standardmäßig diesen Server, denn das Klonen eines Repositorys ist keine Anfrage nach fünf weiteren.
.\install.ps1 # this server
.\install.ps1 -All # all six
.\install.ps1 -Servers jstage,cinii # a chosen subsetWelche Teilmenge Sie auch immer nennen, sie wird gegen einen einzigen Belegordner registriert, nach dem nur einmal gefragt wird. Das Skript zieht ein Checkout in einem benachbarten Verzeichnis dem Netzwerk vor, übernimmt bereits registrierte Anmeldedaten, statt erneut zu fragen, lässt Server, nach denen es nicht gefragt wurde, unangetastet und stoppt, anstatt zu raten, wenn die bereits registrierten Server beim Ordner oder beim Sitzungs-Slug voneinander abweichen. Es prüft außerdem, dass ledger.py und mediation.py über alles, was es installiert hat, byte-identisch sind, sodass nicht unbemerkt zwei Envelope-Versionen in einer Umgebung landen können.
Claude-Desktop-Konfiguration
Fügen Sie unter mcpServers einen Eintrag zu %APPDATA%\Claude\claude_desktop_config.json hinzu, der auf das Konsolenskript in der Umgebung zeigt, in die Sie installiert haben. Verwenden Sie unter macOS oder Linux den absoluten Pfad zu .venv/bin/jstage-mcp.
{
"mcpServers": {
"jstage": {
"command": "C:\\path\\to\\.venv\\Scripts\\jstage-mcp.exe"
}
}
}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, denn server.py ist jetzt ein Modul innerhalb eines Pakets und kein Skript neben seinen Importen. Ersetzen Sie ihn durch das obige Konsolenskript.
Starten Sie Claude Desktop neu. Die drei Tools sollten in der Tool-Liste unter „jstage“ erscheinen.
Ratenbegrenzung
Der Server erzwingt ein Mindestintervall von einer Sekunde zwischen ausgehenden Anfragen, im Einklang mit JSTs Verbot von Massendownloads. Das Limit gilt pro Prozess; wenn Sie mehrere Claude-Desktop-Sitzungen gleichzeitig ausführen, können Sie es überschreiten – also tun Sie das nicht.
Einschränkungen
Es gibt kein Zeitschriftensuch-Tool.
jstage_search_journalsexistierte in v1.x und wurde in v2.0.0 entfernt. J-STAGE hat am 26. März 2026 einen Zeitschriftensuch-Endpunkt (service=4) angekündigt, und die öffentliche API lehnt diesen Servicecode weiterhin mitERR_004ab; ein Tool, das stillschweigend auf die Bandsuche zurückfällt, ist keine Zeitschriftensuche, und dieser Server möchte lieber keins anbieten. Bis JSTservice=4aktiviert, verwenden Siejstage_list_issuesmit einem bekannten Titel, einer ISSN odercdjournal.jstage_get_article_by_doierfordert von J-STAGE vergebene DOIs. Die WebAPI bietet keinendoi=-Abfrageparameter an. Das Tool zerlegt DOIs, die dem Muster von J-STAGE folgen (10.<registrant>.<cdjournal>.<vol>.<no>_<page>), incdjournal+volund gleicht das Ergebnis mit der Antwort ab. Für DOIs außerhalb dieses Musters gibt das Tool die Auflösungs-URL von doi.org mit einem Hinweis zurück.Kommerzielle Nutzung erfordert eine Registrierung. Gemäß den JST-Nutzungsbedingungen erfordert die kommerzielle Nutzung ein Antragsformular, das an
contact@jstage.jst.go.jpgesendet wird. Forschungs- und Lehrnutzung nicht.
API-Hinweise
Endpunkt: https://api.jstage.jst.go.jp/searchapi/do
Verwendete Servicecodes:
service=2— Bände/Hefteservice=3— Artikelsucheservice=4— Zeitschriftensuche (dokumentiert, wird mit Stand 23. August 2026 mitERR_004abgelehnt; von keinem Tool verwendet)
Gültige Artikelsuch-Abfrageparameter, gegen die Live-API bestätigt: material, article, author, affil, keyword, abst, text, issn, cdjournal, vol, no, pubyearfrom, pubyearto, start, count.
Namensnennung
Powered by J-STAGE
Diese Zeichenkette ist in jeder Tool-Antwort enthalten.
Zitation
Wenn diese Software Ihre Forschung unterstützt, zitieren Sie sie bitte. Siehe CITATION.cff oder verwenden Sie den Button „Cite this repository“ auf GitHub.
Lizenz
MIT © 2026 Christopher Gerteis.
Diese Lizenz gilt nur für den Servercode. Sie gewährt keine Rechte an J-STAGE-Inhalten oder der J-STAGE-WebAPI, die weiterhin den Nutzungsbedingungen von JST unterliegen.
Haftungsausschluss
Ein Forschungstool, das nach bestem Bemühen gepflegt und ohne Gewährleistung „wie besehen“ bereitgestellt wird. Es ist weder mit der Japan Science and Technology Agency verbunden noch von ihr unterstützt. JST bietet keinen Support für die WebAPI an.
Autor
Dr Christopher Gerteis, SOAS University of London.
Available Tools
3 toolsjstage_get_article_by_doiARead-onlyIdempotent
Resolve a J-STAGE DOI to its article record. Returns the unified envelope (operation 'resolve_doi') with one item on success, or zero items plus a diagnostic when the DOI is not in J-STAGE's issuance pattern or is unmatched.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only/idempotent/non-destructive behavior. The description adds meaningful behavioral context beyond annotations by specifying the response envelope, the operation name ('resolve_doi'), and the success/failure contract (one item vs. zero items plus diagnostic). This clarifies what happens in edge cases, which is not covered by annotations.
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, front-loaded with the primary purpose and then the response behavior. There is no redundancy or unnecessary detail. Every sentence contributes to understanding the tool's function and outcomes.
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 simplicity (one parameter) and the presence of an output schema, the description covers the essential aspects: the operation, success/failure representation, and error handling. It does not mention pagination or other complexities because they are not applicable. The schema description handles the parameter format. Overall, it is complete for an agent to use the tool 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?
The schema description for the 'doi' parameter already explains that it can be with or without the doi.org prefix, providing semantic meaning. Although the context signal says schema description coverage is 0%, the actual schema includes a description, so the baseline of 3 applies. The tool description adds no additional parameter information beyond what the schema provides.
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 explicitly states the verb 'resolve' and the resource 'a J-STAGE DOI to its article record.' It is specific and clearly distinguishes from the siblings (search_articles and list_issues) by focusing on DOI-based lookup. The purpose is immediately understandable.
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 does not explicitly mention when to use this tool versus the alternatives. However, the purpose (DOI to article) strongly implies usage when a DOI is available. There are no explicit exclusions or comparisons to siblings, so guidance is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jstage_list_issuesARead-onlyIdempotent
Return the volume/issue spine of a journal (by material/issn/cdjournal).
Navigation aid, not literature retrieval: returns structural JSON (volumes with publisher/journal metadata), not the record envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not repeat those. It adds useful behavioral context: the return is 'structural JSON (volumes with publisher/journal metadata), not the record envelope'. This clarifies the nature of the output beyond what annotations capture and reinforces the navigation-purpose distinction. It does not contradict any annotation.
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 core purpose, and immediately clarifies what it is not. Every word earns its place; there is no redundant or vague language.
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 is relatively simple (one params object) and the description covers the essential purpose and output shape. An output schema exists, so the detailed return structure is likely defined elsewhere. The description could elaborate on pagination (count/start) or use cases, but for a navigation aid the current level is adequate. The only minor gap is not mentioning the filtering options beyond identifiers, but they are in the schema.
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% (description does not discuss the parameters object). The description mentions 'by material/issn/cdjournal', covering three of the seven fields, but omits count, start, pubyearfrom, and pubyearto. Given the low coverage, the description should compensate more, but it does highlight the primary identifiers. The schema itself provides titles and constraints for the remaining fields, so this is a partial compensation.
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: 'Return the volume/issue spine of a journal'. It also differentiates from siblings by asserting it is a 'Navigation aid, not literature retrieval', which precisely matches the listing vs. search/article functions. This leaves no ambiguity about what the tool does.
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 context: this is for navigation, not literature retrieval. It implies when to use it (when you need the structural spine) and when not (for literature retrieval, likely using search or get-article siblings). It also names the key identifiers ('by material/issn/cdjournal') but does not explicitly mention alternative tool names or exact conditions for choosing this over siblings. This is close to full guidance, but not explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jstage_search_articlesARead-onlyIdempotent
Search articles on J-STAGE. Returns the unified response envelope.
J-STAGE matches text against full text and treats multi-word terms
loosely, so a high result.total is often noisy — read matching_mode
(full_text_broad), result.breadth, and the diagnostics before treating
a count as the size of a literature. A SCRIPT_LATIN_QUERY diagnostic means
the query matched Latin-script text and metadata only; re-issue in kanji/kana. The same
string can return very different totals on CiNii (metadata conjunction).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the bar is lower, and the description still adds substantial context. It explains full-text broad matching, loose multi-word handling, the meaning of matching_mode/result.breadth/diagnostics, SCRIPT_LATIN_QUERY implications, and differences from CiNii. This goes far beyond the structured annotations.
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 front-loaded with the core purpose and then provides a dense but relevant paragraph of caveats. Every sentence earns its place, with no filler or repetition of annotation information.
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 search tool's complexity and the existing output schema, the description covers the response envelope, diagnostics, matching behavior, and cross-source caveats. It does not explicitly address when to choose this tool over siblings or provide examples, but the essential invocation and result-interpretation context is present.
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% at the top level, but the nested schema properties have individual descriptions. The tool description adds meaningful semantics for the central text parameter, explaining full-text matching, noise, and re-issuing in kanji/kana, which is not in the schema. It does not discuss filters or pagination, but those are covered in the nested schema.
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 opens with 'Search articles on J-STAGE' and 'Returns the unified response envelope,' clearly stating the verb, resource, and scope. It is distinguishable from siblings like jstage_list_issues and jstage_get_article_by_doi by the search focus, though it does not explicitly contrast itself with 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 description gives practical guidance for interpreting noisy results and re-issuing Latin-script queries in kanji/kana, which helps an agent act after receiving results. However, it does not explicitly state when to prefer this tool over the sibling tools or when not to use it, so usage selection is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v3.0.0- First observed
jstage_get_article_by_doi - First observed
jstage_list_issues - First observed
jstage_search_articles
TDQS
Scored across 3 tools
Each tool targets a distinct operation: full-text search, DOI resolution, and journal issue navigation. There is no real overlap between query-based retrieval and known-identifier lookup, and list_issues is explicitly separated from article record retrieval.
All tool names follow a consistent jstage_<verb>_<object> pattern using snake_case and a shared prefix. The verbs search, get, and list are predictable and clearly map to their respective actions.
Three tools is at the lower end of a well-scoped range, but each tool earns its place by covering a core workflow. The count feels minimal yet sufficient for a focused J-STAGE article server.
Core discovery workflows are covered: searching articles, resolving a DOI, and navigating journal issues. Minor gaps exist for directly listing articles inside a specific issue or retrieving articles by non-DOI identifiers, but these are workable via search.
Maintenance
Related MCP Connectors
Search 150M+ academic works, journals, and funders via Crossref API.
Search DataCite datasets and software, fetch DOI metadata, trace relations, format citations.
Google Scholar search results, citation counts and citation export formats, as structured JSON.
Wikipedia, Wikidata and Wiktionary as clean JSON, not HTML. 1.9M searchable. Free, no auth.
Related MCP Servers
- AlicenseAqualityAmaintenanceEnables querying Japan's national academic database, CiNii Research, for articles, books, dissertations, KAKEN projects, and researcher profiles via seven MCP tools.113MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to query Japanese public data (laws, corporations, statistics) from official government APIs, returning normalized English metadata with source attribution.1MIT
- AlicenseAqualityDmaintenanceEnables searching CiNii Research for academic articles, books, grants, and research data, and retrieving metadata for individual items.2MIT
- AlicenseAqualityCmaintenanceEnables scholarly metadata lookups from the Crossref REST API, including works, members, journals, funders, types, licenses, and prefixes, as tools for LLM clients.1841 PyPIMIT