de en es ja ko ru zh

jstage-mcp

Name: jstage-mcp
Author: ckgerteis

by ckgerteis

Overview Schema Source Related Servers Discussions Admin

Python

Local

jstage-mcp

Un servidor FastMCP stdio que expone la J-STAGE WebAPI como tres herramientas para usar con Claude Desktop.

Para qué sirve

J-STAGE contiene el texto completo de revistas publicadas por sociedades científicas japonesas, y esto busca dentro de los artículos en lugar de en un catálogo. Un término que ningún catalogador eligió como palabra clave sigue siendo localizable si un autor lo usó en un argumento, lo que convierte esto en la vía para conceptos que circulan antes de ser nombrados.

Resuelve un DOI de J-STAGE directamente a su registro, o recorre el espinazo de volúmenes y números de una revista para ver una colección completa.

Ejecuta un término aquí y en cinii-mcp y lee la brecha: una divergencia amplia te dice si tu vocabulario pertenece a la descripción de catálogo o a la prosa del campo, lo cual es un hallazgo sobre la literatura antes de ser un hallazgo en ella.

Related MCP server: Japan Data MCP

Herramientas

Tool	Propósito
`jstage_search_articles`	Búsqueda de texto completo / autor / título / revista en los artículos de J-STAGE
`jstage_list_issues`	Espinazo de volúmenes y números para un título, ISSN o `cdjournal` conocido
`jstage_get_article_by_doi`	Resuelve un DOI de J-STAGE a su registro completo de artículo

Todas las herramientas devuelven un sobre de respuesta JSON tipado con títulos, autores y nombres de revistas bilingües (inglés / japonés) cuando J-STAGE los proporciona — ver Formato de respuesta más abajo. El requisito de atribución de JST se cumple mediante el campo attribution del sobre, presente en cada respuesta.

Formato de respuesta

Cada herramienta devuelve un sobre de respuesta JSON, construido por mediation.py y definido en response-schema.json. Versión de esquema 2.3.0. El mismo módulo y esquema se incluyen byte-idénticos en toda la familia de servidores, de modo que un sobre de un servidor puede ser leído por un consumidor escrito para otro.

El sobre informa de cómo se realizó la búsqueda, no solo de lo que encontró:

searched_for — en operaciones de búsqueda, el término realmente enviado, su escritura detectada y el modo de coincidencia, elevados a la parte superior del sobre para que un cliente intermediario no pueda eliminarlo. Las operaciones de recuperación (jstage_get_article_by_doi, jstage_list_issues) lo omiten: se les entregó un identificador y no eligieron ningún término.
query — input_terms tal como se proporcionaron, normalized tal como se enviaron, y la script detectada. Este par es el registro de cualquier transformación realizada entre el idioma del llamante y el corpus.
matching_mode — full_text_broad para este servidor. Te indica cómo leer result.total.
result.breadth — none, narrow (1–50), broad (51–1000), very_broad (>1000). Los umbrales son bajos a propósito: unos cientos de resultados que parecen una literatura se marcan en lugar de pasarse limpios.
items[].matched_in — en qué campo se realizó la coincidencia, por registro.
receipt — una marca de tiempo ISO 8601, un SHA-256 calculado sobre la consulta normalizada y sus parámetros, y los identificadores devueltos. El hash verifica un término que ya posees; no puede invertirse para producir uno, por lo que la unidad de depósito es el sobre, no el recibo.
attribution — la línea de crédito requerida, en cada respuesta.

Códigos de diagnóstico

Tipados y cerrados. Un diagnóstico nunca es prosa que el cliente tenga que analizar.

Code	Level	Significado
`OK`	info	Registros devueltos; nada que señalar.
`BROAD_FULLTEXT`	warning	La coincidencia se realizó sobre el texto completo, donde los términos de varias palabras se comparan de forma flexible, por lo que un `result.total` alto suele ser ruidoso.
`SCRIPT_LATIN_QUERY`	warning	La consulta estaba en escritura latina, por lo que solo coincidió con metadatos romanizados e ingleses. Vuelve a emitirla en kanji o kana.
`LITERAL_COMPOUND_EMPTY`	warning	Sin registros para esta representación. Prueba un término émico o de componente, o una representación japonesa alternativa.
`API_ERROR`	error	La API respondió, y respondió con un error.
`TRANSPORT_ERROR`	error	La solicitud no se completó. Se mantiene distinto de `API_ERROR` porque una búsqueda fallida tiene un resultado desconocido y nunca debe registrarse como una ausencia.
`RECEIPT_NOT_DEPOSITED`	info	La respuesta no se escribió en el registro de consultas, porque no hay ningún destino de recibos configurado. La búsqueda no se ve afectada; ningún recibo sobrevive a ella.
`RECEIPT_WRITE_FAILED`	warning	Hay un destino de recibos configurado, se intentó la escritura y no se completó. Se distingue de la línea anterior porque una es una elección y la otra es un fallo.

Recibos de consulta

Cada sobre puede depositarse en un registro JSONL de solo añadidura y encadenado por hash mediante ledger.py. Está desactivado a menos que se establezca MCP_RECEIPT_DIR (o el heredado MCP_RECEIPT_LOG), y un fallo de registro se traga en lugar de lanzarse: una búsqueda importa más que el registro de la misma. Los secretos se redactan antes de componer una línea.

Desde el esquema 2.3.0 el sobre lo dice. Cuando una respuesta no se deposita, emit() añade RECEIPT_NOT_DEPOSITED si la variable no está establecida, o RECEIPT_WRITE_FAILED si está establecida y la escritura no se completó. La brecha es entonces visible en el artefacto que se convierte en el registro, en lugar de solo en un archivo de configuración. mediation.deposit_enabled() informa del mismo hecho a petición.

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

Una carpeta, y un archivo por servidor. MCP_RECEIPT_DIR apunta a un directorio y cada servidor escribe su propio <server>.jsonl dentro de él. Eso no es orden. Añadir es leer-el-último-hash-y-luego-escribir, y el bloqueo que lo rodea es un bloqueo de hilo, que se mantiene dentro de un proceso y no entre varios: seis servidores son seis procesos, y dos que respondan al mismo tiempo leerán ambos el mismo predecesor y ambos lo reclamarán. Medido, no teorizado: seis procesos escribiendo 150 líneas en un archivo produjeron catorce bifurcaciones. MCP_RECEIPT_LOG sigue funcionando y sigue siendo correcto para un solo servidor; es la forma equivocada para una familia.

install.ps1 configura esto para los seis y escribe un README en la carpeta.

Verifica una cadena, o toda la carpeta:

jstage-mcp-ledger verify      receipts/jstage.jsonl
jstage-mcp-ledger verify-dir  receipts
jstage-mcp-ledger manifest    receipts        # writes receipts/manifest.json

verify sale con código distinto de cero en caso de fallo y dice qué tipo encontró: una bifurcación (escritores concurrentes — un fallo de configuración, y cada línea sigue ahí), una línea faltante, un reordenamiento, o manipulación (una línea que no se corresponde con su propio contenido). Solo la última es una afirmación sobre la honestidad, y reportarlas por igual invitaría a un lector a confundir una con la otra. El manifiesto es el objeto a citar: una descripción de todo el depósito — recuentos de líneas por archivo, primeras y últimas marcas de tiempo, hashes terminales y totales combinados por servidor, escritura y sesión.

Instalación

El paquete instala un script de consola jstage-mcp. Tiene espacio de nombres, por lo que puede compartir un entorno con el resto de esta familia de servidores.

python3 -m venv .venv
.venv/bin/pip install .

En Windows:

py -3.11 -m venv .venv
.venv\Scripts\pip.exe install .

O directamente desde el repositorio, sin clonar:

uvx --from "git+https://github.com/ckgerteis/jstage-mcp" jstage-mcp

Verifica la instalación:

.venv/bin/python -c "import jstage_mcp; print(jstage_mcp.__version__)"

Eso falla de forma ruidosa si el paquete o uno de sus módulos incluidos falta. No uses jstage-mcp --help como comprobación: los argumentos desconocidos se ignoran, el servidor se inicia, lee el final de la entrada y sale con 0, por lo que informa de éxito sea cual sea el estado del código.

Instalar más de este

Seis paquetes independientes. Ninguno importa a otro, ninguno depende de otro, y cada uno se instala y responde por sí mismo — pip install . en este directorio es una instalación completa de este servidor y nada más.

Sí comparten tres cosas: un sobre de respuesta, un registro de consultas y — si ejecutas más de uno — una carpeta de recibos. install.ps1 se incluye byte-idéntico en los seis y se encarga de eso. Instala este servidor por defecto, porque clonar un repositorio no es una solicitud de cinco más.

.\install.ps1                        # this server
.\install.ps1 -All                   # all six
.\install.ps1 -Servers jstage,cinii        # a chosen subset

Cualquier subconjunto que nombres se registra contra una carpeta de recibos, solicitada una vez. El script prefiere una copia hermana a la red, traslada las credenciales ya registradas en lugar de volver a preguntar, deja en paz a los servidores sobre los que no se le preguntó, y se detiene en lugar de adivinar dónde los servidores ya registrados discrepan sobre la carpeta o el slug de sesión. También afirma que ledger.py y mediation.py son byte-idénticos en todo lo que instaló, de modo que dos versiones de sobre no pueden terminar en un entorno sin ser notadas.

Configuración de Claude Desktop

Añade una entrada a %APPDATA%\Claude\claude_desktop_config.json bajo mcpServers, apuntando al script de consola en el entorno en el que instalaste. En macOS o Linux usa la ruta absoluta a .venv/bin/jstage-mcp.

{
  "mcpServers": {
    "jstage": {
      "command": "C:\\path\\to\\.venv\\Scripts\\jstage-mcp.exe"
    }
  }
}

Cambiado en 3.0.0. Las versiones anteriores se registraban por ruta — "command": "…\\python.exe", "args": ["…\\server.py"]. Esa entrada no iniciará esta versión, porque server.py ahora es un módulo dentro de un paquete en lugar de un script junto a sus importaciones. Reemplázala con el script de consola anterior.

Reinicia Claude Desktop. Las tres herramientas deberían aparecer bajo "jstage" en la lista de herramientas.

Límite de velocidad

El servidor impone un intervalo mínimo de un segundo entre solicitudes salientes de acuerdo con la prohibición de JST sobre descargas masivas. El límite es por proceso; si ejecutas varias sesiones de Claude Desktop simultáneamente, podrías superarlo, así que no lo hagas.

Limitaciones

No hay herramienta de búsqueda de revistas. jstage_search_journals existía en v1.x y se eliminó en v2.0.0. J-STAGE anunció un endpoint de búsqueda de revistas (service=4) el 26 de marzo de 2026 y la API pública aún rechaza ese código de servicio con ERR_004; una herramienta que silenciosamente recurre a la búsqueda de volúmenes no es una búsqueda de revistas, y este servidor prefiere no ofrecer una. Hasta que JST active service=4, usa jstage_list_issues contra un título, ISSN o cdjournal conocido.
jstage_get_article_by_doi requiere DOIs emitidos por J-STAGE. La WebAPI no expone un parámetro de consulta doi=. La herramienta descompone los DOIs que siguen el patrón de J-STAGE (10.<registrant>/<cdjournal>.<vol>.<no>_<page>) en cdjournal+vol y compara el resultado con la respuesta. Para DOIs fuera de ese patrón, la herramienta devuelve la URL de resolución de doi.org con una nota.
El uso comercial requiere registro. Según los Términos de Uso de JST, el uso comercial necesita un formulario de solicitud enviado a contact@jstage.jst.go.jp. El uso para investigación y enseñanza no.

Notas de la API

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

Códigos de servicio utilizados:

service=2 — Volúmenes/números
service=3 — Búsqueda de artículos
service=4 — Búsqueda de revistas (documentado, rechazado con ERR_004 a partir del 23 de agosto de 2026; no utilizado por ninguna herramienta)

Parámetros de consulta válidos para la búsqueda de artículos confirmados contra la API en vivo: material, article, author, affil, keyword, abst, text, issn, cdjournal, vol, no, pubyearfrom, pubyearto, start, count.

Atribución

Powered by J-STAGE

Esta cadena se incluye en cada respuesta de herramienta.

Cita

Si este software respalda tu investigación, por favor cítalo. Ver CITATION.cff, o usa el botón "Cite this repository" en GitHub.

Licencia

Esta licencia cubre únicamente el código del servidor. No otorga ningún derecho sobre el contenido de J-STAGE ni sobre la WebAPI de J-STAGE, que siguen regidos por los Términos de uso de JST.

Descargo de responsabilidad

Una herramienta de investigación, mantenida con el mejor esfuerzo posible y proporcionada "tal cual", sin garantía. No está afiliada ni respaldada por Japan Science and Technology Agency. JST no ofrece soporte para la WebAPI.

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.

Name	Required	Description	Default
`params`	Yes

Output Schema

Name	Required	Description
`result`	Yes

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.

Name	Required	Description	Default
`params`	Yes

Output Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`params`	Yes

Output Schema

Name	Required	Description
`result`	Yes

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.

3 tool updatesv3.0.0Aug 27, 2026
- First observedjstage_get_article_by_doi
- First observedjstage_list_issues
- First observedjstage_search_articles

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored 2026-09-08 22:20 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

Resources

Related MCP Connectors

Crossref Scholarly DataOAuth
io.github.Taru0208
Search 150M+ academic works, journals, and funders via Crossref API.
Search Research & Data Open Data
2
https://aligned-kettledrum--crossref-mcp-server.apify.actor/mcp
datacite-mcp-server A
io.github.cyanheads
Search DataCite datasets and software, fetch DOI metadata, trace relations, format citations.
Research & Data Open Data Search
611
https://datacite.caseyjhand.com/mcp
Google Scholar Remote MCP Server A
com.hasdata
Google Scholar search results, citation counts and citation export formats, as structured JSON.
Research & Data Search Web Scraping
3113
https://mcp.hasdata.com/api/mcp?apis=google_scholar
Wikexa Knowledge A
com.wikexa
Wikipedia, Wikidata and Wiktionary as clean JSON, not HTML. 1.9M searchable. Free, no auth.
Search Knowledge & Memory Open Data
61
https://wikexa.com/mcp

Related MCP Servers

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 12 days ago (2026-10-19 08:58 UTC)
7
3
MIT
Japan Data MCP
Government Data Open Data
yurukusa
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.
Updated 4 months ago (2026-07-06 11:13 UTC)
1
MIT
mcp-cinii
Research & Data Open Data
iwaokimura
A
license
A
quality
D
maintenance
Enables searching CiNii Research for academic articles, books, grants, and research data, and retrieving metadata for individual items.
Updated 4 months ago (2026-07-10 05:40 UTC)
2
MIT
crossref-mcp
Research & Data Open Data
jtl-neo
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.
Updated 4 months ago (2026-06-24 11:35 UTC)
18
41 PyPI
MIT