Сервер FastMCP stdio, предоставляющий две корейские библиографические службы — Korea Citation Index (KCI, 한국학술지인용색인, Национальный исследовательский фонд Кореи) и Open Access Korea (OAK, 오픈액세스코리아, Национальная библиотека Кореи) — в виде восьми инструментов для Claude Desktop и других MCP-клиентов.
Это корейский аналог cinii-mcp и jstage-mcp, возвращающий ту же обёртку ответа, так что все три можно читать бок о бок в трёхсторонней работе.
Инструмент | Источник | Требуется ключ | Назначение |
| KCI REST | да | Поиск статей по названию, автору, журналу, учреждению, аффилиации, ключевому слову, аннотации, DOI, диапазону дат |
| KCI REST | да | Полная запись по контрольному номеру — единственная конечная точка, содержащая ключевые слова, ISSN, UCI и аннотации |
| KCI REST | да | Произведения, цитируемые в одной статье |
| KCI REST | да | Индексы цитируемости журнала (импакт-фактор, индекс оперативности, доля самоцитирования) |
| KCI OAI-PMH | нет | Сбор по окну дат поступления, фильтрация на стороне клиента, следование токенам возобновления |
| OAK OAI-PMH | нет | Сбор корейских институциональных репозиториев по окну дат поступления |
| OAK OAI-PMH | нет | Одна запись OAK по идентификатору OAI |
| — | — | Что настроено, что доступно и что этот сервер не охватывает |
Четыре из восьми работают вообще без учётных данных — всё OAI-PMH, а также статус.
Related MCP server: Literatür MCP
KCI индексирует статьи в корейских рецензируемых журналах. Он не индексирует монографии, главы или диссертации. Его REST-интерфейс — это настоящий интерфейс запросов; его интерфейс OAI-PMH — нет.
OAK агрегирует корейские институциональные репозитории — отчёты об исследованиях, диссертации, монографии, фонды 고서, статьи открытого доступа — неравномерно пополняемые учреждениями-участниками.
Обе службы были протестированы вживую 19 августа 2026 года, и три свойства определяют, как написаны инструменты:
Метки времени OAI — это даты поступления, а не публикации. Окно сбора за май 2019 года возвращает статьи, опубликованные в период с 2010 по 2015 год. Часто повторяемое утверждение, что канал OAI KCI раскрывает только недавние материалы, является неверным прочтением этого: канал охватывает весь корпус, просто его невозможно ни о чём спросить. Поэтому kci_harvest фильтрует на стороне клиента и сообщает об этом в диагностике при каждом вызове.
1a. oai_dc у KCI полностью типизирован, и этот сервер читает типы. По результатам измерений на 500 живых записях: identifier[type=artiId|uci|doi|citedCnt|regularity|journalInfo], атрибут issn= в 500/500 и lang="original|english" в каждом заголовке и описании. Версия 0.2.0 утверждала обратное — «позиционный нетипизированный мешок», который нужно сопоставлять по шаблону, — и, следовательно, отбрасывала все ISSN, все аннотации и 371 реальный DOI на 500 записей. Сопоставление по шаблону остаётся только как запасной вариант для идентификаторов, поступающих без тегов. Обратите внимание, что KCI также выдаёт элементы type="doi", содержащие только префикс резолвера; они нормализуются до null, а не передаются как идентификаторы.
OAK не отправляет resumptionToken. Он объявляет noSetHierarchy, соблюдает from/until и ограничивает окно примерно 99 записями без продолжения. Сборщик, доверяющий протоколу, молча выдаст усечённое окно за полное. oak_harvest вызывает OAI_WINDOW_TRUNCATED при достижении предела и сообщает вам о необходимости разбить окно.
OAK — это не стандартный Dublin Core. Он выдаёт dc:title_h, dc:abstract_e, dc:publish_date, dc:location_org, dc:deep_link, dc:contents_url и помещает тип материала в dc:keyword. Наличие полей зависит от репозитория-источника. Нераспознанные поля сохраняются в extra.raw_fields, а не отбрасываются.
Ещё две асимметрии сообщаются, а не сглаживаются:
articleSearch в KCI принимает keyword как поле поиска, но опускает авторские ключевые слова, ISSN и UCI в ответе. Пустой список ключевых слов — артефакт конечной точки. kci_search сообщает об этом при каждом вызове; kci_article восстанавливает их.
KCI отвечает HTTP 200 при ошибке, помещая ошибку в outputData/result/resultMsg. Клиент, проверяющий коды состояния, сообщит о незарегистрированном ключе как об успешном пустом поиске.
Каждый инструмент возвращает обёртку, описанную в mediation.py (схема 2.1.0) — типизированные query/script, matching_mode, градуированную breadth, поэлементный matched_in, типизированные diagnostics, журналируемый receipt и attribution. Ничего не обобщается и не оценивается за вас.
mediation.py 2.2.0 — это примирение форка. До 19 августа 2026 года два разных файла называли себя 2.1.0: в японской копии был emit() — сохраняемость реестра, — но хангыль классифицировался как latin; корейская копия знала хангыль и расширения CJK, но не имела emit(), поэтому корейские запросы никогда не попадали в реестр, в который попадал каждый японский запрос. В 2.2.0 есть и то и другое, и он поставляется байт-в-байт одинаковым в cinii-mcp, jstage-mcp, ndl-mcp и этом сервере. Всё в нём аддитивно, поэтому японские серверы принимают его без миграции.
detect_script() распознаёт хангыль и расширения CJK B–G, а также Дополнение для совместимости.
title и source содержат слот ko наряду с ja.
emit() помещает обёртку в хэш-связанный реестр запросов; ledger_available() сообщает, может ли он это сделать, а не оставляет молчаливую заглушку.
title.romanized остаётся null, если источник не предоставляет романизацию. Ни KCI, ни OAK этого не делают, и этот сервер не будет её генерировать: исправленная романизация корейского имени требует знания имени, а строка, транслитерированная машиной и представленная как библиографические данные, — это фабрикация, имеющая форму факта.
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+ в PATH.
Необязательно ключ API KCI — бесплатный, регистрируется самостоятельно, требуется только для четырёх инструментов REST.
Зарегистрируйтесь на open.kci.go.kr и подайте заявку на ключ Open API.
Один и тот же ключ обслуживает все пять значений apiCode (articleSearch, articleDetail, referenceSearch, citation, citationDetail).
KCI также зеркалируется в виде четырёх наборов данных на data.go.kr под именем 한국연구재단; этот путь выдаёт другой ключ и здесь не используется.
Пакет использует структуру src/ и устанавливает консольный скрипт. Подойдёт любой из этих вариантов:
# 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-mcpУстановка помещает команду korea-scholarship-mcp в PATH. python -m korea_scholarship_mcp эквивалентна.
cp .env.example .envKCI_API_KEY=your_kci_api_key_hereЕсли пакет установлен, укажите на консольный скрипт:
{
"mcpServers": {
"korea-scholarship": {
"command": "C:\\path\\to\\.venv\\Scripts\\korea-scholarship-mcp.exe",
"env": {
"KCI_API_KEY": "your_kci_api_key_here"
}
}
}
}Или запустите его из клона без установки:
{
"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"
}
}
}
}Полностью опустите блок env, чтобы запустить четыре инструмента без ключа.
mcp 2.0.0 удалил mcp.server.fastmcp. Этот сервер импортирует FastMCP, где он есть, и возвращается к MCPServer, где его нет, поэтому он работает в любом случае. Тот же самый шим был применён к cinii-mcp и jstage-mcp 19 августа 2026 года; до этого оба импортировали mcp.server.fastmcp напрямую, закрепляя mcp[cli]>=1.2.0 без верхней границы, поэтому свежая установка любого из них разрешалась в 2.0.0 и падала при импорте.
Ключ KCI передаётся в строке запроса, что делает его уязвимым для утечки двумя конкретными способами, которые этот сервер закрывает:
httpx регистрирует каждый URL запроса на уровне INFO. _silence_http_logging() отключает это и удаляет любой обработчик stdout — что в любом случае необходимо, поскольку stdout несёт JSON-RPC.
Исключения транспорта и состояния содержат URL запроса. Каждое сообщение, предназначенное клиенту, проходит через _redact(), а квитанция формируется из параметров с удалёнными учётными данными, а не с замаскированными.
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.krЖивые тесты защищают утверждения, на которых основан этот README: что окно поступления KCI возвращает более старые публикации, что идентификаторы KCI типизированы, что max_records — это предел, а не подсказка, и что возобновляемый сбор не записывает окно дат, которое он никогда не отправлял. Тест OAK отдельно ограничен и громко падает, если OAK недоступен, а не проходит на невыполненной ветке.
Четыре инструмента KCI REST никогда не видели живого ответа — нет ключа API. Их сопоставление полей следует опубликованной документации и не проверено на проводе; тест успеха/неудачи намеренно структурный (наличие записей означает успех), чтобы ни многословное сообщение об успехе, ни краткий отказ не были истолкованы неверно. Считайте вывод REST предварительным, пока не появится ключ.
ScienceON (KISTI) — намеренно вне области охвата. Его шлюз требует токен AES-256-CBC, созданный из зарегистрированного MAC-адреса, а также зарегистрированный публичный IP-адрес. rubato103/scienceon-mcp уже реализует его с реальными учётными данными и защищён от описанного выше пути утечки учётных данных; установите его рядом, а не дублируйте непроверяемый код аутентификации:
claude mcp add scienceon -- uvx --from "git+https://github.com/rubato103/scienceon-mcp" scienceon-mcpRISS (KERIS) — поисковый API существует по адресу https://www.riss.kr/openApi и охватывает диссертации, отечественные и зарубежные статьи, монографии, отчёты об исследованиях и серийные издания, но ключи выдаются только корейским некоммерческим учреждениям и университетам, каждая заявка одобряется сотрудниками KERIS; физические лица не могут подать заявку. Отвечает ли неккорейский университет требованиям, не проверялось. Если ключ когда-нибудь будет получен, RISS принадлежит этому серверу.
DBpia (Nurimedia) — ключи открыты и щедры (2500 вызовов в день), но условия использования ограничивают сервис некоммерческими целями и запрещают копирование, хранение или передачу результатов поиска, которые должны отображаться в реальном времени и без изменений. Это несовместимо со сбором в менеджер ссылок, индекс корпуса или реестр. Ограничение — это лицензия, а не API.
korea_sources_status сообщает обо всех трёх на месте, так что упущение видно изнутри инструмента, а не только в этом файле.
KCI и OAK — государственные сервисы без опубликованного лимита запросов. Собирайте данные благоразумно; нарезайте окна, а не долбите по широким диапазонам.
Метаданные, полученные здесь, являются библиографическими. Полный текст находится на условиях, установленных репозиторием-держателем — contents_url OAK указывает на репозитории-участники, каждый со своей лицензией.
Строки атрибуции возвращаются в каждой обёртке; переносите их в любые публикации.
Если это программное обеспечение поддерживает ваше исследование, пожалуйста, процитируйте его. См. CITATION.cff или используйте кнопку «Cite this repository» на GitHub.
MIT © 2026 Christopher Gerteis.
Эта лицензия распространяется только на серверный код. Она не предоставляет никаких прав на данные KCI или OAK, которые по-прежнему регулируются условиями National Research Foundation of Korea и National Library of Korea соответственно.
Исследовательский инструмент, поддерживаемый по мере возможностей и предоставляемый «как есть», без гарантий. Не аффилирован с National Research Foundation of Korea, National Library of Korea, KERIS, KISTI или Nurimedia и не одобрен ими.
Dr Christopher Gerteis, SOAS University of London.
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.5.0kci_articlekci_harvestkci_journal_metricskci_referenceskci_searchkorea_sources_statusoak_harvestoak_recordScored across 8 tools
Each tool targets a different function—search, record detail, references, journal metrics, OAI harvesting, or source status—and the descriptions explicitly distinguish overlapping endpoints such as kci_search vs kci_harvest. The KCI search/detail pair is clearly separated by 'use kci_article to repair records returned by kci_search', so an agent should not confuse them. No two tools appear to do the same thing.
All tool names are lowercase, snake_case, and consistently source-prefixed (kci_, oak_, korea_). However, the set mixes noun-style retrieval names (kci_article, kci_references, kci_journal_metrics, oak_record) with verb-style names (kci_search, kci_harvest, oak_harvest), so it is readable but not a uniform verb_noun convention. This is a minor deviation rather than chaos.
Eight tools is a well-scoped size for a Korean scholarship metadata server covering two source families plus a status tool. Each tool contributes a distinct capability—search, detail, references, metrics, harvesting, and operational health—so none feels redundant or out of place.
The set covers KCI search, detail, references, journal metrics, and OAI harvesting, plus OAK harvesting, OAK record retrieval, and source status. The main minor gaps are the lack of an OAK search endpoint and the hard ~99-record harvest cap, but the tool descriptions explicitly document these and offer workarounds such as narrowing windows or using kci_article to enrich search results.
OpenCitations MCP — citation index (COCI + general Index API).
CORE Research MCP — wraps CORE API (api.core.ac.uk/v3)
IEEE Xplore MCP — BYOK wrapper over the IEEE Xplore Metadata Search API
MCP server for Altmetric APIs - track research attention across news, policy, social media, and more
