複数のソースから学術論文情報を検索および取得できるモデル コンテキスト プロトコル (MCP)サーバー。
サーバーは LLM に次のものを提供します。
リアルタイムの学術論文検索機能
論文のメタデータと抄録へのアクセス
利用可能な場合はフルテキストコンテンツを取得する機能
MCP仕様に準拠した構造化データレスポンス
MCP 仕様は主に Anthropic の Claude Desktop クライアントとの統合を目的として設計されていますが、ツール/関数呼び出し機能 (OpenAI の API など) をサポートする他の AI モデルやクライアントとの互換性も考慮されています。
注意：このソフトウェアは現在開発中です。機能は変更される可能性があります。
このサーバーは次のツールを公開します。
search_papers : 複数のソースから学術論文を検索
パラメータ:
query (str): 検索クエリテキスト
limit (int, オプション): 返される結果の最大数 (デフォルト: 10)
戻り値: 論文の詳細を含むフォーマットされた文字列
fetch_paper_details : 特定の論文の詳細情報を取得する
パラメータ:
paper_id (str): 論文識別子（DOIまたはSemantic Scholar ID）
source (str, オプション): データソース ("crossref" または "semantic_scholar", デフォルト: "crossref")
戻り値: 以下の包括的な論文メタデータを含むフォーマットされた文字列:
タイトル、著者、年、DOI
会場、オープンアクセスステータス、PDF URL（Semantic Scholarのみ）
要約とTL;DR要約（利用可能な場合）
search_by_topic : オプションの日付範囲フィルターを使用してトピックで論文を検索します
パラメータ:
topic (str): 検索クエリテキスト（300文字まで）
year_start (int, オプション): 日付範囲の開始年
year_end (int, オプション): 日付範囲の終了年
limit (int, オプション): 返される結果の最大数 (デフォルト: 10)
戻り値: 次の検索結果を含むフォーマットされた文字列:
論文のタイトル、著者、年
要約とTL;DR要約（利用可能な場合）
会場およびオープンアクセス情報
Related MCP server: Research MCP
Smithery経由で Claude Desktop 用の Academic Paper Search Server を自動的にインストールするには:
npx -y @smithery/cli install @afrise/academic-search-mcp-server --client claude***注意:***この方法は、サーバーに問題があるようなので、ほとんどテストされていません。 smithery が修正されるまで、スタンドアロンの指示に従うことができます。
依存関係をインストールします:
uv add "mcp[cli]" httpx環境または.envファイルで必要な API キーを設定します。
# These are not actually implemented
SEMANTIC_SCHOLAR_API_KEY=your_key_here
CROSSREF_API_KEY=your_key_here # Optional but recommendedサーバーを実行します。
uv run server.pyサーバーを Claude Desktop 構成 ( claude_desktop_config.json ) に追加します。
{
"mcpServers": {
"academic-search": {
"command": "uv",
"args": ["run ", "/path/to/server/server.py"],
"env": {
"SEMANTIC_SCHOLAR_API_KEY": "your_key_here",
"CROSSREF_API_KEY": "your_key_here"
}
}
}
}Claudeデスクトップを再起動します
このサーバーは以下を使用して構築されています:
Python MCP SDK
簡素化されたサーバー実装のためのFastMCP
APIリクエスト用のhttpx
セマンティック・スカラーAPI
クロスリファレンスAPI
このプロジェクトは、GNU Affero General Public License v3.0（AGPL-3.0）に基づいてライセンスされています。このライセンスは、以下のことを保証します。
このソフトウェアは自由に使用、変更、配布することができます
いかなる変更も同じライセンスの下でオープンソース化されなければならない
このソフトウェアを使用してネットワークサービスを提供する者は、ソースコードを公開する必要がある。
商用利用は許可されているが、ソフトウェアとその派生物はフリーかつオープンソースのままでなければならない。
完全なライセンス テキストについては、 LICENSEファイルを参照してください。
貢献を歓迎します！ご協力いただける方法は次のとおりです。
リポジトリをフォークする
機能ブランチを作成する ( git checkout -b feature/amazing-feature )
変更をコミットします（ git commit -m 'Add amazing feature' ）
ブランチにプッシュする ( git push origin feature/amazing-feature )
プルリクエストを開く
ご注意ください：
既存のコードスタイルと規則に従う
新しい機能のテストを追加する
必要に応じてドキュメントを更新する
変更がAGPL-3.0ライセンス条項を遵守していることを確認してください
このプロジェクトに貢献することにより、貢献内容が AGPL-3.0 ライセンスの下でライセンスされることに同意したことになります。
Get detailed information about a specific paper.
Args:
paper_id: Paper identifier (DOI for Crossref, paper ID for Semantic Scholar)
source: Source database ("semantic_scholar" or "crossref")
| Name | Required | Description | Default |
|---|---|---|---|
| paper_id | Yes | ||
| source | No | semantic_scholar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] detailed information,' which implies a read-only operation, but it doesn't disclose any behavioral traits such as authentication needs, rate limits, error handling, or what 'detailed information' includes. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a clear purpose statement followed by a concise 'Args' section that lists parameters with brief explanations. Every sentence earns its place by providing essential information without unnecessary details, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and parameters well, but it lacks information on behavioral aspects like what 'detailed information' entails, potential errors, or usage constraints. Without an output schema, the description should ideally hint at the return structure, but it doesn't, leaving some context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'paper_id' is a 'Paper identifier (DOI for Crossref, paper ID for Semantic Scholar)' and 'source' is a 'Source database' with options 'semantic_scholar' or 'crossref'. This clarifies the purpose and format of the parameters, compensating well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about a specific paper.' This specifies the verb ('Get') and resource ('paper'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'search_by_topic' or 'search_papers', which likely return lists rather than details for a specific paper.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying that it's for a 'specific paper' and lists the required 'paper_id' and optional 'source' parameters. This suggests it should be used when you have a known paper identifier, but it doesn't explicitly state when to use this tool versus the sibling search tools or provide any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for papers by topic with optional date range.
Note: Query length is limited to 300 characters. Longer queries will be automatically truncated.
Args:
topic (str): Search query (max 300 chars)
year_start (int, optional): Start year for date range
year_end (int, optional): End year for date range
limit (int, optional): Maximum number of results to return (default 10)
Returns:
str: Formatted search results or error message
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | Yes | ||
| year_end | No | ||
| year_start | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: the query length limit (300 characters with truncation) and the return type (formatted search results or error message). However, it lacks details on permissions, rate limits, error conditions beyond truncation, or pagination behavior, which are important for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured. It starts with a clear purpose statement, adds a critical behavioral note (query length limit), and then lists parameters and returns in a formatted way. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is partially complete. It covers parameters and basic behavior but lacks output details (e.g., result format beyond 'formatted'), error handling specifics, and differentiation from siblings. For a search tool, this leaves gaps in guiding the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: 'topic' as the search query with a character limit, 'year_start' and 'year_end' for date range, and 'limit' for maximum results with a default. This compensates well for the schema's lack of descriptions, though it could note that year parameters are optional integers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for papers by topic with optional date range.' It specifies the verb ('search'), resource ('papers'), and scope ('by topic with optional date range'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_papers' or 'fetch_paper_details,' which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_papers' or 'fetch_paper_details.' It mentions optional parameters like date range and limit, but doesn't explain scenarios where this tool is preferred over siblings or any prerequisites for usage. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for papers across multiple sources.
args:
query: the search query
limit: the maximum number of results to return (default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions searching 'across multiple sources' but does not cover critical aspects such as authentication needs, rate limits, pagination, or what the response format looks like. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose, but the 'args' section is somewhat redundant as it repeats parameter names without adding new insights. It could be more structured to avoid duplication and enhance clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with no annotations and no output schema, the description is incomplete. It lacks details on result format, error handling, source specifics, and behavioral traits, making it inadequate for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for both parameters: 'query' is explained as 'the search query,' and 'limit' as 'the maximum number of results to return (default 10).' Since schema description coverage is 0%, this compensates well by clarifying parameter purposes beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Search for papers across multiple sources,' which provides a clear verb ('Search') and resource ('papers'). However, it does not differentiate from sibling tools like 'search_by_topic' or specify what 'multiple sources' entails, making it somewhat vague in distinguishing its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_by_topic' or 'fetch_paper_details.' The description lacks context on scenarios, prerequisites, or exclusions, leaving usage decisions unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0fetch_paper_detailssearch_by_topicsearch_papersScored across 3 tools
The tools 'search_by_topic' and 'search_papers' have significant overlap in purpose—both search for papers, with only minor differences in parameters. This creates ambiguity, as an agent might struggle to choose between them. The 'fetch_paper_details' tool is distinct, but the two search tools are not clearly differentiated.
The naming is mixed: 'fetch_paper_details' uses a verb_noun pattern, while 'search_by_topic' and 'search_papers' use verb_preposition_noun and verb_noun styles, respectively. This inconsistency makes the set less predictable, though the names are still readable and descriptive.
With only 3 tools, the server feels thin for an academic paper search domain. It lacks essential operations like filtering by author, journal, or citation count, and there's no update or delete functionality, which limits its utility for comprehensive paper management.
The tool surface is incomplete for academic paper search. It covers basic fetch and search operations but misses key features such as author-based searches, citation tracking, paper categorization, or integration with reference managers. This will likely cause agent failures in complex workflows.
Search 340M+ academic papers — citation graphs, semantic similarity, and AI literature reviews.
Find academic papers across major sources like arXiv, PubMed, bioRxiv, and more. Download PDFs whe…
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Academic paper search, scientific literature, citation analysis, arXiv & semantic related-work.
