Skip to main content
Glama
enesjakozh
zongmin-yu

Semantic Scholar MCP Server

by zongmin-yu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Semantic Scholar MCP Server

A FastMCP server implementation for the Semantic Scholar API, providing comprehensive access to academic paper data, author information, and citation networks.

Looking for Claude Code skills? Check out semantic-scholar-skills — the next-generation toolkit that bundles this MCP server with ready-to-use Claude Code skills (/expand-references, /trace-citations, /paper-triage) and a Python workflow engine.

Project Structure

The project has been refactored into a modular structure for better maintainability:

semantic-scholar-server/
├── semantic_scholar/            # Main package
│   ├── __init__.py             # Package initialization
│   ├── server.py               # Server setup and main functionality
│   ├── mcp.py                  # Centralized FastMCP instance definition
│   ├── config.py               # Configuration classes
│   ├── utils/                  # Utility modules
│   │   ├── __init__.py
│   │   ├── errors.py           # Error handling
│   │   └── http.py             # HTTP client and rate limiting
│   ├── api/                    # API endpoints
│       ├── __init__.py
│       ├── papers.py           # Paper-related endpoints
│       ├── authors.py          # Author-related endpoints
│       └── recommendations.py  # Recommendation endpoints
├── run.py                      # Entry point script

This structure:

  • Separates concerns into logical modules

  • Makes the codebase easier to understand and maintain

  • Allows for better testing and future extensions

  • Keeps related functionality grouped together

  • Centralizes the FastMCP instance to avoid circular imports

Related MCP server: AI Research Assistant - Semantic Scholar

Features

  • Paper Search & Discovery

    • Full-text search with advanced filtering

    • Title-based paper matching

    • Paper recommendations (single and multi-paper)

    • Batch paper details retrieval

    • Advanced search with ranking strategies

  • Citation Analysis

    • Citation network exploration

    • Reference tracking

    • Citation context and influence analysis

  • Author Information

    • Author search and profile details

    • Publication history

    • Batch author details retrieval

  • Advanced Features

    • Complex search with multiple ranking strategies

    • Customizable field selection

    • Efficient batch operations

    • Rate limiting compliance

    • Support for both authenticated and unauthenticated access

    • Graceful shutdown and error handling

    • Connection pooling and resource management

System Requirements

  • Python 3.10+

  • Environment variable for API key (optional)

Installation

Quick Install (PyPI)

pip install semantic-scholar-fastmcp

Or run directly with uvx:

uvx semantic-scholar-fastmcp

MCP Client Configuration

For any MCP client that supports uvx:

{
  "mcpServers": {
    "semantic-scholar": {
      "command": "uvx",
      "args": ["semantic-scholar-fastmcp"],
      "env": {
        "SEMANTIC_SCHOLAR_API_KEY": "your-api-key-here"
      }
    }
  }
}

Installing via Smithery

To install Semantic Scholar MCP Server for Claude Desktop automatically via Smithery:

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

Manual Installation

  1. Clone the repository:

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

  1. Install in development mode:

pip install -e ".[dev]"

  1. Run the server:

semantic-scholar-mcp-server

API Key (Optional)

To get higher rate limits and better performance:

  1. Get an API key from Semantic Scholar API

  2. Add it to your FastMCP configuration as shown above in the env section

If no API key is provided, the server will use unauthenticated access with lower rate limits.

Configuration

Contributing

See CONTRIBUTING.md.

Environment Variables

  • SEMANTIC_SCHOLAR_API_KEY: Your Semantic Scholar API key (optional)

HTTP Bridge (Built-in)

This repository includes a small HTTP bridge (semantic_scholar.bridge) that exposes a minimal REST API for common workflows.

Default listening port: 8000.

Bridge configuration via environment variables:

  • SEMANTIC_SCHOLAR_ENABLE_HTTP_BRIDGE (default: 1) — set to 0 to disable

  • SEMANTIC_SCHOLAR_HTTP_BRIDGE_HOST (default: 0.0.0.0)

  • SEMANTIC_SCHOLAR_HTTP_BRIDGE_PORT (default: 8000)

Available endpoints:

  • GET /v1/paper/search?q=... — paper search (params: fields, offset, limit)

  • GET /v1/paper/{paper_id} — paper details (param: fields)

  • POST /v1/paper/batch — batch paper details (JSON: { "ids": [ ... ] })

  • GET /v1/author/search?q=... — author search (params: fields, offset, limit)

  • GET /v1/author/{author_id} — author details (param: fields)

  • POST /v1/author/batch — batch author details (JSON: { "ids": [ ... ] })

  • GET /v1/recommendations?paper_id=... — recommendations for a paper

The bridge reuses the package's HTTP utilities (semantic_scholar.utils.http) so rate limits, API key handling and connection pooling remain consistent with the MCP tools.

Example:

curl 'http://localhost:8000/v1/paper/search?q=machine+learning&limit=5'

Rate Limits

The server automatically adjusts to the appropriate rate limits:

With API Key:

  • Search, batch and recommendation endpoints: 1 request per second

  • Other endpoints: 10 requests per second

Without API Key:

  • All endpoints: 100 requests per 5 minutes

  • Longer timeouts for requests

Note: Rate limits are subject to change. See Semantic Scholar API for the latest information.

Semantic Scholar API Terms

This project uses the Semantic Scholar Academic Graph API, provided by the Allen Institute for AI (AI2). Please review the API License Agreement before use.

Available MCP Tools

The server currently exposes 16 MCP tools.

Note: All tools are aligned with the official Semantic Scholar API documentation. Please refer to the official documentation for detailed field specifications and the latest updates.

Paper Search Tools

  • paper_relevance_search: Search for papers using relevance ranking

    • Supports comprehensive query parameters including year range and citation count filters

    • Returns paginated results with customizable fields

  • paper_bulk_search: Bulk paper search with sorting options

    • Similar to relevance search but optimized for larger result sets

    • Supports sorting by citation count, publication date, etc.

  • paper_title_search: Find papers by exact title match

    • Useful for finding specific papers when you know the title

    • Returns detailed paper information with customizable fields

  • paper_details: Get comprehensive details about a specific paper

    • Accepts various paper ID formats (S2 ID, DOI, ArXiv, etc.)

    • Returns detailed paper metadata with nested field support

  • paper_batch_details: Efficiently retrieve details for multiple papers

    • Accepts up to 1000 paper IDs per request

    • Supports the same ID formats and fields as single paper details

  • paper_authors: Get the authors associated with a specific paper

    • Returns paginated author results for the paper

    • Supports author field customization with offset and limit controls

  • paper_autocomplete: Get paper title suggestions for a partial query

    • Returns minimal paper metadata for interactive search completion

    • Truncates overly long queries to the API-supported length

  • snippet_search: Search within paper snippets and excerpts

    • Returns relevant text matches from titles, abstracts, and body text

    • Supports filters for paper IDs, authors, venue, year, and field of study

Citation Tools

  • paper_citations: Get papers that cite a specific paper

    • Returns paginated list of citing papers

    • Includes citation context when available

    • Supports field customization and sorting

  • paper_references: Get papers referenced by a specific paper

    • Returns paginated list of referenced papers

    • Includes reference context when available

    • Supports field customization and sorting

Author Tools

  • author_search: Search for authors by name

    • Returns paginated results with customizable fields

    • Includes affiliations and publication counts

  • author_details: Get detailed information about an author

    • Returns comprehensive author metadata

    • Includes metrics like h-index and citation counts

  • author_papers: Get papers written by an author

    • Returns paginated list of author's publications

    • Supports field customization and sorting

  • author_batch_details: Get details for multiple authors

    • Efficiently retrieve information for up to 1000 authors

    • Returns the same fields as single author details

Recommendation Tools

  • get_paper_recommendations_single: Get recommendations based on a single paper

    • Returns similar papers based on content and citation patterns

    • Supports field customization for recommended papers

  • get_paper_recommendations_multi: Get recommendations based on multiple papers

    • Accepts positive and negative example papers

    • Returns papers similar to positive examples and dissimilar to negative ones

Usage Examples

Basic Paper Search

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

Paper Recommendations

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

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

Batch Operations

# 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 Handling

The server provides standardized error responses:

{
    "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