en es ja ko zh

Semantic Scholar MCP Server

Name: Semantic Scholar MCP Server
Author: zongmin-yu

by zongmin-yu

Overview Schema Source Related Servers Discussions Admin

Python

Remote

セマンティック・スカラーMCPサーバー

鍛冶屋のバッジ

Semantic Scholar API 用の FastMCP サーバー実装。学術論文データ、著者情報、引用ネットワークへの包括的なアクセスを提供します。

プロジェクト構造

このプロジェクトは、保守性を向上させるためにモジュール構造にリファクタリングされました。

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

この構造:

懸念事項を論理モジュールに分割する
コードベースの理解と保守が容易になります
より良いテストと将来の拡張が可能
関連する機能をグループ化します
循環インポートを回避するためにFastMCPインスタンスを集中管理します

Related MCP server: AI Research Assistant - Semantic Scholar

特徴

論文検索と発見
- 高度なフィルタリングによる全文検索
- タイトルベースの論文マッチング
- 論文の推奨事項（単一論文および複数論文）
- バッチペーパーの詳細検索
- ランキング戦略を備えた高度な検索
引用分析
- 引用ネットワーク探索
- 参照追跡
- 引用の文脈と影響の分析
著者情報
- 著者検索とプロフィール詳細
- 出版履歴
- 著者詳細の一括取得
高度な機能
- 複数のランキング戦略を備えた複雑な検索
- カスタマイズ可能なフィールド選択
- 効率的なバッチ操作
- レート制限コンプライアンス
- 認証されたアクセスと認証されていないアクセスの両方をサポート
- 正常なシャットダウンとエラー処理
- 接続プールとリソース管理

システム要件

Python 3.8以上
FastMCPフレームワーク
APIキーの環境変数（オプション）

インストール

Smithery経由でインストール

Smithery経由で Claude Desktop 用の Semantic Scholar MCP Server を自動的にインストールするには:

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

手動インストール

リポジトリをクローンします。

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

FastMCP とその他の依存関係を次のようにインストールします: https://github.com/jlowin/fastmcp
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セクションを完全に削除できます。

サーバーの使用を開始します。

これで、Claude Desktopインスタンスからサーバーが利用できるようになります。手動でコマンドを実行する必要はありません。Claudeは必要に応じてサーバープロセスを自動的に起動し、管理します。

APIキー（オプション）

より高いレート制限とより良いパフォーマンスを得るには:

Semantic Scholar APIからAPIキーを取得する
上記のenvセクションに示すように、FastMCP構成に追加します。

API キーが提供されない場合、サーバーはレート制限が低い認証されていないアクセスを使用します。

構成

環境変数

SEMANTIC_SCHOLAR_API_KEY : Semantic Scholar API キー（オプション）
- Semantic Scholar APIからキーを取得する
- 指定しない場合、サーバーは認証されていないアクセスを使用します

レート制限

サーバーは適切なレート制限に自動的に調整します。

APIキーの場合:

検索、バッチ、推奨エンドポイント: 1 秒あたり 1 リクエスト
その他のエンドポイント: 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 : 複数の論文の詳細を効率的に取得する
- 1回のリクエストにつき最大1000枚の紙IDを受け付けます
- 単一の紙の詳細と同じID形式とフィールドをサポートします

引用ツール

paper_citations : 特定の論文を引用している論文を取得する
- 引用論文のページ区切りリストを返します
- 利用可能な場合は引用コンテキストも含めます
- フィールドのカスタマイズと並べ替えをサポート
paper_references : 特定の論文によって参照されている論文を取得する
- 参照論文のページ区切りリストを返します
- 利用可能な場合は参照コンテキストを含める
- フィールドのカスタマイズと並べ替えをサポート

著者ツール

author_search : 著者名で検索
- カスタマイズ可能なフィールドを持つページ区切りの結果を返します
- 所属と出版物数を含む
author_details : 著者に関する詳細情報を取得する
- 包括的な著者メタデータを返す
- h指数や引用数などの指標が含まれます
author_papers : 著者が書いた論文を取得する
- 著者の出版物のページ区切りリストを返します
- フィールドのカスタマイズと並べ替えをサポート
author_batch_details : 複数の著者の詳細を取得する
- 最大1000人の著者の情報を効率的に取得
- 単一の著者の詳細と同じフィールドを返します

推奨ツール

paper_recommendations_single : 1つの論文に基づいて推奨事項を取得します
- 内容と引用パターンに基づいて類似の論文を返します
- 推奨論文のフィールドカスタマイズをサポート
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

Name	Required	Description	Default
`author_ids`	Yes
`fields`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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

Name	Required	Description	Default
`author_id`	Yes
`fields`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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

Name	Required	Description	Default
`author_id`	Yes
`fields`	No
`offset`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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_searchD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`fields`	No
`offset`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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

Name	Required	Description	Default
`positive_paper_ids`	Yes
`negative_paper_ids`	No
`fields`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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

Name	Required	Default
`paper_id`	Yes
`fields`	No
`limit`	No
`from_pool`	No	recent

Output Schema

ParametersJSON Schema

Name	Required	Description
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

Name	Required	Description	Default
`paper_id`	Yes
`fields`	No
`offset`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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

Name	Required	Description	Default
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
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

Name	Required	Description	Default
`paper_ids`	Yes
`fields`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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_bulk_searchD

ParametersJSON Schema

Name	Required	Description	Default
`query`	No
`token`	No
`fields`	No
`sort`	No
`publication_types`	No
`open_access_pdf`	No
`min_citation_count`	No
`publication_date_or_year`	No
`year`	No
`venue`	No
`fields_of_study`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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

Name	Required	Description	Default
`paper_id`	Yes
`fields`	No
`offset`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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

Name	Required	Description	Default
`paper_id`	Yes
`fields`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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

Name	Required	Description	Default
`paper_id`	Yes
`fields`	No
`offset`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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_relevance_searchD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`fields`	No
`publication_types`	No
`open_access_pdf`	No
`min_citation_count`	No
`year`	No
`venue`	No
`fields_of_study`	No
`offset`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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_title_searchD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`fields`	No
`publication_types`	No
`open_access_pdf`	No
`min_citation_count`	No
`year`	No
`venue`	No
`fields_of_study`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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.

snippet_searchD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`fields`	No
`limit`	No
`paper_ids`	No
`authors`	No
`min_citation_count`	No
`inserted_before`	No
`publication_date_or_year`	No
`year`	No
`venue`	No
`fields_of_study`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
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.

16 tool updatesv0.1.0Apr 17, 2026
- 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 2026-04-18 11:50 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

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Academic Research Intelligence MCP A
io.github.FoundryNet
Academic paper search, scientific literature, citation analysis, arXiv & semantic related-work.
Research & Data Search
2
nobleblocks-mcp
com.nobleblocks
Search 340M+ academic papers — citation graphs, semantic similarity, and AI literature reviews.
Research & Data Search AI & Machine Learning
21
Semanticscholar A
io.github.pipeworx-io
Semantic Scholar Academic Graph MCP.
Research & Data Search
352
openalex-mcp-server A
io.github.cyanheads
Access the OpenAlex academic research catalog — 270M+ publications.
Search Research & Data Open Data
5214

Related MCP Servers

Semantic Scholar MCP Server
Search Research & Data Documentation Access
fegizii
A
license
A
quality
D
maintenance
Enables access to the Semantic Scholar Academic Graph API for searching and retrieving detailed information about academic papers, authors, citations, and references.
Updated a year ago (2025-07-02 16:13 UTC)
11
3
MIT
AI Research Assistant -
Research & Data Search RAG Systems
hamid-vakilzadeh
A
license
Not graded
quality
F
maintenance
Enables comprehensive academic research through the Semantic Scholar API, including paper search, author discovery, citation network analysis, and full-text access from arXiv and Wiley sources.
Updated 6 months ago (2026-03-26 20:14 UTC)
23 npm
28
ISC
semantic-scholar-mcp
Research & Data Search
benhaotang
A
license
Not graded
quality
D
maintenance
Enables searching and retrieving academic paper metadata from Semantic Scholar, including paper details, citations, and author information.
Updated a year ago (2025-04-05 00:20 UTC)
21
MIT
semantic-scholar-mcp-server
Research & Data Search
SMABoundless
A
license
A
quality
C
maintenance
Provides tools to search, retrieve, and explore over 200M academic papers, authors, citations, and full-text snippets via the Semantic Scholar API.
Updated 2 months ago (2026-07-04 21:29 UTC)
16
26 npm
MIT

セマンティック・スカラーMCPサーバー

プロジェクト構造

特徴

システム要件

インストール

Smithery経由でインストール

手動インストール

APIキー（オプション）

構成

環境変数

レート制限

利用可能なMCPツール

論文検索ツール

引用ツール

著者ツール

推奨ツール

使用例

基本的な論文検索

論文の推奨事項

バッチ操作

エラー処理

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches