This server provides access to the Korea Citation Index (KCI) Open API, translating XML responses to JSON via MCP tools. Here's what you can do:
Search Articles (kci_search_articles): Find academic papers by title, author, journal name, keyword, abstract, DOI, affiliation, institution, and date range. Returns journal details, authors, abstracts, keywords, and citation counts.
Get Article Detail (kci_get_article_detail): Retrieve comprehensive details for a specific article using its KCI Control Number (e.g., ART002358582), including author affiliations, full-text URL, DOI, UCI, FWCI, and citation counts.
Search References (kci_search_references): Look up the reference lists of articles matching a given title, author, institution, or publication year — i.e., see what sources those papers cited.
Get Journal Citations (kci_get_journal_citations): Query citation index metrics (impact factor, immediacy index, self-citation rate) for journals by base year and inclusion window (2–5 years).
Get Citation Detail (kci_get_citation_detail): Retrieve detailed citation history for a specific journal by its Control Number, including registration info, publisher details, name change history, and yearly citation index records (3/4/5-year impact factor, SJR, self-citation ratio).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kci-mcp-server search references for 'AI ethics' in KCI journals"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
KCI(한국학술지인용색인, Korea Citation Index) Open API를 호출하는 MCP(Model Context Protocol) 서버입니다.
KCI 포털(https://www.kci.go.kr) 회원가입
Open API 인증키 신청서 작성 후 한국연구재단(kciadmin@nrf.re.kr)에 공문 발송
인증키 발급 완료 후 아래 환경변수에 설정
Related MCP server: KISTI-MCP
git clone https://github.com/iapke486-arch/mcp-server.git
cd mcp-server
npm install
npm run buildKCI_API_KEY=발급받은인증키 node --use-system-ca build/index.jsWindows PowerShell:
$env:KCI_API_KEY = "발급받은인증키"
node --use-system-ca build/index.js
--use-system-ca플래그가 필요한 이유: 사내망/회사 프록시가 TLS 트래픽을 검사(SSL 인터셉션)하는 환경에서는 Node.js의 기본 인증서 목록에 없는 사설 루트 인증서가 응답에 포함되어self-signed certificate in certificate chain오류로 요청이 실패할 수 있습니다.--use-system-ca(Node 22+)는 Windows 인증서 저장소를 함께 신뢰하도록 하여 이 문제를 해결합니다. 이런 프록시 환경이 아니라면 없어도 무방합니다.
claude_desktop_config.json(보통 %APPDATA%\Claude\claude_desktop_config.json)에 아래와 같이 등록합니다.
{
"mcpServers": {
"kci": {
"type": "stdio",
"command": "node",
"args": ["--use-system-ca", "/path/to/mcp-server/build/index.js"],
"env": {
"KCI_API_KEY": "발급받은인증키"
}
}
}
}경로 예시:
Windows: C:/Users/YourName/Documents/projects/mcp-server/build/index.js
macOS/Linux: /home/username/projects/mcp-server/build/index.js
claude mcp add --env KCI_API_KEY=발급받은인증키 -- node --use-system-ca /path/to/mcp-server/build/index.js
# 모든 프로젝트에서 사용하려면 사용자 전역 스코프로 등록
claude mcp add --scope user --env KCI_API_KEY=발급받은인증키 -- node --use-system-ca /path/to/mcp-server/build/index.jsClaude Code: /mcp 목록에서 kci 서버가 ✓ Connected 상태인지 확인하세요.
Tool | KCI API Code | 설명 |
|
| 제목/저자/저널명 등으로 논문 기본 정보 검색 |
|
| 논문 제어번호로 상세 정보 조회 (초록, 키워드, DOI, FWCI, 피인용 횟수 등) |
|
| 논문의 참고문헌 목록 조회 |
|
| 기준년도별 저널 인용지수(영향력 지수 등) 목록 조회 |
|
| 저널 제어번호로 인용지수 상세 이력 조회 |
모든 도구는 KCI Open API가 XML로 응답하는 데이터를 JSON으로 변환하여 반환합니다.
KCI Open API는 XML 응답만 지원하며, 이 서버는 내부적으로 XML을 JSON으로 파싱해 반환합니다.
인증키가 만료되었거나 잘못된 경우, KCI가 반환하는 원본 오류 메시지를 그대로 전달합니다.
KCI 서버는 displayCount 파라미터 값과 무관하게 기본 10건을 반환하는 경우가 있습니다(KCI 서버 자체의 동작이며 클라이언트 코드 문제가 아님). 정확한 전체 건수는 응답의 result.total 값을 참고하세요.
KCI 논문 제어번호(Control Number, 예: ART002358582)로 논문의 상세 정보(저자 소속, 원문 URL, DOI, UCI, FWCI, 피인용 횟수 등)를 조회합니다. 제어번호는 kci_search_articles 결과의 article-id 값입니다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | KCI 논문 제어번호 (Control Number, 예: ART002358582) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully compensates by stating that it reads data (조회) and listing returned fields like author affiliations, URL, DOI, etc. There is no contradiction.
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 concise sentences that front-load the purpose, provide a concrete example, and explain how to obtain the required input. No wasted words.
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?
Given the simple single-parameter tool and no output schema, the description fully covers the needed context: what the input is, how to get it, and what information will be returned.
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 description adds significant meaning beyond the schema: it explains the parameter as 'KCI 논문 제어번호' with an example, and crucially tells the agent that the value should come from another tool's result. Schema coverage is 100% but the description enriches it.
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 states the tool's purpose: retrieve article details from KCI using a control number, listing specific fields. It differentiates from siblings by specifying the input (control number) and output (detailed info), and explains the relationship with kci_search_articles.
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 explicitly indicates when to use the tool (after obtaining a control number from kci_search_articles) and provides context for the input. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
저널(학술지) 제어번호로 해당 저널의 등재 정보, 발행 기관 정보, 학술지 변경 이력, 연도별 인용지수 이력(영향력 지수 3/4/5년, SJR, 자기인용비율 등)을 상세 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 저널(학술지)의 제어 번호 (Control Number) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It clearly states this is a read-only retrieval operation (상세 조회) and lists the types of data returned. It does not mention side effects, authentication, or rate limits, but the absence is acceptable for a simple read tool. The disclosure of return content is sufficient.
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 sentence that front-loads the core action and then lists specific data categories. Every word adds value, and there is no redundant or off-topic content. It is highly efficient.
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 input (control number) and enumerates the types of output (registration, institution, change history, citation history). Given the simple schema (1 parameter, no output schema), this is largely complete. Lacking only is mention of output format or potential errors, which are minor omissions.
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 input schema already provides a description for the only parameter (id: control number). The tool description merely restates 'journal control number' without adding new semantics, format constraints, or examples. Since schema coverage is 100%, a baseline of 3 is appropriate.
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 specifies the verb (상세 조회, retrieve detailed information), the resource (저널/학술지, journal), and the method (by 제어번호, control number). It lists specific data types (registration info, citation history) that clearly differentiate it from sibling tools like kci_get_article_detail or kci_get_journal_citations.
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 implies usage when the user has a journal control number and needs detailed citation and registration data. However, it does not provide explicit guidance on when not to use it or how it compares to siblings (e.g., ‘for article-level data, use kci_get_article_detail’). The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
기준년도(year)와 포함년도(years)를 기준으로 저널(학술지)들의 인용지수(영향력 지수, 즉시성 지수, 자기인용 비율 등) 목록을 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | DOI | |
| page | No | 페이지 번호 | |
| year | Yes | 기준년도 (YYYY, 필수) | |
| years | Yes | 포함 년도 수 (2~5, 필수, 기본 2) | |
| sortNm | No | 정렬 기준: title(제목), author(저자명), pubiYr(발행일자) | |
| journal | No | 저널(학술지) 이름 | |
| sortDir | No | 정렬 방향: asc(오름차순), desc(내림차순) | |
| modDateTo | No | 수정일 끝 (YYYYMMDD) | |
| institution | No | 발행 기관명 | |
| modDateFrom | No | 수정일 시작 (YYYYMMDD) | |
| displayCount | No | 출력 건수 (기본 10, 최대 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, side effects, or permissions. It only states what the tool retrieves, leaving behavior largely unspecified.
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 in Korean. It front-loads the key parameters and purpose without any redundant or unclear phrasing.
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 mentions examples of returned data but does not explain pagination, sorting, or other parameters' roles. For a tool with 11 parameters and no output schema, more detail would improve completeness.
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 100%, so baseline is 3. The description adds value by listing specific citation indices (영향력 지수, 즉시성 지수, 자기인용 비율 등) that are returned, which is beyond what input schema provides.
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 states the tool retrieves citation indices (impact factor, immediacy index, self-citation rate) for journals based on year and years. It distinguishes from sibling tools which focus on article details, citation details, or search.
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 implies use when needing journal citation indices by year range, but does not explicitly state when to use this tool versus alternatives or provide exclusions. No usage guidance beyond implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
KCI(한국학술지인용색인)에 등재된 논문을 제목, 저자, 저널명 등으로 검색하여 기본 정보(저널 정보, 저자, 초록, 키워드, 피인용 횟수 등)를 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | DOI | |
| page | No | 페이지 번호 | |
| title | Yes | 논문 제목 (필수, 검색 키워드) | |
| author | No | 저자 이름 | |
| dateTo | No | 발행년월 끝 (YYYYMM, 6자리) | |
| sortNm | No | 정렬 기준: title(제목), author(저자명), pubiYr(발행일자) | |
| journal | No | 저널(학술지) 이름 | |
| keyword | No | 키워드 | |
| sortDir | No | 정렬 방향: asc(오름차순), desc(내림차순) | |
| abstract | No | 초록 검색어 | |
| dateFrom | No | 발행년월 시작 (YYYYMM, 6자리) | |
| modDateTo | No | 수정일 끝 (YYYYMMDD, 8자리) | |
| regDateTo | No | 등록일 끝 (YYYYMMDD, 8자리) | |
| affiliation | No | 저자 소속 기관명 | |
| institution | No | 발행 기관명 | |
| modDateFrom | No | 수정일 시작 (YYYYMMDD, 8자리) | |
| regDateFrom | No | 등록일 시작 (YYYYMMDD, 8자리) | |
| displayCount | No | 출력 건수 (기본 10, 최대 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states 'retrieves basic information' without disclosing traits like pagination, rate limits, or read-only nature. The presence of 'displayCount' parameter implies pagination, but not explained.
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?
Single sentence that effectively communicates the tool's purpose and scope. No unnecessary words, front-loaded with action verb and target resource.
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?
Adequate but incomplete: describes general functionality but lacks details on output format, pagination behavior, or handling of large result sets. For a search tool with 18 parameters, more contextual framing would help.
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 coverage is 100%, so baseline is 3. The description mentions key parameters (title, author, journal) but adds no new semantics beyond the schema definitions. No enrichment of meaning.
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 states the tool's function: searching KCI-registered articles by various fields (title, author, journal) and retrieving basic info. It implies a search-and-list capability, distinguishing it from sibling tools like kci_get_article_detail which likely provides full details on a single article.
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?
No explicit guidance on when to use this tool versus alternatives. The description is generic and does not specify use cases, prerequisites, or exclusions, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
특정 제목/저자/기관/연도로 검색되는 논문들이 인용한 참고문헌 목록을 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 검색할 논문 제목 (필수) | |
| author | No | 저자명 | |
| pubiYr | No | 발행년도 (YYYY) | |
| sortNm | No | 정렬 기준: title(제목), author(저자명), pubiYr(발행일자) | |
| sortDir | No | 정렬 방향: asc(오름차순), desc(내림차순) | |
| institution | No | 발행 기관명 | |
| displayCount | No | 출력 건수 (기본 10, 최대 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention whether the operation is read-only, destructive, or has side effects. Also missing are details on pagination, rate limits, or any constraints beyond the input schema. The description only states what the tool does, not its behavioral characteristics.
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, well-formed sentence that covers the essential purpose. It is front-loaded and avoids unnecessary verbosity. However, it could be slightly improved by adding structure (e.g., separating search criteria from output description) without increasing length significantly.
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?
Given the tool has 7 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the return format, pagination behavior, or how results correspond to input parameters. A more complete description would provide an overview of the response structure and any limitations.
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 100%, so the baseline is 3. The description adds context that parameters are used to search for papers whose references are retrieved, but it does not provide additional semantics beyond what the schema descriptions already specify (e.g., format constraints, default values). Thus, it meets the baseline without significant added value.
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 states the tool's action ('조회합니다' - retrieves) and resource ('참고문헌 목록' - reference list) with specific search criteria (title, author, institution, year). It effectively distinguishes from sibling tools like kci_search_articles (which searches articles) and kci_get_citation_detail (which gets citation details).
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 no explicit guidance on when to use this tool versus alternatives. While the purpose implies its use for retrieving references, there is no mention of when not to use it, prerequisites, or comparison with sibling tools. This lack of contextual guidance reduces its helpfulness for an AI agent deciding between tools.
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.1.0kci_get_article_detailkci_get_citation_detailkci_get_journal_citationskci_search_articleskci_search_referencesScored across 5 tools
Each tool targets a distinct operation: searching articles, getting article details, journal citation details, journal citation lists, and reference searching. Descriptions clearly differentiate them.
All tools follow the consistent pattern 'kci_<verb>_<noun>' (e.g., kci_search_articles, kci_get_article_detail) with all lowercase and underscores.
5 tools appropriately cover the core functionalities of a citation index server: search, article details, journal citation details, citation lists, and reference searching. Neither too few nor too many.
The tool set covers key research workflows (search, article details, citation info). A minor gap might be a dedicated journal search tool, but kci_get_journal_citations partially fills that role. Overall well-scoped.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Search biomedical papers, inspect publication records, and traverse citation or semantic graphs.
Search 150M+ academic works, journals, and funders via Crossref API.
Look up Korean drug ingredient and product data by HIRA component and product codes via Pilldoc. V…
