How do I use jstage-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jstage-mcp-server Search J-STAGE for recent articles about artificial intelligence" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

jstage-mcp-server

by Groshan67

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

jstage-mcp-server

An MCP server for searching Japanese scientific articles and publications on J-STAGE (the JST platform — Japan Science and Technology Agency).

Unlike NCBI, J-STAGE does not require an API key
It has only ۳ types of services (journal search, issue list, article search), not ۱۱
It returns metadata only, not full text — for full text, you need to go to the publisher's site using the link/doi field of each result

Step ۰: Prerequisites

Node.js version ۱۸ or higher (because of global fetch)
npm

Related MCP server: cinii-mcp

Step ۱: Installation

git clone <download or copy this folder>
cd jstage-mcp-server
npm install

Step ۲: Compilation

npm run build

This creates the build/ folder with the compiled JavaScript files.

Step ۳: Local testing with MCP Inspector

Before connecting it to Claude, it's better to make sure the server works correctly with the official MCP testing tool:

npx @modelcontextprotocol/inspector node build/index.js

This opens a local web interface where you can directly call the jstage_search_articles, jstage_search_journals, jstage_list_volumes tools and see the actual J-STAGE response — without Claude being involved at all.

Sample input for testing jstage_search_articles:

{ "keyword": "人工知能", "count": 5 }

(“人工知能” means “artificial intelligence” — since most J-STAGE content is Japanese, searching in Japanese usually gives better results)

Step ۴: Connecting to Claude Desktop (stdio mode — local)

Open the Claude Desktop configuration file (usually claude_desktop_config.json) and add this:

{
  "mcpServers": {
    "jstage": {
      "command": "node",
      "args": ["/full/path/to/jstage-mcp-server/build/index.js"],
      "env": {
        "MCP_TRANSPORT_TYPE": "stdio"
      }
    }
  }
}

After saving, restart Claude Desktop. Now you can say: “Find an article about such-and-such topic on J-STAGE”.

Step ۵: Connecting to Claude Code

claude mcp add --transport stdio jstage node /full/path/to/jstage-mcp-server/build/index.js

Then you can check that the server is connected with /mcp.

Step ۶: Deploying for remote access (Claude.ai web)

To allow Claude.ai (the web version) to connect to it as well, you need to run the HTTP server at a public address.

Local HTTP testing

MCP_TRANSPORT_TYPE=http npm run start:http
# the server listens on http://localhost:3011/mcp

Actual deployment

Since this server uses Express (rather than just an API route like the Next.js example), the simplest options are:

Docker on any VPS (for example, a simple Dockerfile with CMD ["node", "build/index.js"] and ENV MCP_TRANSPORT_TYPE=http)
Railway / Render / Fly.io — these directly deploy ordinary Node.js apps from a repository

After deployment, in Claude.ai → Settings → Connectors → Add custom connector, provide the address https://your-domain.com/mcp.

Available Tools

4 tools

jstage_fetch_article_abstract_and_referencesFetch abstract & references for a J-STAGE articleA

برای یه مقاله‌ی مشخص (با لینکی که از jstage_search_articles گرفتی)، سعی می‌کنه چکیده (Abstract) و بخشی از فهرست منابع (References) رو استخراج کنه. ⚠️ فقط برای بعضی نشریات J-STAGE (عمدتاً open-access) کار می‌کنه، چون بر پایه‌ی یه نسخه‌ی txt غیررسمی‌ه که فقط بعضی ناشرها منتشرش می‌کنن. اگه در دسترس نبود، پیام مشخصی برمی‌گردونه که یعنی برای این مقاله باید مستقیم از لینک/DOI استفاده کنی.

ParametersJSON Schema

Name	Required	Description	Default
`article_link`	Yes	فیلد link همون مقاله‌ای که از jstage_search_articles گرفتی (چیزی شبیه https://www.jstage.jst.go.jp/article/{cdjournal}/{vol}/{no}/{id}/_article/-char/en)
`max_references`	No	حداکثر تعداد رفرنسی که برگردونده بشه (نه لزوماً کل لیست منابع)

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full transparency burden. It honestly discloses that extraction is best-effort, works only for some publications, is based on an unofficial text version, and returns a clear message on failure. It doesn't describe the exact output format, but the main behavioral limitations are well covered.

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 compact and front-loaded: it states the purpose, then the key limitation and fallback, with no redundant filler. Every sentence earns its place and the warning is clearly marked.

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 that there is no output schema, the description adequately explains what the tool returns (abstract and part of the reference list) and what happens when data is unavailable. It doesn't specify the exact structure of returned references, but for a focused fetch tool this is sufficient and the fallback guidance completes the picture.

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 100%, and both parameters already have meaningful descriptions. The tool description adds workflow context but little additional parameter-level meaning, so the baseline of 3 is appropriate.

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 names a specific action (extract abstract and references) on a specific resource (a J-STAGE article identified by a link). It also ties the input to jstage_search_articles, which clearly differentiates this fetch tool from the search/list sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use a link obtained from jstage_search_articles, establishing a clear workflow. It also states when the tool will not work (non-open-access publications) and instructs the agent to fall back to the article link/DOI directly, which is an explicit alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jstage_list_volumesList J-STAGE journal volumes/issuesA

گرفتن فهرست شماره‌ها (جلد/شماره) یه نشریه‌ی خاص در J-STAGE. برای این ابزار حتماً باید نام نشریه، ISSN یا کد نشریه رو بدی.

ParametersJSON Schema

Name	Required	Description	Default
`issn`	No	ISSN دقیق نشریه — سریع‌ترین و دقیق‌ترین راه
`lang`	No		ja
`count`	No
`start`	No
`journal_code`	No	کد داخلی نشریه در J-STAGE (cdjournal)، اگه از قبل می‌دونی
`journal_name`	No	نام نشریه (اگه issn یا cdjournal رو نداری از این استفاده کن)

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden. It does frame the operation as retrieving a list, which implies a read-only action, but it says nothing about pagination, ordering, error behavior, or identifier precedence. Basic but not deeply transparent.

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?

Two short sentences, purpose first and prerequisites second, with no filler. The description is easy to scan and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter list tool with no output schema and no annotations, the description plus schema is workable: the identifier requirement is stated and the remaining parameters are visible in the schema. However, pagination behavior, return shape, and how to prioritize issn vs journal_name vs journal_code are left unstated, leaving a moderate gap.

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 description adds the important rule that at least one of issn, journal_name, or journal_code must be supplied, even though the schema lists zero required parameters. With only 50% schema description coverage, it does not directly explain count/start/lang, though those are partially self-documenting via defaults, enums, and min/max.

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 names a concrete operation — retrieving the list of volumes/issues for a specific J-STAGE journal — so the agent can understand the core purpose. It is clearly distinguishable from the sibling search/fetch tools, but it never explicitly contrasts itself with them, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description sets an explicit operational prerequisite: the caller must supply a journal name, ISSN, or journal code. This tells the agent when the tool is applicable, though it does not mention alternatives or exclusion cases such as using jstage_search_journals first to find an identifier.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jstage_search_articlesSearch J-STAGE articlesA

جستجوی مقالات علمی و فنی ژاپنی در J-STAGE بر اساس کلیدواژه، نویسنده، نشریه یا بازه‌ی سال. توجه: فقط متادیتا (عنوان، نویسنده، چکیده، DOI، لینک) برمی‌گردونه، نه متن کامل مقاله.

ParametersJSON Schema

Name	Required	Description	Default
`issn`	No	ISSN دقیق نشریه، اگه می‌دونی سریع‌تره
`lang`	No	زبان ترجیحی متادیتا در پاسخ (بیشتر محتوای J-STAGE ژاپنیه)	ja
`count`	No	تعداد نتیجه در این صفحه (حداکثر ۲۰۰)
`start`	No	شماره‌ی رکورد شروع، برای صفحه‌بندی (پیش‌فرض ۱)
`author`	No	نام نویسنده (تطبیق جزئی)
`keyword`	No	کلیدواژه‌ی آزاد برای جستجو در متادیتای مقاله (عنوان/چکیده/متن نمایه‌شده)
`affiliation`	No	وابستگی سازمانی نویسنده
`pub_year_to`	No	سال پایان بازه‌ی انتشار (YYYY)
`journal_name`	No	نام نشریه (تطبیق جزئی، مثلاً بخشی از نام مجله)
`article_title`	No	جستجوی دقیق‌تر در عنوان مقاله
`pub_year_from`	No	سال شروع بازه‌ی انتشار (YYYY)

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It usefully discloses that the tool returns only metadata (title, author, abstract, DOI, link) and never full-text content, which is a non-obvious behavioral constraint. It could additionally note pagination or sort behavior, but those are partly encoded in the start/count parameters.

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?

Two sentences with no fluff: the first fronts the action and filter dimensions, the second delivers the critical metadata-only limitation. Every sentence adds distinct value.

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?

For an 11-parameter search tool with no output schema, the description plus a fully documented schema provides adequate guidance: overall purpose, accepted filter families, and the central limitation on returned content. A slight gap is the lack of an explicit mention of result list/pagination behavior, but the start/count parameters already hint at this.

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 100%, so every parameter already has its own meaningful Persian description. The tool description adds only a high-level grouping of search dimensions and the metadata caveat, which is useful but does not need to compensate for undocumentd parameters.

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 action ('search'), a specific resource (J-STAGE articles), and the available filter dimensions (keyword, author, journal, year range). It also distinguishes the tool's scope from full-text retrieval by explicitly noting that only metadata is returned.

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 clear context about searching Japanese scientific/technical articles and the metadata-only limitation, but it does not explicitly name alternatives or state when NOT to use this tool. The intended use is implied rather than contrasted with sibling tools like jstage_fetch_article_abstract_and_references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jstage_search_journalsSearch J-STAGE journalsA

جستجوی نشریات (ژورنال‌ها) نمایه‌شده در J-STAGE بر اساس نام یا ISSN. برای پیدا کردن ISSN/کد یه نشریه قبل از جستجوی مقاله یا گرفتن فهرست شماره‌ها مفیده.

ParametersJSON Schema

Name	Required	Description	Default
`issn`	No	ISSN دقیق نشریه
`lang`	No		ja
`count`	No
`start`	No
`journal_name`	No	نام نشریه یا بخشی از آن (تطبیق جزئی، بدون حساسیت به حروف بزرگ/کوچک)
`publication_type`	No	کد نوع انتشار طبق مستندات J-STAGE (مثلاً 100 = ژورنال علمی)

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full behavioral burden. It explains matching criteria and a useful workflow, but it does not disclose output shape, pagination behavior, what happens when no parameters are provided, or read-only status. This is a meaningful gap for a tool with no 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?

Two tightly scoped sentences; the main purpose is front-loaded and the second sentence provides workflow value without fluff. Every word contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 optional parameters, no output schema, and no annotations, the description is thin. An agent knows why to call it but not what result shape to expect or how optional parameters affect behavior. This is insufficient for a complete contextual picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description restates name/ISSN search criteria, but those are already present in the input schema. With only 50% schema coverage, it should add meaning for lang, count, start, and publication_type; it does not. The added value beyond the schema is minimal.

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 (search), a resource (journals indexed in J-STAGE), and search criteria (name or ISSN) in a single clear sentence. It also disambiguates from sibling tools by noting this is the prerequisite workflow step before article search or volume listing.

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?

It gives concrete workflow context: use this tool to find an ISSN/code before searching articles or listing volumes. It does not explicitly name alternatives or list exclusion cases, but the intended usage is clear.

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. Dates show when Glama detected each change.

4 tool updatesv0.1.0Sep 6, 2026
- First observedjstage_fetch_article_abstract_and_references
- First observedjstage_list_volumes
- First observedjstage_search_articles
- First observedjstage_search_journals

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation4/5

The tools are broadly distinct: search articles, search journals, list volumes, and fetch article details. There is slight overlap because jstage_search_articles already returns abstracts, while jstage_fetch_article_abstract_and_references also fetches abstracts in addition to references.

Naming Consistency5/5

All tool names consistently use the jstage_ prefix followed by a clear verb_noun pattern: search_articles, search_journals, list_volumes, fetch_article_abstract_and_references. Naming is unambiguous and easy to predict.

Tool Count5/5

Four tools is a well-scoped size for a specialized J-STAGE metadata and journal navigation server. Each tool has a meaningful role and the count does not feel padded or insufficient.

Completeness3/5

The set covers journal discovery, article search, volume listing, and fetching article-level details, but there is a notable gap: after listing volumes, there is no tool to retrieve the articles within a specific volume or issue. Full-text access is explicitly out of scope, but the volume browsing workflow is left incomplete.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

paper-mcp B
io.github.MCPServings
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Research & Data Open Data
21
Scite A
ai.scite
Ground answers in scientific literature. Search full text, evaluate trust, access full-text articles
Search Research & Data Documentation Access
132
Shirabe Japan Data Hub A
dev.shirabe
Japan data tools for AI agents: calendar (rokuyo), address, name splitting, corporate number lookup
Art & Culture Government Data Open Data
52
pubmed-mcp-server A
io.github.cyanheads
Search PubMed/Europe PMC, fetch articles and full text (PMC/EPMC/Unpaywall), citations, MeSH terms.
Search Research & Data Biology & Medicine
114144

Related MCP Servers

CiNii MCP Server
Research & Data Search
suzuuuuu09
A
license
C
quality
C
maintenance
Enables searching and retrieving academic articles from CiNii, Japan's largest bibliographic database, with support for advanced filtering, sorting, and search range options.
Updated 7 months ago (2026-01-26 19:03 UTC)
1
1
Apache 2.0
cinii-mcp
Research & Data Open Data
ckgerteis
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.
Updated 3 days ago (2026-09-04 14:28 UTC)
7
2
MIT
jstage-mcp
Research & Data Education & Learning Tools
ckgerteis
A
license
A
quality
A
maintenance
Exposes J-STAGE WebAPI as four tools for searching articles, issues, journals, and resolving DOIs, returning bilingual JSON with attribution.
Updated 3 days ago (2026-09-04 14:29 UTC)
3
2
MIT
legal_scholarship_mcp
Research & Data Search
MH-LT
A
license
Not graded
quality
C
maintenance
Enables searching scholarly literature via the OpenAlex database, with tools for full-text search, work details, citation lookup, and author queries.
Updated 2 months ago (2026-06-25 18:30 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Groshan67/jstage-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server