Skip to main content
Glama
enesjakozh
zongmin-yu

Semantic Scholar MCP Server

by zongmin-yu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Semantic Scholar MCP 서버

대장간 배지

Semantic Scholar API를 위한 FastMCP 서버 구현으로, 학술 논문 데이터, 저자 정보 및 인용 네트워크에 대한 포괄적인 액세스를 제공합니다.

프로젝트 구조

이 프로젝트는 더 나은 유지 관리를 위해 모듈형 구조로 리팩토링되었습니다.

지엑스피1

이 구조는:

  • 문제를 논리적 모듈로 분리합니다.

  • 코드베이스를 더 쉽게 이해하고 유지 관리할 수 있습니다.

  • 더 나은 테스트와 향후 확장이 가능합니다.

  • 관련 기능을 함께 그룹화합니다.

  • 순환 가져오기를 방지하기 위해 FastMCP 인스턴스를 중앙화합니다.

Related MCP server: AI Research Assistant - Semantic Scholar

특징

  • 논문 검색 및 발견

    • 고급 필터링을 통한 전체 텍스트 검색

    • 제목 기반 논문 매칭

    • 논문 추천 (단일 및 다중 논문)

    • 배치 용지 세부 정보 검색

    • 순위 전략을 활용한 고급 검색

  • 인용 분석

    • 인용 네트워크 탐색

    • 참조 추적

    • 인용 맥락 및 영향 분석

  • 저자 정보

    • 작성자 검색 및 프로필 세부 정보

    • 출판 내역

    • 일괄 작성자 세부 정보 검색

  • 고급 기능

    • 다양한 순위 전략을 사용한 복잡한 검색

    • 사용자 정의 가능한 필드 선택

    • 효율적인 배치 작업

    • 속도 제한 준수

    • 인증된 액세스와 인증되지 않은 액세스 모두 지원

    • 우아한 종료 및 오류 처리

    • 연결 풀링 및 리소스 관리

시스템 요구 사항

  • 파이썬 3.8 이상

  • FastMCP 프레임워크

  • API 키에 대한 환경 변수(선택 사항)

설치

Smithery를 통해 설치

Smithery를 통해 Claude Desktop에 Semantic Scholar MCP Server를 자동으로 설치하려면:

npx -y @smithery/cli install semantic-scholar-fastmcp-mcp-server --client claude

수동 설치

  1. 저장소를 복제합니다.

git clone https://github.com/YUZongmin/semantic-scholar-fastmcp-mcp-server.git
cd semantic-scholar-server

  1. FastMCP 및 기타 종속성을 다음에서 설치하세요: https://github.com/jlowin/fastmcp

  2. FastMCP 구성:

Claude Desktop 사용자의 경우 FastMCP 구성 파일에서 서버를 구성해야 합니다. 구성 파일(일반적으로 ~/.config/claude-desktop/config.json )에 다음을 추가합니다.

{
  "mcps": {
    "Semantic Scholar Server": {
      "command": "/path/to/your/venv/bin/fastmcp",
      "args": [
        "run",
        "/path/to/your/semantic-scholar-server/run.py"
      ],
      "env": {
        "SEMANTIC_SCHOLAR_API_KEY": "your-api-key-here"  # Optional
      }
    }
  }
}

다음 사항을 확인하세요.

  • /path/to/your/venv/bin/fastmcp FastMCP 설치의 실제 경로로 바꾸세요.

  • /path/to/your/semantic-scholar-server/run.py 컴퓨터의 run.py에 대한 실제 경로로 바꾸세요.

  • Semantic Scholar API 키가 있으면 env 섹션에 추가하세요. 없으면 env 섹션을 완전히 삭제할 수 있습니다.

  1. 서버 사용을 시작하세요:

이제 Claude Desktop 인스턴스에서 서버를 사용할 수 있습니다. 명령을 수동으로 실행할 필요가 없습니다. Claude가 필요 시 서버 프로세스를 자동으로 시작하고 관리합니다.

API 키(선택 사항)

더 높은 요금 한도와 더 나은 성능을 얻으려면:

  1. Semantic Scholar API 에서 API 키 받기

  2. 위에 표시된 대로 env 섹션에 FastMCP 구성에 추가하세요.

API 키가 제공되지 않으면 서버는 낮은 속도 제한이 있는 인증되지 않은 액세스를 사용합니다.

구성

환경 변수

  • SEMANTIC_SCHOLAR_API_KEY : Semantic Scholar API 키(선택 사항)

    • Semantic Scholar API 에서 키를 받으세요

    • 제공되지 않으면 서버는 인증되지 않은 액세스를 사용합니다.

요금 제한

서버는 자동으로 적절한 속도 제한에 맞춰 조정됩니다.

API 키 사용 :

  • 검색, 일괄 처리 및 추천 엔드포인트: 초당 1개 요청

  • 기타 엔드포인트: 초당 10개 요청

API 키 없이 :

  • 모든 엔드포인트: 5분당 100개 요청

  • 요청에 대한 더 긴 시간 제한

사용 가능한 MCP 도구

참고: 모든 도구는 공식 Semantic Scholar API 문서를 따릅니다. 자세한 필드 사양 및 최신 업데이트 내용은 공식 문서를 참조하세요.

논문 검색 도구

  • paper_relevance_search : 관련성 순위를 사용하여 논문 검색

    • 연도 범위 및 인용 횟수 필터를 포함한 포괄적인 쿼리 매개변수를 지원합니다.

    • 사용자 정의 가능한 필드로 페이지가 매겨진 결과를 반환합니다.

  • paper_bulk_search : 정렬 옵션을 사용한 대량 논문 검색

    • 관련성 검색과 유사하지만 더 큰 결과 집합에 최적화됨

    • 인용 횟수, 출판 날짜 등을 기준으로 정렬을 지원합니다.

  • paper_title_search : 정확한 제목 일치로 논문 찾기

    • 제목을 알고 있을 때 특정 논문을 찾는 데 유용합니다.

    • 사용자 정의 가능한 필드로 자세한 논문 정보를 반환합니다.

  • paper_details : 특정 논문에 대한 포괄적인 세부 정보를 얻으세요

    • 다양한 논문 ID 형식(S2 ID, DOI, ArXiv 등)을 허용합니다.

    • 중첩된 필드 지원을 통해 자세한 논문 메타데이터를 반환합니다.

  • paper_batch_details : 여러 논문의 세부 정보를 효율적으로 검색합니다.

    • 요청당 최대 1000개의 종이 ID를 허용합니다.

    • 단일 문서 세부 정보와 동일한 ID 형식 및 필드를 지원합니다.

인용 도구

  • paper_citations : 특정 논문을 인용한 논문을 가져옵니다.

    • 인용된 논문의 페이지별 목록을 반환합니다.

    • 사용 가능한 경우 인용 컨텍스트를 포함합니다.

    • 필드 사용자 정의 및 정렬 지원

  • paper_references : 특정 논문에서 참조된 논문을 가져옵니다.

    • 참조된 논문의 페이지별 목록을 반환합니다.

    • 가능한 경우 참조 컨텍스트를 포함합니다.

    • 필드 사용자 정의 및 정렬 지원

작성자 도구

  • author_search : 이름으로 저자 검색

    • 사용자 정의 가능한 필드로 페이지가 매겨진 결과를 반환합니다.

    • 소속 및 출판 횟수 포함

  • author_details : 작성자에 대한 자세한 정보를 가져옵니다.

    • 포괄적인 작성자 메타데이터를 반환합니다.

    • h-index 및 인용 횟수와 같은 측정 항목이 포함됩니다.

  • author_papers : 저자가 작성한 논문을 가져옵니다

    • 저자의 출판물의 페이지별 목록을 반환합니다.

    • 필드 사용자 정의 및 정렬 지원

  • author_batch_details : 여러 작성자에 대한 세부 정보를 가져옵니다.

    • 최대 1000명의 저자에 대한 정보를 효율적으로 검색합니다.

    • 단일 작성자 세부 정보와 동일한 필드를 반환합니다.

추천 도구

  • paper_recommendations_single : 단일 논문을 기반으로 추천을 받습니다.

    • 콘텐츠 및 인용 패턴을 기반으로 유사한 논문을 반환합니다.

    • 추천 논문에 대한 필드 맞춤화 지원

  • paper_recommendations_multi : 여러 논문을 기반으로 추천을 받으세요

    • 긍정적, 부정적 예시 논문을 허용합니다.

    • 긍정적 사례와 유사한 논문과 부정적 사례와 다른 논문을 반환합니다.

사용 예

기본 논문 검색

results = await paper_relevance_search(
    context,
    query="machine learning",
    year="2020-2024",
    min_citation_count=50,
    fields=["title", "abstract", "authors"]
)

논문 추천

# Single paper recommendation
recommendations = await paper_recommendations_single(
    context,
    paper_id="649def34f8be52c8b66281af98ae884c09aef38b",
    fields="title,authors,year"
)

# Multi-paper recommendation
recommendations = await paper_recommendations_multi(
    context,
    positive_paper_ids=["649def34f8be52c8b66281af98ae884c09aef38b", "ARXIV:2106.15928"],
    negative_paper_ids=["ArXiv:1805.02262"],
    fields="title,abstract,authors"
)

배치 작업

# Get details for multiple papers
papers = await paper_batch_details(
    context,
    paper_ids=["649def34f8be52c8b66281af98ae884c09aef38b", "ARXIV:2106.15928"],
    fields="title,authors,year,citations"
)

# Get details for multiple authors
authors = await author_batch_details(
    context,
    author_ids=["1741101", "1780531"],
    fields="name,hIndex,citationCount,paperCount"
)

오류 처리

서버는 표준화된 오류 응답을 제공합니다.

{
    "error": {
        "type": "error_type",  # rate_limit, api_error, validation, timeout
        "message": "Error description",
        "details": {
            # Additional context
            "authenticated": true/false  # Indicates if request was authenticated
        }
    }
}

Available Tools

16 tools
author_batch_detailsD
ParametersJSON Schema
NameRequiredDescriptionDefault
author_idsYes
fieldsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

author_detailsD
ParametersJSON Schema
NameRequiredDescriptionDefault
author_idYes
fieldsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

author_papersD
ParametersJSON Schema
NameRequiredDescriptionDefault
author_idYes
fieldsNo
offsetNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_paper_recommendations_multiD
ParametersJSON Schema
NameRequiredDescriptionDefault
positive_paper_idsYes
negative_paper_idsNo
fieldsNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_paper_recommendations_singleD
ParametersJSON Schema
NameRequiredDescriptionDefault
paper_idYes
fieldsNo
limitNo
from_poolNorecent

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

paper_authorsD
ParametersJSON Schema
NameRequiredDescriptionDefault
paper_idYes
fieldsNo
offsetNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

paper_autocompleteD
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

paper_batch_detailsD
ParametersJSON Schema
NameRequiredDescriptionDefault
paper_idsYes
fieldsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

paper_citationsD
ParametersJSON Schema
NameRequiredDescriptionDefault
paper_idYes
fieldsNo
offsetNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

paper_detailsD
ParametersJSON Schema
NameRequiredDescriptionDefault
paper_idYes
fieldsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

paper_referencesD
ParametersJSON Schema
NameRequiredDescriptionDefault
paper_idYes
fieldsNo
offsetNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 16 tool updatesv0.1.0
    • First observedauthor_batch_details
    • First observedauthor_details
    • First observedauthor_papers
    • First observedauthor_search
    • First observedget_paper_recommendations_multi
    • First observedget_paper_recommendations_single
    • First observedpaper_authors
    • First observedpaper_autocomplete
    • First observedpaper_batch_details
    • First observedpaper_bulk_search
    • First observedpaper_citations
    • First observedpaper_details
    • First observedpaper_references
    • First observedpaper_relevance_search
    • First observedpaper_title_search
    • First observedsnippet_search
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2/5.0

Scored across 16 tools

Disambiguation4/5

Most tools have clearly distinct purposes targeting different aspects of the Semantic Scholar domain (authors vs. papers, details vs. search vs. recommendations). However, some potential overlap exists between paper_bulk_search, paper_relevance_search, and paper_title_search which could cause confusion about which search tool to use for specific queries.

Naming Consistency5/5

Excellent naming consistency with a clear pattern throughout. All tools follow a consistent [resource]_[action] structure (e.g., author_search, paper_details, paper_citations), with multi-word actions using underscores consistently (e.g., get_paper_recommendations_multi). No mixing of conventions or inconsistent verb styles.

Tool Count4/5

16 tools is reasonable for a comprehensive academic paper search and analysis server, though slightly on the higher side. The count feels appropriate for covering multiple aspects of the Semantic Scholar API (authors, papers, searches, recommendations, citations/references), though some consolidation might be possible.

Completeness4/5

The tool set provides excellent coverage of the Semantic Scholar domain with operations for both authors and papers, including search, details, recommendations, and citation analysis. Minor gaps might exist in update/delete operations (though likely not applicable to this read-only academic database) and potentially in filtering/sorting capabilities for search results.

Maintenance

ActivityInactive
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches