Skip to main content
Glama

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

jstage_search_articles

Volltext-/Autoren-/Titel-/Zeitschriftensuche über J-STAGE-Artikel

jstage_list_issues

Band- und Heftfolge für einen bekannten Titel, eine ISSN oder cdjournal

jstage_get_article_by_doi

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_terms wie angegeben, normalized wie gesendet und das erkannte script. Dieses Paar ist die Aufzeichnung jeder Umsetzung, die zwischen der Sprache des Aufrufers und dem Korpus vorgenommen wurde.

  • matching_mode — full_text_broad 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). 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

OK

info

Datensätze zurückgegeben; nichts zu beanstanden.

BROAD_FULLTEXT

warning

Der Treffer wurde im Volltext erzielt, wo mehrteilige Begriffe lose abgeglichen werden, daher ist ein hoher result.total oft verrauscht.

SCRIPT_LATIN_QUERY

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.

LITERAL_COMPOUND_EMPTY

warning

Keine Datensätze für diese Schreibweise. Versuchen Sie einen emischen oder Komponentenbegriff oder eine alternative japanische Schreibweise.

API_ERROR

error

Die API hat geantwortet, und zwar mit einem Fehler.

TRANSPORT_ERROR

error

Die Anfrage wurde nicht abgeschlossen. Von API_ERROR unterschieden, weil eine fehlgeschlagene Suche ein unbekanntes Ergebnis hat und niemals als Abwesenheit dargestellt werden darf.

RECEIPT_NOT_DEPOSITED

info

Die Antwort wurde nicht in das Abfragejournal geschrieben, weil kein Belegziel konfiguriert ist. Die Suche ist davon nicht betroffen; es überlebt kein Beleg.

RECEIPT_WRITE_FAILED

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 set

Ein 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.json

verify 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-mcp

Installation 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 subset

Welche 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_journals existierte 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 mit ERR_004 ab; ein Tool, das stillschweigend auf die Bandsuche zurückfällt, ist keine Zeitschriftensuche, und dieser Server möchte lieber keins anbieten. Bis JST service=4 aktiviert, verwenden Sie jstage_list_issues mit einem bekannten Titel, einer ISSN oder cdjournal.

  • jstage_get_article_by_doi erfordert von J-STAGE vergebene DOIs. Die WebAPI bietet keinen doi=-Abfrageparameter an. Das Tool zerlegt DOIs, die dem Muster von J-STAGE folgen (10.<registrant>.<cdjournal>.<vol>.<no>_<page>), in cdjournal+vol und 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.jp gesendet wird. Forschungs- und Lehrnutzung nicht.

API-Hinweise

Endpunkt: https://api.jstage.jst.go.jp/searchapi/do

Verwendete Servicecodes:

  • service=2 — Bände/Hefte

  • service=3 — Artikelsuche

  • service=4 — Zeitschriftensuche (dokumentiert, wird mit Stand 23. August 2026 mit ERR_004 abgelehnt; 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 tools
jstage_get_article_by_doiA
Read-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.

NameRequiredDescriptionDefault
paramsYes

Output Schema

NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_issuesA
Read-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.

NameRequiredDescriptionDefault
paramsYes

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_articlesA
Read-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).

NameRequiredDescriptionDefault
paramsYes

Output Schema

NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

  1. 3 tool updatesv3.0.0
    • First observedjstage_get_article_by_doi
    • First observedjstage_list_issues
    • First observedjstage_search_articles

TDQS

A4.3/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityActive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    A
    maintenance
    Enables querying Japan's national academic database, CiNii Research, for articles, books, dissertations, KAKEN projects, and researcher profiles via seven MCP tools.
    11
    3
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to query Japanese public data (laws, corporations, statistics) from official government APIs, returning normalized English metadata with source attribution.
    1
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Enables searching CiNii Research for academic articles, books, grants, and research data, and retrieving metadata for individual items.
    2
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    Enables scholarly metadata lookups from the Crossref REST API, including works, members, journals, funders, types, licenses, and prefixes, as tools for LLM clients.
    18
    41 PyPI
    MIT