ScholarScope MCP is an academic research server that provides comprehensive access to scholarly literature and research data through the OpenAlex API.
Core Capabilities:
Search academic papers by keywords with customizable search fields (default, title, or title+abstract), filtering by institution or author ID, and sorting by relevance, citation count, or publication date
Search authors by name with filtering by institution affiliation and sorting by relevance or citation count
Search institutions by name with relevance and citation-based sorting
Retrieve all papers by a specific author using their OpenAlex Author ID, sorted by citations or publication date
Citation and relationship analysis - find works citing a paper (forward citations), works referenced by a paper (backward citations), and related works
Fetch full-text content of papers from preferred full-text URLs using Jina AI integration, with access to open-access and publicly available content
Access comprehensive metadata including paper IDs, titles, authors, institution affiliations, publication dates, and citation counts
Pagination support across all search functions for browsing large result sets efficiently
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ScholarScope MCP find recent papers about large language models in education"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Academic MCP Server
The ScholarScope MCP Server is a custom Model Context Protocol server built with FastMCP for powerful academic research tasks.
It integrates with the OpenAlex API to search for papers, authors, institutions, retrieve citations, and even fetch full text using Jina where available.
🔍 Perfect for building intelligent research assistants that can:
Search academic literature by keywords, author, or institution
Explore related works and citations
Retrieve full-text papers directly when possible
Related MCP server: OpenAlex MCP Server
Clone the repository
git clone https://github.com/ErikNguyen20/ScholarScope-MCP.git
cd ScholarScope-MCPInstall uv (if you don't already have it)
pip install uvInstall dependencies
uv syncSet up environment variables
Create a .env file in the project root:
OPENALEX_MAILTO=your_email@example.comYou can use the official MCP Inspector to test your server locally:
npx @modelcontextprotocol/inspector uv run \
--directory "/path/to/mcp_server" \
--with fastmcp \
fastmcp run src/server.py[!Note] Replace
/path/to/mcp_serverwith the path to your local project root.
Open your Claude Desktop configuration file (usually claude_desktop_config.json).
Add your MCP server configuration:
{
"mcpServers": {
"Tool Example": {
"command": "uv",
"args": [
"run",
"--directory", "/path/to/mcp_server",
"fastmcp",
"run",
"src/server.py"
]
}
}
}[!Note] Ensure the
/path/to/mcp_servermatches your local directory structure.
Restart Claude Desktop after updating the config.
🔍 Search papers by keyword, title, author, or institution
📊 Sort results by relevance, citations, or publication date
📚 Retrieve related works and citations for any paper
📄 Fetch full text from preferred sources when available
⚡ Built with FastMCP for fast startup and modular tools
Retrieves the contents of a paper or work from its preferred full-text URL and returns the response body as plain text.
Note: In some cases, the target content may be paywalled, require authentication, or otherwise restrict access. In such situations, the returned output may consist of partial content, metadata, or an access notice rather than the complete text.
Args: preferred_fulltext_url: Preferred full-text URL of the paper or work.
Returns: Plaintext representation of the retrieved content. This may be the complete text, or a limited excerpt if access to the full resource is restricted.
| Name | Required | Description | Default |
|---|---|---|---|
| preferred_fulltext_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations (readOnlyHint, idempotentHint) by disclosing potential access restrictions (paywalls, authentication) and possible partial outputs. This helps the agent understand real-world limitations, though it doesn't cover rate limits or detailed error handling.
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 well-structured with a clear main statement, a note section for important caveats, and separate Args/Returns sections. Every sentence adds value without redundancy, 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 (single parameter, read-only/idempotent annotations, output schema exists), the description is complete. It covers purpose, usage notes, parameter meaning, and output behavior, with the output schema handling return value details, leaving no significant 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?
With 0% schema description coverage, the description fully compensates by explaining the parameter's meaning ('Preferred full-text URL of the paper or work'), adding essential semantics not present in the schema. It clarifies what the URL represents, though it could provide more on format or validation.
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 with specific verbs ('retrieves', 'returns') and resources ('contents of a paper or work', 'preferred full-text URL'), distinguishing it from sibling tools that search or list papers rather than fetch full content. It precisely defines what the tool does without ambiguity.
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 clear context for when to use this tool (to get full-text content from a URL) but does not explicitly mention when not to use it or name specific alternatives among the sibling tools. It implies usage for retrieving text content rather than metadata or search operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for academic papers by a particular author using the OpenAlex API.
Args: author_id: An OpenAlex Author ID of target author. e.g., "https://openalex.org/A123456789" sort_by: The sorting criteria ("cited_by_count", or "publication_date"). page: The page number of the results to retrieve (default: 1).
Returns: A JSON object containing a list of papers+ids by the specified author, or an error message if the search fails.
| Name | Required | Description | Default |
|---|---|---|---|
| author_id | Yes | ||
| sort_by | No | cited_by_count | |
| page | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| page | Yes | |
| has_next | No | |
| per_page | Yes | |
| total_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the API and error handling, it lacks critical details: authentication requirements, rate limits, pagination behavior beyond the 'page' parameter, whether results are cached, or what specific error conditions might occur. The description provides basic operational context but misses important behavioral traits.
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 well-structured with clear sections (purpose, args, returns) and efficiently conveys essential information. Every sentence serves a purpose, though the 'Returns' section could be slightly more concise given the existence of an output schema.
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 (3 parameters, no annotations, but with output schema), the description is adequate but has gaps. The output schema existence reduces the need to detail return values, but the description lacks context about API limitations, error specifics, and differentiation from sibling tools. It covers the basics but misses some operational context.
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?
With 0% schema description coverage, the description must compensate for the schema's lack of parameter documentation. It successfully explains all three parameters: 'author_id' (OpenAlex Author ID with example), 'sort_by' (sorting criteria with enum values), and 'page' (page number with default). The description adds meaningful context beyond what the bare schema provides.
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 specific action ('searches for academic papers') and resource ('by a particular author using the OpenAlex API'), distinguishing it from sibling tools like 'search_papers' (general paper search) and 'search_authors' (author search). It provides a complete, unambiguous purpose statement.
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' (which might allow broader searches) or 'referenced_works_in_paper' (which focuses on citations). It mentions the OpenAlex API but doesn't explain when author-specific searches are appropriate versus other search methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets referenced works used in the specified paper using the OpenAlex API. Note: May return empty if the paper's full text is inaccessible.
Args: paper_id: An OpenAlex Work ID of the target paper. e.g., "https://openalex.org/W123456789"
Returns: A JSON object containing a list of paper ids used in the work, or an error message if the fetch fails.
| Name | Required | Description | Default |
|---|---|---|---|
| paper_id | Yes |
| Name | Required | Description |
|---|---|---|
| data | No | |
| count | 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 effectively describes key behaviors: it uses the OpenAlex API, may return empty results if full text is inaccessible, and returns a JSON object with a list of paper ids or an error message on failure. This covers operational context and error handling, though it could add more on rate limits or authentication needs.
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 well-structured and front-loaded with the core purpose, followed by a note on limitations, and then clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
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 low complexity (1 parameter), no annotations, and the presence of an output schema (which handles return values), the description is complete enough. It covers purpose, usage notes, parameter semantics, and return behavior, providing all necessary context for effective tool invocation without overloading with unnecessary details.
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 input schema has 0% description coverage, so the description must compensate. It adds meaningful semantics by explaining that 'paper_id' is 'An OpenAlex Work ID of the target paper' and provides an example format ('https://openalex.org/W123456789'), which clarifies usage beyond the schema's basic string type. However, it does not detail constraints like valid ID patterns or length, keeping it from a score of 5.
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: 'Gets referenced works used in the specified paper using the OpenAlex API.' It specifies the verb ('Gets'), resource ('referenced works'), and target ('specified paper'), but does not explicitly differentiate it from sibling tools like 'related_works_of_paper' or 'works_citing_paper', which prevents a score of 5.
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 implied usage guidance through the note about potential empty returns when 'the paper's full text is inaccessible,' which suggests when this tool might not be effective. However, it lacks explicit guidance on when to use this tool versus alternatives like 'related_works_of_paper' or 'works_citing_paper,' and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for authors using the OpenAlex API.
Args: query: The search name to look for the authors. sort_by: The sorting criteria ("relevance_score" or "cited_by_count"). institution_id: An optional institution id to filter search results. e.g., "https://openalex.org/I123456789" page: The page number of the results to retrieve (default: 1).
Returns: A JSON object containing a list of authors+ids, or an error message if the search fails.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| sort_by | No | relevance_score | |
| institution_id | No | ||
| page | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| page | Yes | |
| has_next | No | |
| per_page | Yes | |
| total_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions that it returns a JSON object or error message. It lacks details on rate limits, authentication needs, pagination behavior beyond the 'page' parameter, or what happens with empty results.
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 well-structured with clear sections for Args and Returns, and each sentence adds value. It could be slightly more concise by integrating the default values more seamlessly, but overall it's efficient.
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 4 parameters with 0% schema coverage and an output schema present, the description adequately covers parameters but lacks behavioral context (e.g., error conditions, API constraints). The output schema reduces the need to detail return values, but more operational guidance would help.
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?
Schema description coverage is 0%, but the description compensates by explaining all 4 parameters: 'query' as the search name, 'sort_by' with criteria options, 'institution_id' as an optional filter with an example, and 'page' with its default. This adds meaningful context 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 clearly states the tool searches for authors using the OpenAlex API, specifying the resource (authors) and action (search). However, it doesn't explicitly differentiate from sibling tools like 'search_institutions' or 'search_papers' beyond mentioning the resource type.
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 'papers_by_author' or other search tools. The description only states what it does without context about use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for institutions using the OpenAlex API.
Args: query: The search name to look for the institutions. sort_by: The sorting criteria ("relevance_score" or "cited_by_count"). page: The page number of the results to retrieve (default: 1).
Returns: A JSON object containing a list of institutions+ids, or an error message if the search fails.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| sort_by | No | relevance_score | |
| page | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| page | Yes | |
| has_next | No | |
| per_page | Yes | |
| total_count | 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 mentions the API source and error handling, but lacks critical details like rate limits, authentication requirements, pagination behavior beyond the 'page' parameter, or what constitutes a 'failed' search. This leaves significant gaps for an agent to understand operational constraints.
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 well-structured with clear sections (Args, Returns) and uses efficient sentences. However, the first sentence could be more front-loaded with key details, and some redundancy exists (e.g., 'The search name to look for the institutions' could be tighter). Overall, it's concise but has minor room for improvement.
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 (3 parameters, no annotations, but with an output schema), the description is partially complete. It covers basic input semantics and return values, but lacks behavioral context (e.g., API limits, error conditions) and usage guidelines relative to siblings. The output schema reduces the need to detail return values, but other gaps remain.
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?
Schema description coverage is 0%, so the description must compensate. It adds basic semantics for all three parameters (e.g., 'query' is a search name, 'sort_by' has two criteria, 'page' retrieves results), but doesn't provide deeper context like query syntax examples, how 'cited_by_count' sorting works, or pagination limits. This partially addresses the schema gap but not fully.
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 verb ('Searches for') and resource ('institutions') using a specific API ('OpenAlex API'), making the purpose unambiguous. However, it doesn't explicitly differentiate this tool from sibling tools like 'search_authors' or 'search_papers' beyond the resource type, which prevents 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. It doesn't mention sibling tools like 'search_authors' or 'search_papers' for comparison, nor does it specify scenarios where searching institutions is appropriate over other search tools. Usage is implied by the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for academic papers using the OpenAlex API.
Args: query: The search term or keywords to look for in the papers. search_by: The field to search in ("default", "title", or "title_and_abstract"). sort_by: The sorting criteria ("relevance_score", "cited_by_count", or "publication_date"). institution_name: An optional institution or affiliation name to filter search results. author_id: An optional OpenAlex Author ID to filter search results. e.g., "https://openalex.org/A123456789" page: The page number of the results to retrieve (default: 1).
Returns: A JSON object containing a list of searched papers+ids, or an error message if the search fails.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| search_by | No | default | |
| sort_by | No | relevance_score | |
| institution_name | No | ||
| author_id | No | ||
| page | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| page | Yes | |
| has_next | No | |
| per_page | Yes | |
| total_count | 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 mentions the API (OpenAlex) and return format (JSON object with papers or error), but lacks details on rate limits, authentication needs, pagination behavior beyond the 'page' parameter, or what constitutes a 'failed' search. For a search tool with 6 parameters, this is insufficient.
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 well-structured with clear sections (Args, Returns) and uses bullet-like formatting for parameters. Every sentence adds value, but it could be more front-loaded by stating the core purpose more prominently before diving into parameters. Overall, it's efficient with minimal waste.
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 (6 parameters, no annotations, but has output schema), the description is moderately complete. It explains parameters well and notes the return format, but lacks behavioral context (e.g., rate limits, error conditions). The output schema existence reduces the need to detail return values, but more operational guidance would improve completeness.
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?
Schema description coverage is 0%, so the description must compensate. It provides clear explanations for all 6 parameters, including optionality, defaults, and examples (e.g., author_id format). This adds significant meaning beyond the bare schema, though it doesn't cover all possible edge cases or advanced usage scenarios.
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 'searches for academic papers using the OpenAlex API,' which is a specific verb+resource combination. It distinguishes itself from siblings like 'search_authors' and 'search_institutions' by focusing on papers, but doesn't explicitly differentiate from 'fetch_fulltext' or 'works_citing_paper' in terms of search scope versus retrieval.
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 'papers_by_author' (which might fetch papers by a specific author) or 'search_authors' (which searches for authors instead of papers). It lacks explicit when/when-not instructions or named alternatives, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves works that cite a given paper from the OpenAlex API.
Args: paper_id: An OpenAlex Work ID of target paper. e.g., "https://openalex.org/W123456789" sort_by: The sorting criteria ("cited_by_count", or "publication_date"). page: The page number of the results to retrieve (default: 1).
Returns: A JSON object containing a list of papers+ids citing the specific paper, or an error message if the retrieval fails.
| Name | Required | Description | Default |
|---|---|---|---|
| paper_id | Yes | ||
| sort_by | No | cited_by_count | |
| page | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| page | Yes | |
| has_next | No | |
| per_page | Yes | |
| total_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions retrieval from an API and potential error messages, but lacks details on rate limits, authentication needs, pagination behavior beyond the 'page' parameter, or what the JSON structure looks like (though output schema exists). For a tool with no annotation coverage, this leaves significant behavioral gaps.
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 front-loaded with the core purpose, followed by structured sections for args and returns. It's efficient with minimal waste, though the 'Returns' section could be slightly more concise given the output schema exists. Overall, it's well-structured and appropriately sized.
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 has an output schema (which handles return values), no annotations, and moderate complexity with 3 parameters, the description is fairly complete. It covers purpose, parameters, and basic behavior, but lacks deeper context like error handling details or API-specific constraints, which slightly reduces completeness.
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?
Schema description coverage is 0%, so the description must compensate. It explains each parameter's purpose: 'paper_id' as the target paper ID with an example, 'sort_by' as sorting criteria with options, and 'page' as page number with default. This adds meaningful context beyond the schema's titles and enums, though it doesn't detail format constraints beyond the example.
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 verb 'Retrieves' and the resource 'works that cite a given paper from the OpenAlex API', specifying the exact operation. It distinguishes from siblings like 'referenced_works_in_paper' (which would find works referenced by a paper) and 'related_works_of_paper' (which might find conceptually related works), making the purpose specific and differentiated.
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 when you need to find papers citing a specific paper, but it does not explicitly state when to use this tool versus alternatives like 'search_papers' (which might allow broader searches) or 'referenced_works_in_paper'. No exclusions or prerequisites are mentioned, leaving usage context somewhat implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no ambiguity. The tools cover different aspects of academic research: fetching full text, searching for papers/authors/institutions, getting author papers, and analyzing paper relationships (references, related works, citations). There is no overlap in functionality.
All tools follow a consistent verb_noun pattern with snake_case throughout. The naming is predictable and readable: fetch_fulltext, papers_by_author, referenced_works_in_paper, related_works_of_paper, search_authors, search_institutions, search_papers, works_citing_paper.
With 8 tools, this is well-scoped for an academic research server. Each tool earns its place by covering essential operations: searching across different entity types, fetching content, and analyzing paper relationships. The count is neither too thin nor too heavy for the domain.
The tool surface provides excellent coverage for academic research workflows: searching, fetching, and relationship analysis. Minor gaps exist, such as no direct tools for updating metadata or managing user collections, but agents can accomplish core research tasks effectively with the provided tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Academic literature search, retrieval, and private library management on top of OpenAlex.
Access the OpenAlex academic research catalog — 270M+ publications.
OpenAlex MCP — wraps the OpenAlex API (scholarly works, free, no auth)
Scholarly search: OpenAlex, Crossref, arXiv, OpenCitations and PubMed in one endpoint.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ErikNguyen20/ScholarScope-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
