kci-openapi-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Each tool has a clear primary purpose (status, search, detail, references, citations, harvest, collect), but kci_collect overlaps with kci_search and kci_harvest as an automated wrapper, requiring extra attention to decide when to use it instead of the specific tools.
Naming Consistency5/5
All tool names follow the consistent pattern 'kci_' followed by a lowercase noun or verb (status, search, detail, references, harvest, etc.), with no mixed conventions or abbreviations. The prefix uniformly signals the domain.
Tool Count5/5
Seven tools is well within the ideal 3-15 range for a scholarly API wrapper. Each tool maps to a distinct API capability (health check, search, detail, references, citation metrics, OAI harvest, and a collection convenience layer), leaving no sense of bloat or thinness.
Completeness4/5
The coverage is strong for read-only scholarly data: search, detail, references, journal citation, and bulk harvest all present. A minor gap is that references cannot be fetched directly by control number, only via title search, but the automated collection tool compensates by combining routes.
Average 3.9/5 across 7 of 7 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on August 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful context about REST protocol and API key requirements, which goes beyond annotations, but it does not disclose return format, pagination, or potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and scope. The inclusion of REST and auth-key requirements is useful, though it could be structured more explicitly with parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, zero schema coverage, and no output schema, the description is too minimal to make the tool fully usable. It omits parameter semantics, response format, and usage context relative to sibling tools, leaving significant gaps for an agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning, but it only mentions title-based search. The parameters rows, author, and pub_year are left undefined, leaving the agent without sufficient semantic guidance for their use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: collecting raw references from papers matching a title search term. The specific resource (참고문헌 원형) and condition (제목 검색어에 매칭된 논문들) distinguish it from general-purpose tools, though explicit sibling differentiation is absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like kci_search or kci_collect. The description implies usage for reference harvesting but gives no exclusions or context-dependent recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the tool writes files (out_dir), requires an authentication key for REST mode, uses date formats (YYYY-MM-DD for OAI, integer years for REST), and defaults to home kci-output/. This adds useful context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and bulleted, conveying the main routing logic in a few lines. Every sentence adds value, though the opening '[혼용]' is a bit cryptic. Overall it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (12) and lack of output schema, the description explains the core decision logic and default behavior but does not describe return values, the effect of max_records, or the formats parameter. This leaves some gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains terms/title, contains, year_from/year_to, date_from/date_until, set_spec (implicitly), and out_dir. However it omits semantics for name, formats, and max_records, leaving those parameters underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it collects records and saves them to a file, with automatic selection between REST and OAI protocols based on query presence and authentication key. This distinguishes it from sibling tools like kci_search (searching without file saving), though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides internal routing rules (when to use REST vs OAI) but no guidance on when to choose this tool over siblings such as kci_harvest or kci_search. There are no explicit 'when not to use' statements or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description adds that this is a REST API requiring an API key, and provides specific constraints like date format (YYYYMM) and row limit (max 100). This is useful behavioral context not present in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—three short sentences that front-load the core purpose, then add prerequisites and parameter details. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the essential context: purpose, auth requirement, alternative tool, and key parameter formats. However, it does not describe the return value or output structure, and lacks explanations for most filter parameters. Given no output schema, a bit more detail on what the search returns would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only explains date_from/date_to and rows. The other seven parameters (doi, author, journal, keyword, abstract) are left unexplained, leaving users to guess their expected formats or semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a paper search tool (논문 검색) with title as required and optional filters. It also differentiates from the kci_harvest sibling by mentioning the alternative for no-auth users. However, it doesn't distinguish from other sibling tools like kci_detail or kci_references, so not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use kci_harvest (OAI no-auth) when an API key is not available, providing a clear alternative. It also states that title is required and mentions optional filters, giving context on when to use this tool. However, it doesn't cover all sibling tools or more nuanced selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds the API key requirement and clarifies the two operational modes (year/year range for list, journal_id for detail), which is valuable context beyond annotations. However, it does not describe pagination or response formatting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the tool's purpose and key parameters with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the API key, list/detail modes, and detail content (registration history and yearly IF), but with no output schema it does not describe the list response structure or the rows parameter behavior, making it incomplete for thorough understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that year and years (2-5) drive list queries and journal_id drives detail, but it does not explain the rows parameter or how it interacts with the others, leaving a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a journal citation index REST API with two distinct modes: listing by year (with years range) and retrieving details by journal_id. It is specific and distinguishable from sibling tools like kci_search and kci_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for citation index lookups and outlines the parameter-driven modes, but it does not explicitly state when to choose this tool over alternatives or provide exclusions. It mentions the API key requirement as a prerequisite, which is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and open-world behavior, and the description adds valuable context: it's an OAI-PMH harvest requiring no authentication, and the 'contains' filter is a local post-filter rather than a server-side query. This discloses behavior not evident from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact block with a leading summary and a short parameter legend. Every sentence delivers useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers all critical parameters and usage conditions, but does not describe the return format or pagination behavior, which is relevant for a bulk harvest tool. However, with no output schema, the description could have mentioned output details; still, the provided info is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description manually explains the meaning and allowed values for set_spec (ARTI/ARTI_CONF/JOUR), date formats (YYYY-MM-DD), metadata_prefix (oai_kci/oai_dc), and contains (local filter on title/abstract/keywords). It also specifies the no-auth condition, leaving only max_records implicit, which is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '세트+날짜범위 대량 수확' (batch harvest by set+date range) and identifies the OAI-PMH protocol and no-auth requirement. This clearly differentiates it from siblings like kci_search/kci_detail which are not bulk harvesting operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for bulk harvesting via '대량 수확' and notes no auth key is needed, but does not explicitly compare against sibling tools or state when not to use it. There is no mention of alternatives like kci_search for targeted queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds the API key requirement and the exact returned content (details, abstract, keywords, author), providing behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It front-loads the REST nature and immediately specifies the key identifier and output, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with one parameter, the description covers the input format, output scope, and auth requirement. It does not discuss error scenarios, but this is not critical for a basic retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for arti_id, but the description explains it as 'Control Number(ART…)', adding critical semantic meaning. This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb '조회' (retrieve) with resource '논문 상세·초록·키워드·저자' and specifies the method 'Control Number(ART…)'. This clearly distinguishes it from sibling tools like kci_search, which handles search queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the input type (Control Number ART...) and the API key requirement, implying this tool should be used when a specific control number is already known. It does not explicitly name alternatives, but sibling context and the identifier-based lookup make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. The description adds specific behavioral details by stating it checks OAI Identify without authentication and whether a REST API key exists. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct line in Korean, immediately conveying the tool's purpose without any extraneous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description covers the core purpose and scope adequately. It could optionally mention the return format, but for a simple status check, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter behavior since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a connection check, specifying both OAI Identify (no authentication) and REST API key possession status. This distinguishes it from sibling tools like kci_search and kci_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is a connectivity/status check, implying it should be used to verify API access before other operations. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![KCI_openAPI MCP server](https://glama.ai/mcp/servers/rubatoyd/KCI_openAPI/badges/card.svg)](https://glama.ai/mcp/servers/rubatoyd/KCI_openAPI)

Score Badge

Copy to your README.md:

[![KCI_openAPI MCP server](https://glama.ai/mcp/servers/rubatoyd/KCI_openAPI/badges/score.svg)](https://glama.ai/mcp/servers/rubatoyd/KCI_openAPI)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rubatoyd/KCI_openAPI'

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