ScienceON-MCP

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation4/5
Most tools follow a clear search/detail pairing per entity type, making purposes distinct. The only slight ambiguity is between scienceon_news_trends and scienceon_weekly_news, but descriptions clarify one is a searchable archive and the other is a curated weekly digest.
Naming Consistency5/5
All tools share the scienceon_ prefix and use snake_case. Search tools are named by entity (e.g., scienceon_papers), detail tools append _details, and special tools like scienceon_patent_citations and scienceon_weekly_news are descriptive without breaking the convention.
Tool Count4/5
At 17 tools, this exceeds the typical 3-15 range, but the broad scope (papers, patents, reports, researchers, organizations, etc.) justifies the number. Each tool has a clear role, so the count feels reasonable rather than bloated.
Completeness4/5
The server covers search and detail for most major content types, plus patent citations and weekly news. Minor gaps exist: tech trends lack a detail tool, weekly news has no separate detail view, and paper citations are not offered. These are workable but not fully complete.
Average 3.8/5 across 17 of 17 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on June 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Creative Commons Attribution Non Commercial 4.0 International.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations declaring readOnlyHint=true, the description adds no behavioral context beyond that (e.g., no mention of pagination, result size limits, or that include_body toggles abstract inclusion). The one-line description merely restates the function, and the schema already communicates most parameter behavior, leaving no added transparency value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no redundancy, which is structurally concise. However, it is so minimal that it borders on under-specification rather than effective conciseness. It could include a bit more context (e.g., search scope or output type) while still remaining brief.
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 the tool has 4 parameters, an output schema, and multiple sibling tools, the one-line description is incomplete. It does not explain what fields are searched, whether the result is a list, or how it relates to other paper tools. The presence of an output schema reduces the need to describe return values, but the description still lacks essential context for an agent to select this tool confidently.
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 100% (all parameters have descriptions), so the baseline is 3. The tool description does not add any additional parameter meaning; it relies on the schema for details like page, max_results, and include_body. This meets the baseline but does not exceed it.
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 searches for papers in KISTI ScienceON ('KISTI ScienceON에서 논문을 검색합니다'). This is a specific verb+resource combination that communicates the primary function, and it is naturally distinguishable from sibling tools like 'scienceon_paper_details' by the search vs. details distinction.
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 about when to use this tool versus alternatives. It does not mention that it is for keyword-based search, that details of a specific paper should use scienceon_paper_details, or any exclusions or prerequisites. The user must infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only annotation already signals a safe operation, but the description adds no additional behavioral context such as pagination behavior, authentication requirements, or result limitations. It does not disclose anything beyond the literal search action, leaving the agent without deeper expectations.
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, direct sentence with no extraneous content. It is appropriately sized for a simple search tool, and every word serves a purpose.
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 existence of an output schema and complete parameter schema makes the tool minimally invocable, but the description lacks context about the search scope or relationship to sibling detail tools. It is adequate but leaves gaps in the overall picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions for query, page, and max_results. The description does not add value beyond the schema, so the baseline of 3 is appropriate.
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 action (검색합니다, 'searches') and resource (연구자, 'researchers') within the KISTI ScienceON context. This distinguishes it from sibling tools focused on papers, patents, reports, and details, as it explicitly targets researcher search.
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 such as scienceon_researcher_details. The description lacks any context about use cases, prerequisites, or exclusions, offering no decision support beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation but adds no behavioral context beyond it, such as pagination behavior or response format. It simply restates the search intent without disclosing additional traits.
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, front-loaded sentence that directly states the tool's function without extraneous words, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the comprehensive input schema, an output schema, and the readOnlyHint annotation, the description provides sufficient context for a simple search operation. However, it lacks a note about the scope of R&D reports or how results are structured, though the output schema presumably covers the latter.
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?
All 4 parameters are fully described in the schema (100% coverage), so the description adds no parameter-specific meaning beyond what the schema provides. It does not mention any parameters at all, hence baseline 3.
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 the specific verb '검색합니다' (search) and identifies the resource as 'R&D 보고서' (R&D reports) from KISTI ScienceON, clearly distinguishing it from sibling tools like scienceon_papers or scienceon_patents.
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 gives no guidance on when to use this tool instead of the many sibling search tools; it only states the search action without mentioning alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating safe read-only operation. Description adds that news is curated with high reliability ('신뢰성 높은') and grouped by week, but does not disclose response format or pagination. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the main verb '조회합니다'. Compact and to the point, though it could mention usage alternatives for clarity.
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?
With an output schema and full parameter coverage, the description is minimally adequate. It lacks details on result structure or edge cases, but the tool is straightforward. Sibling context suggests broader scienceon family, but no need for deep context.
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 coverage is 100%, so the schema already documents all parameters well. Description adds that the date selects the week containing that date, which is helpful context, but otherwise does not need to compensate.
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 retrieves weekly science/technology news ('금주의 과학기술뉴스를 조회합니다'). It distinguishes from siblings by focusing on weekly news, unlike paper/patent/report tools, but does not explicitly contrast with news_trend tools.
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 fetching weekly news but does not explicitly state when to use this vs alternatives like scienceon_news_trends. It provides context about '주차별' but no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the tool is safe to invoke. The description adds that it returns definitions and related content, which is useful context, but does not disclose other behavioral aspects like pagination behavior or rate limits. This is acceptable given the annotation coverage, but no extra value beyond what annotations and schema already provide.
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 concise, consisting of two sentences plus an example, and front-loads the primary verb and resource. There is minor redundancy between the first and second sentences, but overall it is efficiently written without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and high schema parameter coverage, the description is sufficiently complete for a search tool. It clarifies the tool's focus on technology trends and examples, though it could be slightly more explicit about the result format, which the output schema likely covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with descriptions (100% coverage), so the baseline is 3. The description adds slight context by mentioning definitions and related content, which aligns with the include_body parameter, but it does not materially improve parameter understanding beyond the schema.
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 searches technology trend topics in KISTI ScienceON, using specific verbs ('검색합니다') and resource ('기술트렌드 토픽'). It distinguishes itself from sibling tools by focusing on technology keywords/topics and trend analysis, with concrete examples like '디지털 트윈' and '메타버스'.
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 context for technology trend searches and provides examples, but it does not give explicit when-to-use/when-not-to-use guidance or reference alternative sibling tools. The context is clear enough for basic use, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety; the description adds the scope of content (domestic/international science news collections) but does not disclose additional behaviors such as result sorting, pagination limits, or handling of the include_body flag. It is consistent with annotations, adding some but limited context.
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?
Two concise sentences, with the main action first and supplementary scope second. Every word contributes to understanding, and there is no 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?
With a read-only annotation, full schema coverage, and an output schema present, the description covers the essential purpose and domain. It could briefly mention how it relates to detail views or alternative trend tools, but for a straightforward search interface, it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes all four parameters with individual descriptions, so the baseline is 3. The description adds no parameter-specific semantics beyond broader content context, so it does not improve upon the schema.
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 it searches science and technology trend articles from KISTI ScienceON, using the specific verb 'searches' and naming the resource. It distinguishes itself from sibling tools that handle patents, papers, reports, etc., by focusing on news/trends.
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 searching news/trend articles but does not explicitly compare with related siblings like scienceon_weekly_news or scienceon_tech_trends. There is no exclusion guidance, making it minimally contextual.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals this is a safe read operation. The description adds the behavioral constraint that Korean names are recommended for search, which is useful but does not disclose other traits such as pagination limits or result format beyond what annotations and schema already cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the purpose, the second gives a clear, actionable tip. Every word earns its place, and the front-loaded structure immediately clarifies what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only annotation, the explicit output schema, and the schema descriptions for parameters, this description is sufficiently complete for a search tool. It adds contextual value with the Korean-name tip and example, but it does not elaborate on result handling or edge cases, though the output schema compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all three parameters (query, page, max_results). The description reinforces the query parameter with an example ('한국과학기술정보연구원') but does not add substantial new meaning beyond the schema's own descriptions.
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's function: searching for research institutions in KISTI ScienceON. The verb '검색합니다' (search) and resource '연구기관' (research institutions) are specific, and it distinguishes itself from sibling tools focused on papers, patents, or other entities.
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 provides a practical usage tip (search using Korean institution names) with an example, but it does not explicitly state when to use this tool versus alternatives like scienceon_organization_details or other search tools. The usage context is implied rather than explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: true, so the safety profile is already disclosed. The description adds no extra behavioral context beyond the read-only nature, such as return volume or side effects. It does not contradict the annotation, but it also does not enrich it.
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, front-loaded Korean sentence that directly states the action and target. No unnecessary words, and it earns its place.
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 detail-fetch tool with an output schema and read-only annotation, the description is mostly adequate. It could have explicitly mentioned that it is intended for use with results from scienceon_papers, but the schema's cn reference and sibling list make this inferable. Minor gap only.
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 100%, so the parameter descriptions fully explain cn and include_body. The main description adds no additional meaning to the parameters; it relies completely on the schema. Baseline 3 is appropriate.
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 retrieves detailed paper information using a unique CN number, which is a specific verb+resource+identifier. It distinguishes itself from sibling tools like scienceon_papers (search) and other detail tools (patents, reports) by specifying 'paper details' and the CN identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly say when to use this tool versus alternatives, nor does it name sibling tools. However, the cn parameter description ('CN value from paper search results') implies it is used after a search, providing weak context. There is no explicit exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint: true, so the read-only nature is covered. The description adds that it returns citation/cited-by info, which is helpful, but does not disclose any further behavioral traits such as result format, pagination, or limitations. With annotations present, the description is adequate but not exemplary.
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, clear sentence with no wasted words. The key information (what, how, by what identifier) is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the return structure is documented elsewhere. The description covers the core purpose and both citing and cited aspects (인용/피인용). It does not mention any prerequisites or edge cases, but for a simple single-parameter read tool, this is largely complete. Slight deduction for not noting that the CN must come from a prior patent search, though that is in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'cn', with the schema already explaining it's a unique patent identifier from patent search results. The main description just repeats 'CN번호로', adding no new semantic information beyond the schema. Baseline 3 is appropriate.
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 a specific action (조회합니다/retrieve) and resource (특허 인용/피인용 정보/patent citation/cited-by information) with the method (CN번호로/by CN number). It differentiates from siblings like scienceon_patents and scienceon_patent_details by focusing specifically on citation data.
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 the tool is used when you have a CN number and need citation/cited-by information, but it does not explicitly contrast with alternatives or state when not to use it. The purpose itself gives context, but no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only nature, so the description does not need to repeat that. The description adds that it returns both details and body text, but this is also reflected in the include_body parameter. No additional behavioral context about errors, pagination, or response size is provided, which is acceptable given the annotation coverage.
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, well-structured sentence that front-loads the primary action and target. It contains no redundant words and earns its place by stating exactly what the tool does and how.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the presence of an output schema, and comprehensive parameter descriptions, the description is complete enough for an agent to know when and how to invoke it. It includes the key identifier (CN) and differentiates the tool from search functionalities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed descriptions for both 'cn' and 'include_body'. The description merely restates the role of CN, adding no extra meaning beyond what the schema already conveys.
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 a specific verb '조회' (retrieve) with a clear resource '과학향기 칼럼 상세정보 및 본문' (Science Scent column details and body) and a unique identifier 'CN번호'. This clearly differentiates it from sibling search tools like scienceon_scents by indicating it is a detail lookup based on a known CN.
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 after obtaining a CN number from a search result ('CN번호로') but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. There is no explicit reference to sibling tools like scienceon_scents or search-first workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so the read‑only nature is already disclosed. The description adds no further behavioral context such as response format or side effects, but it does not contradict the annotation. No additional hidden behaviors are revealed, keeping the score at a baseline 3.
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, front-loaded sentence with no redundant wording. Every word conveys necessary meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and the clear parameter definitions, the description is sufficient for invocation. The only slight gap is not explicitly linking to the sibling search tool, but the name and schema make the relationship apparent.
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 100% for both parameters (cn and include_body), so the schema already documents their meaning. The description only repeats the CN concept and adds no extra parameter semantics, thus the baseline 3 applies.
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's function: 'CN번호로 과학기술 동향 기사 상세정보를 조회합니다' (retrieves detailed info of science/technology trend articles by CN number). The verb '조회' and the resource '상세정보' distinguish it from sibling list tools like 'scienceon_news_trends', making the purpose unambiguous.
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 indicates usage by CN number, implying it is for looking up details after a search. The schema further clarifies that the CN comes from trend search results, but the description itself does not explicitly name alternatives or when not to use the tool. This is clear context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already communicates the read-only nature, so the description doesn't need to repeat that. The description adds minimal behavioral context beyond stating what it retrieves, and it does not disclose additional traits like response size or data source. Since the annotation covers safety, the bar is lower, and the description adds no significant extra behavioral information.
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 extremely concise, consisting of two sentences that each earn their place. The first sentence states the core function, and the second provides a clear pointer to an alternative tool. There is no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema present), the description is adequately complete. It clarifies the key use case and provides a crucial alternative reference for citations. It does not explain what '상세정보' includes, but the output schema presumably covers that. A slightly richer description could mention the source or what types of details are returned, but it's sufficient for this complexity.
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 100%, with both cn and include_body well-documented in the input schema. The description's mention of CN번호 aligns with the cn parameter but adds no meaning beyond the schema. The include_body parameter is not addressed in the description at all, so it relies entirely on the schema. This meets the baseline for full 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 clearly states 'CN번호로 특허 상세정보를 조회합니다' (retrieves patent detailed information by CN number), specifying the exact resource and identifier. It also distinguishes itself from the sibling tool scienceon_patent_citations by explicitly stating that citation information is handled separately.
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: use this tool for patent details by CN number. It explicitly directs users to the alternative tool `scienceon_patent_citations` for cited/citing patents, giving a concrete exclusion. However, it does not mention other related tools like scienceon_patents for searching, though the scope is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description consistently describes a read operation. The description adds no further behavioral context beyond the basic function, such as response nature or impact of include_body, which is already covered by the schema. With annotations handling the safety profile, this meets a minimum standard.
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, concise sentence in Korean that directly states the tool's purpose without any filler or repetition. It is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only detail retriever with full parameter schema coverage and an output schema present. The description is sufficient for an agent to select and invoke it, though explicit mention of the prerequisite report search would enhance completeness.
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 100%, with both cn and include_body fully described. The description only mentions CN번호 and adds no additional meaning beyond what the schema already provides, so it does not need to compensate.
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 a specific verb '조회' (query/retrieve) and identifies the resource 'R&D 보고서 상세정보' (R&D report detailed info) keyed by CN number. This clearly distinguishes it from sibling tools like scienceon_reports, which likely performs list searches.
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 states the tool operates by 'CN번호' (CN number), and the schema for cn adds that it comes from report search results, implying usage after scienceon_reports. However, it does not explicitly name alternatives or state when not to use this tool, providing clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already informs the agent this is a read-only operation. The description adds no additional behavioral context (e.g., return format, limitations, side effects), so it meets the baseline without exceeding it.
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, concise sentence that immediately communicates the tool's purpose and primary parameter. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one well-documented parameter, an output schema present, and annotations indicating read-only behavior, the description is sufficient for an agent to select and invoke the tool correctly. The description covers the purpose, and the structured data covers the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'cn' parameter with a description of its meaning and origin from search results. The description merely states 'by CN number,' which adds no new information beyond the schema, so the score is at the baseline for high 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 clearly states the tool's function: retrieving detailed research institution information by CN number. It uses a specific verb ('조회합니다') and resource ('연구기관 상세정보'), and the 'CN번호로' qualifier distinguishes it from list-style sibling tools like scienceon_organizations.
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 implies the prerequisite of having a CN number to use this tool, providing clear context for when it is appropriate. However, it does not explicitly mention alternatives like scienceon_organizations for list queries, so it has no exclusions or direct sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says '조회' (query), which is consistent with readOnlyHint=true, and adds that it returns '상세정보' (detailed information). It does not disclose other behavioral aspects such as error conditions or response format, but the output schema covers return values.
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 front-loaded sentence that directly states the operation and key identifier, containing no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple lookup nature, a fully described required parameter, readOnlyHint annotation, and an available output schema, the one-line description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, describing cn as the researcher's unique identifier from search results. The tool description only repeats 'CN번호로' without adding further semantic detail, so the baseline of 3 is appropriate.
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 the specific verb '조회' (retrieve) with the resource '연구자 상세정보' and the method 'CN번호로', clearly defining a detail-lookup operation. It distinguishes itself from the sibling 'scienceon_researchers' search tool by requiring an existing CN identifier.
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 parameter schema states cn comes from '연구자 검색 결과의 CN 값' (CN value from researcher search results), implying this tool is used after a search to get full details. It does not explicitly name alternatives, but the intended post-search workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the `readOnlyHint: true` annotation, indicating a safe read operation. However, it adds no additional behavioral context beyond the search action itself, such as pagination behavior or result scope, but given the annotation coverage, this minimal addition is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences. The first sentence states the primary purpose, and the second provides a useful pointer to a sibling tool. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (4 parameters with full descriptions), annotations, and presence of an output schema, the description is sufficient. It covers the core purpose and the main alternative (citations). It could mention result details or whether it returns bibliographic info, but the output schema likely handles that, so no major gap.
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 100%, with all parameters (query, page, max_results, include_body) already documented in the schema. The tool description adds no extra parameter semantics, so the baseline score of 3 applies.
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 searches patents on KISTI ScienceON, using the specific verb '검색' (search) and resource '특허' (patents). It also distinguishes itself from the sibling `scienceon_patent_citations` by noting that citation data is handled separately, preventing confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells users to use `scienceon_patent_citations` for cited/citing patents, providing a clear alternative and exclusion. This helps the agent decide when not to use this tool without additional inference.
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?
The annotation readOnlyHint=true already signals a safe read-only operation. The description adds the key behavioral constraint that the API only supports searching by year, and also states the date range and subject scope. This goes beyond the annotation and helps the agent understand the tool's limitations.
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 three concise sentences, each serving a distinct purpose: state the action, give background scope, and note the key limitation. It is front-loaded with the main purpose and contains no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and fully described parameters, the description covers the essential behavioral constraints and scope. The year-only search limitation is critical for correct invocation, and the tool's read-only nature is already annotated. The description is complete for an agent to select and call this tool appropriately.
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?
All four parameters have descriptions in the input schema (100% coverage), so the schema already documents their meaning. The description's note about year-only search reinforces the 'year' parameter's importance, but it doesn't add significant new information beyond the schema.
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 the specific verb '검색' (search) and identifies the resource as '과학향기 칼럼' (Science Scent columns), clearly distinguishing it from sibling detail tools like scienceon_scent_details. It also states the coverage (2003 to present, all science/tech fields), making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool searches Science Scent columns and is only searchable by publication year ('발행연도(year)로만 검색 가능'). This implies when to use it, but it does not explicitly name alternatives or exclusion criteria, such as 'use scienceon_scent_details for detailed column content.'
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:

[![scienceon-mcp MCP server](https://glama.ai/mcp/servers/ansua79/scienceon-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ansua79/scienceon-mcp)

Score Badge

Copy to your README.md:

[![scienceon-mcp MCP server](https://glama.ai/mcp/servers/ansua79/scienceon-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ansua79/scienceon-mcp)

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/ansua79/scienceon-mcp'

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