Un servidor FastMCP stdio que expone dos servicios bibliográficos coreanos — el Korea Citation Index (KCI, 한국학술지인용색인, National Research Foundation of Korea) y Open Access Korea (OAK, 오픈액세스코리아, National Library of Korea) — como ocho herramientas para Claude Desktop y otros clientes MCP.
Es la contraparte coreana de cinii-mcp y jstage-mcp y devuelve el mismo sobre de respuesta, de modo que los tres pueden leerse lado a lado en un trabajo trilateral.
Herramienta | Fuente | Clave requerida | Propósito |
| KCI REST | sí | Búsqueda de artículos en título, autor, revista, institución, afiliación, palabra clave, resumen, DOI, rango de fechas |
| KCI REST | sí | Registro completo por número de control — el único endpoint que lleva palabras clave, ISSN, UCI y resúmenes |
| KCI REST | sí | Obras citadas por un artículo |
| KCI REST | sí | Índices de citación de revistas (impacto, inmediatez, proporción de autocitas) |
| KCI OAI-PMH | no | Cosecha por ventana de fecha de ingesta, filtro en el cliente, seguimiento de tokens de reanudación |
| OAK OAI-PMH | no | Cosecha de repositorios institucionales coreanos por ventana de fecha de ingesta |
| OAK OAI-PMH | no | Un registro OAK por identificador OAI |
| — | — | Qué está configurado, qué es accesible y qué no cubre este servidor |
Cuatro de las ocho funcionan sin credenciales — todo lo de OAI-PMH, más el estado.
Related MCP server: Literatür MCP
KCI indexa artículos en revistas académicas registradas en Corea. No indexa monografías, capítulos ni disertaciones. Su interfaz REST es una interfaz de consulta genuina; su interfaz OAI-PMH no lo es.
OAK agrega repositorios institucionales coreanos — informes de investigación, tesis, monografías, fondos 고서, artículos de acceso abierto — contribuidos de manera desigual por las instituciones miembros.
Ambos fueron probados en vivo el 19 de agosto de 2026, y tres propiedades dan forma a cómo están escritas las herramientas:
Las marcas de fecha OAI son fechas de ingesta, no fechas de publicación. Una ventana de cosecha de mayo de 2019 devuelve artículos publicados entre 2010 y 2015. La afirmación repetida a menudo de que el feed OAI de KCI solo expone material reciente es una mala lectura de esto: el feed cubre el corpus, simplemente no tiene forma de que se le pregunte nada. kci_harvest por lo tanto filtra en el cliente y lo dice en un diagnóstico en cada llamada.
1a. El oai_dc de KCI está completamente tipado, y este servidor lee los tipos. Medido sobre 500 registros en vivo: identifier[type=artiId|uci|doi|citedCnt|regularity|journalInfo], un atributo issn= en 500/500, y lang="original|english" en cada título y descripción. La versión 0.2.0 afirmaba lo contrario — "una bolsa posicional sin tipos" para emparejar por patrón — y en consecuencia descartaba cada ISSN, cada resumen y 371 DOIs reales por cada 500 registros. El emparejamiento por patrón sobrevive solo como respaldo para identificadores que llegan sin etiquetar. Nótese que KCI también emite elementos type="doi" que contienen solo el prefijo del resolver; esos se normalizan a null en lugar de pasarse como identificadores.
OAK no envía resumptionToken. Declara noSetHierarchy, honra from/until, y limita una ventana a aproximadamente 99 registros sin continuación. Un cosechador que confíe en el protocolo presentará silenciosamente una ventana truncada como completa. oak_harvest lanza OAI_WINDOW_TRUNCATED cuando alcanza el límite y te dice que dividas la ventana.
OAK no es Dublin Core estándar. Emite dc:title_h, dc:abstract_e, dc:publish_date, dc:location_org, dc:deep_link, dc:contents_url, y pone el tipo de material en dc:keyword. La presencia de campos varía según el repositorio contribuyente. Los campos no reconocidos se conservan bajo extra.raw_fields en lugar de descartarse.
Dos asimetrías adicionales se informan en lugar de suavizarse:
El articleSearch de KCI acepta keyword como campo de búsqueda pero omite las palabras clave del autor, ISSN y UCI de su respuesta. Una lista de palabras clave vacía es un artefacto del endpoint. kci_search lo dice en cada llamada; kci_article las recupera.
KCI responde HTTP 200 en caso de error, poniendo el error en outputData/result/resultMsg. Un cliente que verifica los códigos de estado informa una clave no registrada como una búsqueda vacía exitosa.
Cada herramienta devuelve el sobre documentado en mediation.py (esquema 2.1.0) — query/script tipados, matching_mode, breadth graduado, matched_in por elemento, diagnostics tipados, un receipt registrable, y attribution. Nada se resume o puntúa por ti.
mediation.py 2.2.0 es la reconciliación de una bifurcación. Hasta el 19 de agosto de 2026, dos archivos diferentes se llamaban a sí mismos 2.1.0: la copia japonesa tenía emit() — persistencia de libro mayor — pero clasificaba el hangul como latin; la copia coreana conocía el hangul y las extensiones CJK pero no tenía emit(), por lo que las consultas coreanas nunca llegaban al depósito que toda consulta japonesa ingresaba. 2.2.0 lleva ambos, y está vendido byte-idéntico en cinii-mcp, jstage-mcp, ndl-mcp y este servidor. Todo en él es aditivo, por lo que los servidores japoneses lo adoptan sin migración.
detect_script() reconoce hangul y las extensiones CJK B–G más el Suplemento de Compatibilidad.
title y source llevan una ranura ko junto a ja.
emit() deposita el sobre en el libro mayor de consultas encadenado por hash; ledger_available() informa si puede hacerlo, en lugar de dejar un no-op silencioso.
title.romanized permanece null a menos que la fuente proporcione una romanización. Ni KCI ni OAK lo hacen, y este servidor no generará una: la Romanización Revisada de un nombre coreano requiere conocer el nombre, y una cadena transliterada por máquina presentada como dato bibliográfico es una fabricación con la forma de un hecho.
OK · NO_KEY · KCI_REJECTED · KCI_KEYWORDS_ABSENT · ZERO_CONJUNCTION · TRUNCATED · PAGE_PAST_END · REFERENCE_DEPOSIT_UNEVEN · BIBLIOMETRIC_SCOPE · SCRIPT_LATIN_QUERY · INGEST_DATE_NOT_PUBLICATION_DATE · CLIENT_SIDE_FILTER · OAI_MORE_AVAILABLE · OAI_INCOMPLETE · OAI_STALLED · OAI_PAGE_CAP · OAI_NO_RECORDS · OAI_ERROR · OAI_WINDOW_TRUNCATED · OAK_NONSTANDARD_DC · WINDOW_DOMINATED_BY_ONE_REPOSITORY · REDIRECTED · TRANSPORT_ERROR · API_ERROR · PARSE_ERROR
Python 3.10+ en PATH.
Opcionalmente, una clave API de KCI — gratuita, auto-registrada, requerida solo para las cuatro herramientas REST.
Regístrate en open.kci.go.kr y solicita una clave de Open API.
La misma clave sirve para los cinco valores de apiCode (articleSearch, articleDetail, referenceSearch, citation, citationDetail).
KCI también está reflejado como cuatro conjuntos de datos en data.go.kr bajo 한국연구재단; esa ruta emite una clave diferente y no se usa aquí.
El paquete usa una estructura src/ e instala un script de consola. Cualquiera de estas opciones funciona:
# from a release archive
pip install korea-scholarship-mcp.zip
# from a built wheel
pip install korea_scholarship_mcp-0.4.0-py3-none-any.whl
# from a clone, for development
pip install -e ".[dev]"
# without installing anything, straight from the repository
uvx --from "git+https://github.com/ckgerteis/korea-scholarship-mcp" korea-scholarship-mcpInstalar pone un comando korea-scholarship-mcp en PATH. python -m korea_scholarship_mcp es equivalente.
cp .env.example .envKCI_API_KEY=your_kci_api_key_hereSi el paquete está instalado, apunta al script de consola:
{
"mcpServers": {
"korea-scholarship": {
"command": "C:\\path\\to\\.venv\\Scripts\\korea-scholarship-mcp.exe",
"env": {
"KCI_API_KEY": "your_kci_api_key_here"
}
}
}
}O ejecútalo desde un clon sin instalar:
{
"mcpServers": {
"korea-scholarship": {
"command": "C:\\path\\to\\.venv\\Scripts\\python.exe",
"args": ["-m", "korea_scholarship_mcp"],
"env": {
"KCI_API_KEY": "your_kci_api_key_here"
}
}
}
}Omite el bloque env por completo para ejecutar las cuatro herramientas sin clave.
mcp 2.0.0 eliminó mcp.server.fastmcp. Este servidor importa FastMCP donde existe y recurre a MCPServer donde no, por lo que funciona en ambos. El mismo shim se aplicó a cinii-mcp y jstage-mcp el 19 de agosto de 2026; antes de eso, ambos importaban mcp.server.fastmcp directamente mientras fijaban mcp[cli]>=1.2.0 sin límite superior, por lo que una instalación nueva de cualquiera de ellos resolvía a 2.0.0 y fallaba en la importación.
La clave KCI viaja en la cadena de consulta, lo que la hace propensa a fugas de dos maneras específicas que este servidor cierra:
httpx registra cada URL de solicitud en INFO. _silence_http_logging() lo silencia y elimina cualquier manejador de stdout — necesario de todos modos, ya que stdout lleva JSON-RPC.
Las excepciones de transporte y estado incrustan la URL de la solicitud. Cada mensaje destinado al cliente pasa por _redact(), y el recibo se construye a partir de parámetros con las credenciales eliminadas en lugar de enmascaradas.
python -m pytest tests -q # offline, against fixtures captured 19 Aug 2026
RUN_LIVE=1 python -m pytest tests -q # also exercises the live KCI endpoints
RUN_LIVE_OAK=1 python -m pytest tests -q # adds OAK; needs a network that reaches oak.go.krLas pruebas en vivo protegen las afirmaciones en las que se basa este README: que una ventana de ingesta de KCI devuelve publicaciones más antiguas, que los identificadores de KCI están tipados, que max_records es un límite en lugar de una sugerencia, y que una cosecha con reanudación no registra una ventana de fechas que nunca envió. La prueba de OAK está separada y falla ruidosamente si OAK es inalcanzable en lugar de pasar en una rama no ejercitada.
Las cuatro herramientas REST de KCI nunca han visto una respuesta en vivo — no hay clave API. Su mapeo de campos sigue la documentación publicada y no está verificado contra el cable; la prueba de éxito/fracaso es deliberadamente estructural (registros presentes significa éxito) para que ni un mensaje de éxito locuaz ni un rechazo breve se lean mal. Trata la salida REST como provisional hasta que exista una clave.
ScienceON (KISTI) — deliberadamente fuera de alcance. Su puerta de enlace requiere un token AES-256-CBC construido a partir de una dirección MAC registrada, más una IP pública registrada. rubato103/scienceon-mcp ya lo implementa contra credenciales en vivo y está endurecido contra la ruta exacta de fuga de credenciales descrita anteriormente; instálalo junto a este en lugar de duplicar código de autenticación no comprobable:
claude mcp add scienceon -- uvx --from "git+https://github.com/rubato103/scienceon-mcp" scienceon-mcpRISS (KERIS) — la API de búsqueda existe en https://www.riss.kr/openApi y cubre tesis, artículos nacionales y extranjeros, monografías, informes de investigación y publicaciones periódicas, pero las claves se emiten solo a instituciones sin fines de lucro y universidades coreanas, cada solicitud aprobada por el personal de KERIS; los individuos no pueden solicitarlas. Si una universidad no coreana califica no está probado. Si alguna vez se obtiene una clave, RISS pertenece a este servidor.
DBpia (Nurimedia) — las claves son abiertas y generosas (2,500 llamadas al día), pero los términos de uso restringen el servicio a fines no comerciales y prohíben copiar, almacenar o transmitir los resultados de búsqueda, que deben mostrarse en tiempo real y sin alteraciones. Eso es incompatible con la cosecha en un gestor de referencias, un índice de corpus o un registro. La restricción es la licencia, no la API.
korea_sources_status informa los tres en el lugar, por lo que la omisión es visible desde dentro de la herramienta en lugar de solo en este archivo.
KCI y OAK son servicios del sector público sin límite de tasa publicado. Cosecha con consideración; divide las ventanas en lugar de golpear rangos amplios.
Los metadatos recuperados aquí son bibliográficos. El texto completo está detrás de los términos que establezca el repositorio que lo aloja — la contents_url de OAK apunta a repositorios miembros, cada uno con su propia licencia.
Las cadenas de atribución se devuelven en cada sobre; llévalas a cualquier cosa que publiques.
Si este software apoya tu investigación, por favor cítalo. Consulta CITATION.cff, o usa el botón "Cite this repository" en GitHub.
MIT © 2026 Christopher Gerteis.
Esta licencia cubre únicamente el código del servidor. No otorga ningún derecho sobre los datos de KCI o OAK, que siguen rigiéndose por los términos de la National Research Foundation of Korea y la National Library of Korea, respectivamente.
Una herramienta de investigación, mantenida sobre la base del mejor esfuerzo y proporcionada "tal cual", sin garantía. No está afiliada ni respaldada por la National Research Foundation of Korea, la National Library of Korea, KERIS, KISTI ni Nurimedia.
Dr Christopher Gerteis, SOAS University of London.
Compose DBpia addresses for the user to open; sends nothing to DBpia.
DBpia's terms forbid storing or transmitting its results, so this tool
never queries it. Give query, or any of title, author, journal
(joined into one search), and/or a DBpia node_id (NODE plus digits) for
the article page. The links come back under suggestions; items is
always empty because no record was retrieved. Open them in a browser signed
in to DBpia to see availability and price, and save with Zotero's DBpia
translator from there.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| title | No | ||
| author | No | ||
| journal | No | ||
| node_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so: it discloses the hard constraint (no query is ever sent), the auth requirement (must be signed in to DBpia to see availability and price), and a surprising output trait (`items` is always empty). That is exactly the kind of non-obvious behavior an agent cannot infer from schema alone.
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 core constraint is front-loaded and every sentence carries information (constraint, inputs, return shape, next action). Slightly long and line-broken for the amount of content, but no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter builder tool with an output schema, this covers the essentials: why it exists, what to pass, where results land, and what the user must do next. Minor incompleteness remains around tool-side edge cases (empty suggestions, conflicting inputs), but nothing an agent needs to call it correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: it maps title/author/journal to a single joined search string, and specifies the node_id format ("NODE plus digits") for article pages. The only gap is the unresolved precedence when multiple parameter groups are populated.
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?
"Compose DBpia addresses for the user to open; sends nothing to DBpia" names a concrete verb (compose), a concrete output (links/addresses), and immediately scopes it away from a search. The second sentence reinforces the distinction from the KCI/OAK retrieval siblings: this tool never retrieves records, so an agent cannot confuse it with a query tool.
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?
It tells the agent exactly what inputs to supply ("Give `query`, or any of `title`, `author`, `journal` ..., and/or a DBpia `node_id`") and what to do with the output (open in a signed-in browser, then save via Zotero's translator). The rationale for the constraint (DBpia's terms) makes the boundary clear. What's missing is precedence guidance when both query and bibliographic fields, or both node_id and a query, are supplied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full KCI record for one control number (e.g. ART001995054).
This is the only endpoint that carries author keywords, ISSN, author affiliations and the abstracts. Use it to repair records returned by kci_search.
| Name | Required | Description | Default |
|---|---|---|---|
| article_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description faithfully conveys the core behavior: a read-only retrieval of a full record, with no mutation implied. It adds meaningful context about scope and exclusivity, though it does not discuss error behavior or access prerequisites. The output schema covers return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences lead with the core definition and immediately add differentiating value. Every phrase contributes — no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with an output schema, the description is nearly complete: it states what the tool returns, why it is unique, and when to use it. Minor omissions like invalid-ID behavior are acceptable given the simple shape and existing output 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%, yet the description compensates by explaining article_id as a control number and giving a realistic example (ART001995054). That gives an agent enough to construct a valid call despite the sparse 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?
Clearly identifies a specific resource — the full KCI record for one control number — with a concrete example. It also distinguishes itself from sibling kci_search by naming the unique fields it carries (author keywords, ISSN, affiliations, abstracts).
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?
Explicitly tells the agent when to use this endpoint: to repair incomplete records returned by kci_search. The phrase 'the only endpoint that carries...' also communicates why it is the correct choice over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Harvest KCI by OAI-PMH — no API key required.
date_from/date_to are YYYY-MM-DD and select on KCI ingest datestamp,
not publication date: a July 2026 window returns articles published in
2015. There is no query interface, so contains is applied client-side to
whatever the window yielded. Sets: ARTI (article), ARTI_CONF (conference),
JOUR (journal).
This is a harvesting tool wearing a search tool's clothes. Treat a result as a slice of the accession stream, and say so in anything built on it.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | Yes | ||
| contains | No | ||
| set_spec | No | ARTI | |
| date_from | Yes | ||
| max_records | No | ||
| resumption_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals non-obvious behavior: the date window refers to KCI ingest datestamp rather than publication date, 'contains' is not a server-side query, and results are slices of the accession stream. This is genuinely transparent about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: the core identity comes first, then parameter semantics, then a useful mental-model warning. No sentence is wasted, and formatting highlights the most important caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers protocol, authentication, date semantics, filtering behavior, sets, and the right mental model for results. It does not explain resumption_token or max_records behavior, and it could be more explicit about when to prefer kci_search. Still, for an OAI-PMH harvesting tool, this is a strong and unusually complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains date_from/date_to format and semantics, clarifies 'contains' behavior, and enumerates the set_spec values. However, max_records and resumption_token are not explained beyond their names/defaults, leaving a small but real semantic gap.
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: 'Harvest KCI by OAI-PMH'. It also explicitly reframes the tool as a harvesting tool rather than a search tool, which distinguishes it from sibling tools like kci_search. The first sentence makes the tool's identity unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: date selection is on ingest datestamp, there is no query interface, and 'contains' is applied client-side. This implies that users needing true search should use another tool, but it does not explicitly name kci_search or say when not to use this tool. Still, the guidance is strong and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
KCI journal citation indices (impact factor, immediacy, self-citation share).
Supply journal for the list view or journal_id for one journal's
history. years must be 2–5.
These are bibliometric artefacts of a national index with a small, largely domestic citing population. They measure position within KCI, not standing in a field, and should not be used to rank scholarship.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| years | No | ||
| journal | No | ||
| journal_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so this description carries the disclosure burden, and it does so well: it explains the parameter-driven behavior (list vs. history), the `years` constraint, and the important interpretive limitation that these indices measure rank within KCI, not scholarly standing. It does not discuss data freshness or rate limits, but those are less critical for a read-only metrics query.
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?
Three short paragraphs with no fluff: definition, usage pattern, and a caveat that prevents misuse. Important information is front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and the safety profile simple, the description covers the key call contract: purpose, parameter modes, validation, and interpretation limits. The only real gaps are the unexplained `year` parameter and the lack of explicit sibling-tool routing, but those are minor for this query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must document the parameters itself. It explains `journal` (list view), `journal_id` (one journal's history), and `years` (2–5 range). However, it never explains the `year` parameter or how it relates to `years`, `journal`, and `journal_id`, leaving one parameter semantically unresolved.
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 opening line identifies the resource (KCI journal citation indices) and the exact metric set (impact factor, immediacy, self-citation share). The second paragraph's 'Supply ... for the list view or ... for history' clarifies the action and distinguishes the two primary call modes. It does not name a sibling tool, but the tool's scope is clear enough to separate it from kci_search, kci_article, and kci_references.
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 concrete usage guidance: use `journal` for a list view, `journal_id` for a single journal's history, and keep `years` in the 2–5 range. It does not, however, state when to choose this tool over the sibling KCI/korea tools or mention any exclusions, so the routing guidance 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.
Works cited by one KCI article (referenceSearch).
KCI's reference data is contributed by publishers and is uneven: an empty list is as likely to mean the publisher deposited no reference block as that the article cites nothing. Read it as a floor, never a count.
| Name | Required | Description | Default |
|---|---|---|---|
| article_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure and does so well by warning that an empty list may mean missing publisher data rather than zero citations. The 'floor, never a count' caveat is a meaningful behavioral trait beyond what the schema or output schema would reveal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and every sentence earns its place. The caveat about data quality is essential and presented without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup with an output schema available, the description adequately covers what the tool does and the critical data-quality caveat. It is slightly incomplete only in not addressing tool-selection context relative to its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one required parameter, article_id, and zero percent schema description coverage. The description implies that this parameter identifies a single KCI article, but it does not add explicit details about the expected format, provenance, or examples beyond what the parameter name and title convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the works cited by one KCI article, and the parenthetical 'referenceSearch' reinforces the operation. It is distinguishable from sibling tools such as kci_search and kci_article, though it lacks an explicit imperative verb like 'retrieve' or 'list.'
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 important interpretive guidance about KCI's reference data being uneven and empty lists being ambiguous, which helps an agent use results correctly. However, it does not explicitly state when to choose this tool over siblings or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search KCI articles (REST, requires KCI_API_KEY).
title is mandatory — the KCI API rejects a query without it, so a
subject-led search must be run as a title query and again as a keyword
query, and the two sets unioned by hand. date_from/date_to are YYYYMM.
rows is capped at 100 by the API.
Two asymmetries this tool reports rather than hides: articleSearch accepts
keyword as a search field but omits author keywords, ISSN and UCI from
its response, so an empty keywords list here means the endpoint did not
return them, not that the article has none — use kci_article to recover
them per record.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | ||
| page | No | ||
| rows | No | ||
| title | Yes | ||
| author | No | ||
| date_to | No | ||
| journal | No | ||
| keyword | No | ||
| abstract | No | ||
| date_from | No | ||
| affiliation | No | ||
| institution | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers richly: API key requirement, rejection of queries missing title, the 100-row cap, and the response asymmetry where omitted author keywords/ISSN/UCI produce an empty list that must not be interpreted as 'no keywords'. This is exactly the failure-mode disclosure that prevents an agent from confidently misinferring on empty data.
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?
Three paragraphs follow a logical progression (purpose → constraints/workflow → caveats), with every sentence carrying operational information and the purpose front-loaded in the first clause. It is dense rather than padded, though the subject-led workflow explanation could arguably be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with 0% schema coverage and no annotations, the description covers the critical constraints and the key response quirk well. It is incomplete mainly because seven filter parameters get no semantics anywhere, and the response asymmetry is disclosed narratively rather than per-field. The presence of an output schema mitigates the return-value gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds real semantics for title (mandatory), date_from/date_to (YYYYMM format), rows (API cap 100), and keyword (accepted as a search field but absent from the response). However, 7 of the 12 parameters — doi, page, author, journal, abstract, affiliation, institution — remain undocumented in both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Search KCI articles (REST, requires KCI_API_KEY)' names a specific verb, resource, and transport/auth context in one line. It also differentiates from the kci_article sibling by explicitly assigning per-record field recovery (keywords, ISSN, UCI) to that tool rather than this one.
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 explicit operational guidance: title is mandatory and the API rejects queries without it, so a subject-led search must be run as both a title query and a keyword query with the results unioned by hand. It also states an explicit alternative — use kci_article to recover keywords/ISSN/UCI — telling the agent exactly when this tool's output is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report which Korean sources are configured and reachable right now.
Checks the KCI REST key, the two keyless OAI endpoints, and states plainly what this server does not cover (ScienceON, RISS, DBpia) and why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does well by stating exactly what it checks (KCI REST key, two keyless OAI endpoints) and what it deliberately does not cover (ScienceON, RISS, DBpia) with reasons implied. It could add a note about being read-only, but the zero-parameter status-report nature makes side effects unlikely.
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 tight paragraphs: the first states the core purpose with a time qualifier ('right now'), and the second names the exact endpoints checked and the notable exclusions. Every sentence adds useful information, and the most important action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool with an output schema present, the description is complete. It covers what is checked, how authentication is handled (REST key vs keyless endpoints), what is not covered, and the fact that the report is a current runtime view. Nothing needed for an agent to call it correctly is missing.
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 tool has zero parameters, and schema description coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 applies because no parameter documentation burden exists.
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 a specific verb and object: 'Report which Korean sources are configured and reachable right now.' It then names the concrete checks involved (KCI REST key, two keyless OAI endpoints) and explicitly lists what is not covered, making the tool's scope unmistakable. This clearly distinguishes it from the sibling kci_* and oak_* tools, which are searching and harvesting tools.
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 makes the intended use case clear: checking current configuration and reachability of Korean sources. It does not name sibling alternatives explicitly, but it frames itself as a status/diagnostic tool, implying it should be used before or alongside harvest/search operations rather than as a content-fetching tool. It does not include explicit 'when not to use' guidance, but the scope is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Harvest Open Access Korea by OAI-PMH — no API key required.
date_from/date_to are YYYY-MM-DD ingest datestamps. OAK declares no set
hierarchy and — verified 19 Aug 2026 — sends no resumptionToken, so a
window returns at most about 99 records and there is no way to ask for the
rest. When the cap is hit this tool says so and tells you to narrow the
window; it will not present a truncated window as a complete one.
Windows are lumpy: a single repository's bulk deposit can fill one entirely, so the tool also reports which holding organisation dominates.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | Yes | ||
| contains | No | ||
| date_from | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It discloses the ~99-record cap, the absence of resumptionToken, the explicit self-reporting behavior when the cap is hit, and the refusal to present a truncated window as complete. It also discloses the dominant-holding-organization reporting behavior, which exceeds typical expectations.
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: purpose first, then parameter format, then limits and behavior. The paragraphs are longer than minimal but every sentence adds operational value—technical details like no resumptionToken and the verified date justify the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, required parameters, operational limits, and result caveats, while an output schema exists to handle return values. It is slightly incomplete because 'contains' is not explained and no explicit routing to sibling tools is provided, but the core invocation is fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly defines date_from and date_to as YYYY-MM-DD ingest datestamps, which is essential. However, the optional 'contains' parameter is never mentioned, leaving one parameter semantically unexplained.
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 first sentence states a specific verb ('Harvest'), target ('Open Access Korea'), method ('by OAI-PMH'), and a key requirement ('no API key required'). This clearly differentiates it from the KCI-oriented sibling tools even though no sibling is named.
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?
It gives concrete usage context: ingest-date windows, YYYY-MM-DD format, no set hierarchy, no resumptionToken, and the need to narrow the window when the cap is hit. It stops short of explicitly naming alternatives or saying when not to use this tool, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One OAK record by OAI identifier (oai:oak.go.kr:NNNNNNNN, or the bare number).
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the input format and that the result is one record; it does not explicitly confirm read-only behavior, what happens on missing identifiers, authentication needs, or any error conditions. The phrase 'One OAK record' is too vague to describe the tool's behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the resource and immediately gives the critical identifier format in parentheses. Every word adds value, and the example formats improve clarity without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the essential input knowledge (identifier format) and the resource name. However, it lacks any usage context relative to sibling tools and does not state expected behavior or edge cases. It is minimally sufficient for invoking the tool, but not thoroughly contextual.
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 provides only a 'string' type and the title 'Identifier', with 0% description coverage. The description compensates by explaining the accepted input formats: full OAI identifier with prefix or bare number. This is essential semantic information for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (a single OAK record) and the key identifier format (OAI identifier or bare number). It implies a retrieval operation even though the verb is not explicit. It is distinguishable from sibling tools like kci_article and oak_harvest by naming OAK records and the identifier-based lookup, though it does not explicitly contrast 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 no guidance on when to use this tool versus alternatives. It implies usage when you have an OAI identifier, but no exclusions or sibling comparisons are provided. An agent must infer the appropriate context from the identifier format alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.7.0dbpia_linksv0.5.0kci_articlekci_harvestkci_journal_metricskci_referenceskci_searchkorea_sources_statusoak_harvestoak_recordScored across 9 tools
Each tool targets a distinct source+operation (KCI search/article/harvest/metrics/references, OAK harvest/record, DBpia link composition, status check), and the descriptions explicitly delimit the tricky boundary between kci_search and kci_harvest. Minor residual overlap remains between kci_search and kci_article since both return article records, though the 'repair records' framing helps.
Naming follows a clear source-prefix scheme (kci_*, oak_*, dbpia_*) that makes family membership obvious. The lone outlier korea_sources_status breaks that pattern, and noun-style names (kci_article, kci_references, oak_record) are mixed with verb-style ones (kci_search, kci_harvest), but it remains readable and predictable.
Nine tools is squarely in the well-scoped range, and each earns its place by covering a distinct source or operation. Nothing looks redundant or bolted on, and the surface is small enough for an agent to hold in mind.
The surface covers the KCI lifecycle (search, full record, harvest, references, journal metrics) and OAK harvest/record, with explicitly justified exclusions (ScienceON, RISS, DBpia search) surfaced by a status tool. Gaps are minor: no cross-source unified search, no OAK metadata search (only harvest plus identifier lookup), and no built-in export/citation formatting.
OpenCitations MCP — citation index (COCI + general Index API).
CORE Research MCP — wraps CORE API (api.core.ac.uk/v3)
MCP server for Altmetric APIs - track research attention across news, policy, social media, and more
Search and retrieve bioRxiv and medRxiv preprints — by DOI, date interval, or keyword — via MCP.
