Provides access to the OpenAlex API for searching and retrieving scholarly research data including 240M+ works, authors with ORCID integration, sources, institutions, concepts, publishers, and funders. Supports full-text search, filtering, aggregation, and text classification for research topics.
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., "@OpenAlex MCP Server find recent papers about quantum computing"
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.
A Model Context Protocol (MCP) server that provides access to the OpenAlex API - a fully open catalog of the global research system covering over 240 million scholarly works.
This MCP server provides tools to search and retrieve:
Works - Scholarly articles, preprints, datasets, books (240M+ items)
Authors - Researchers and creators with ORCID integration
Sources - Journals, conferences, repositories (~250K venues)
Institutions - Universities, hospitals, labs with ROR matching
Concepts - Hierarchical research topics (levels 0-5)
Publishers - Publishing organizations
Funders - Grant-making bodies
Autocomplete - Type-ahead search across all entity types
Text Classification - Concept prediction for arbitrary text
Related MCP server: OpenAlex MCP Server
npm install -g openalex-mcpgit clone https://github.com/reetp14/openalex-mcp.git
cd openalex-mcp
npm install
npm run buildAdd to your MCP client configuration:
{
"mcpServers": {
"openalex": {
"command": "npx",
"args": ["openalex-mcp"]
}
}
}
json
Or if installed locally:
{
"mcpServers": {
"openalex": {
"command": "node",
"args": ["./node_modules/openalex-mcp/build/index.js"]
}
}
}All search tools support the full OpenAlex query grammar:
search_works - Search scholarly works
search_authors - Search researchers and creators
search_sources - Search journals, conferences, repositories
search_institutions - Search universities, hospitals, labs
search_concepts - Search research topics
search_publishers - Search publishing organizations
search_funders - Search grant-making bodies
Common Parameters:
search - Full-text search query
filter - Boolean filters (e.g., concept.id:C12345,from_publication_date:2022-01-01)
sort - Sort field with optional :desc (e.g., cited_by_count:desc)
page/per_page - Standard pagination (max 10,000 results total)
cursor - Deep pagination (use * for first call)
group_by - Faceting/aggregation by field
select - Comma-separated fields to return
sample - Random sample size with optional seed
mailto - Your email for higher rate limits
get_entity - Get a single entity by OpenAlex ID
entity_type - One of: works, authors, sources, institutions, concepts, publishers, funders
openalex_id - OpenAlex ID (e.g., W2741809807, A1969205038)
autocomplete - Type-ahead search across entity types
search - Search query (required)
type - Entity type to search within (optional)
per_page - Number of suggestions (max 50)
classify_text - Predict research concepts from text
title - Title text to classify
abstract - Abstract text to classify
{
"tool": "search_works",
"arguments": {
"search": "artificial intelligence",
"filter": "from_publication_date:2023-01-01,to_publication_date:2023-12-31",
"sort": "cited_by_count:desc",
"per_page": 10,
"mailto": "researcher@university.edu"
}
}{
"tool": "search_authors",
"arguments": {
"filter": "last_known_institution.id:I27837315",
"sort": "works_count:desc",
"select": "id,display_name,works_count,cited_by_count"
}
}{
"tool": "search_works",
"arguments": {
"filter": "concepts.id:C154945302",
"group_by": "publication_year"
}
}{
"tool": "autocomplete",
"arguments": {
"search": "nature",
"type": "sources",
"per_page": 5
}
}{
"tool": "classify_text",
"arguments": {
"title": "Deep Learning for Medical Image Analysis",
"abstract": "We present a novel approach using convolutional neural networks..."
}
}Chain with , for AND: concept.id:C12345,publication_year:2023
Chain with | for OR: type:journal|type:repository
Negate with !: authors.id!A12345 (exclude author)
Date ranges: from_publication_date:2020-01-01,to_publication_date:2023-12-31
Ascending: sort=publication_year
Descending: sort=cited_by_count:desc
Multiple: sort=publication_year:desc,cited_by_count:desc
Standard: page=2&per_page=100 (max 10,000 results)
Deep: cursor=* (first call), then use returned next_cursor
Anonymous: 10 requests/second, 100,000/day
With mailto: 100 requests/second, 1,000,000/day
All tools return the standard OpenAlex JSON envelope:
{
"meta": {
"count": 249256387,
"db_response_time_ms": 12,
"page": 1,
"per_page": 25,
"next_cursor": "ZjEwMD..."
},
"results": [
{
/* entity object */
}
]
}# Watch mode during development
npm run watch
# Test with MCP inspector
npm run inspector
# Run basic functionality test
node test-simple.jsThe server supports environment variables for configuration. Copy .env.example to .env and configure:
cp .env.example .env
# Edit .env with your settingsOPENALEX_BEARER_TOKEN: Bearer token for authenticated API access (optional)
OPENALEX_DEFAULT_EMAIL: Default email for rate limiting when no mailto parameter provided
Free Access: OpenAlex API is free and open
Rate Limits: 10 req/sec (anonymous) or 100 req/sec (with Bearer token or mailto)
Authentication: Bearer token automatically loaded from environment
Response Size: Use select parameter to limit response size for large datasets
Example with optimized response:
{
"tool": "search_works",
"arguments": {
"search": "machine learning",
"select": "id,display_name,publication_year,cited_by_count",
"per_page": 10
}
}OpenAlex is a fully open catalog of the global research system, named after the ancient Library of Alexandria and created by the nonprofit OurResearch. It provides free, comprehensive metadata about scholarly works, authors, institutions, and more.
Website: https://openalex.org/
API Documentation: https://docs.openalex.org/
Data sources: Crossref, ORCID, ROR, Microsoft Academic Graph, and more
Type ahead search across any OpenAlex entity type
| Name | Required | Description | Default |
|---|---|---|---|
| search | Yes | Search query for autocomplete | |
| type | No | Entity type to search within | |
| per_page | No | Number of suggestions (max 50) | |
| mailto | No | Email for rate limits | |
| api_key | No | Premium API key |
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 but offers minimal information. It mentions 'type ahead search' which implies real-time suggestions, but doesn't describe response format, rate limits (beyond the mailto parameter hint), error conditions, or performance characteristics. For a tool with 5 parameters and no output schema, 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 extremely concise at just 7 words, front-loading the core functionality with zero wasted language. Every word earns its place: 'Type ahead' establishes the interaction pattern, 'search' specifies the action, 'across any OpenAlex entity type' defines the scope. This is a model of efficiency in technical documentation.
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 complexity (5 parameters, no annotations, no output schema, multiple sibling alternatives), the description is insufficiently complete. While concise, it doesn't address key contextual questions: how results differ from full search tools, what the output format looks like, authentication requirements, or rate limiting behavior. The agent would need to guess or trial-error these aspects.
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 doesn't explicitly mention any parameters, though 'type ahead search' implies the 'search' parameter. With 100% schema description coverage, all parameters are well-documented in the schema itself, so the description doesn't need to compensate. The baseline score of 3 reflects adequate parameter documentation through the schema alone, though the description adds no additional semantic context.
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: 'Type ahead search across any OpenAlex entity type'. It specifies the verb ('search') and resource ('OpenAlex entity type'), making the function immediately understandable. However, it doesn't explicitly distinguish this autocomplete functionality from the various search_* sibling tools, which likely offer more comprehensive search capabilities.
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. With multiple search-related sibling tools (search_authors, search_works, etc.), there's no indication whether this is for quick suggestions versus full results, or what distinguishes it from get_entity for lookup operations. The agent must infer usage context from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify arbitrary text to predict research concepts and confidence scores
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Title text to classify | |
| abstract | No | Abstract text to classify | |
| mailto | No | Email for rate limits | |
| api_key | No | Premium API key |
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 'predict research concepts and confidence scores,' which implies a read-only analysis operation, but fails to disclose critical traits like authentication needs (e.g., 'api_key' usage), rate limits (implied by 'mailto'), or potential costs. This leaves significant gaps in understanding the tool's behavior and 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 a single, efficient sentence: 'Classify arbitrary text to predict research concepts and confidence scores.' It is front-loaded with the core purpose, uses clear language, and avoids unnecessary words. Every part of the sentence contributes directly to explaining the tool's function, making it highly concise and well-structured.
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 classification tool with 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the return format (e.g., structure of 'research concepts and confidence scores'), error handling, or how parameters like 'api_key' affect functionality. This leaves the agent with inadequate context for effective tool invocation and result interpretation.
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 100% description coverage, so parameters like 'title,' 'abstract,' 'mailto,' and 'api_key' are documented in the schema. The description adds no additional semantic details about these parameters, such as how 'title' and 'abstract' interact or why 'mailto' is needed for rate limits. This meets the baseline for high schema coverage but doesn't enhance understanding beyond the 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's purpose: 'Classify arbitrary text to predict research concepts and confidence scores.' It specifies the verb ('classify'), resource ('text'), and output type ('research concepts and confidence scores'), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'search_topics' or 'get_entity', which might have overlapping domains, so it doesn't achieve the highest 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 any context, prerequisites, or exclusions, such as when to prefer 'search_topics' for broader searches or 'get_entity' for specific entities. This lack of usage context leaves the agent without clear direction for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single entity by its OpenAlex ID
| Name | Required | Description | Default |
|---|---|---|---|
| entity_type | Yes | Type of entity to retrieve | |
| openalex_id | Yes | OpenAlex ID (e.g., W2741809807, A1969205038) | |
| select | No | Comma-separated list of fields to return | |
| mailto | No | Email for rate limits | |
| api_key | No | Premium API key |
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. It states this is a 'Get' operation but doesn't mention whether it's read-only, what happens with invalid IDs, rate limiting implications, authentication requirements, or response format. The description lacks crucial behavioral context for API interaction.
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 a single, efficient sentence that directly states the tool's purpose. It's front-loaded with the core functionality and contains no unnecessary words or redundant information. Every word earns its place in conveying the essential operation.
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?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address authentication needs (api_key), rate limiting (mailto), field selection (select), or what constitutes a valid OpenAlex ID format. The description leaves too many operational questions unanswered given the tool's complexity.
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 100%, so the schema already documents all 5 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. It mentions 'OpenAlex ID' which aligns with the openalex_id parameter but provides no additional semantic context. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Get') and resource ('a single entity'), specifying retrieval by OpenAlex ID. It distinguishes from sibling search tools by focusing on single entity lookup rather than searching. However, it doesn't explicitly differentiate from other potential get_* tools that might exist.
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 when to use get_entity versus the various search_* sibling tools, nor does it indicate prerequisites like needing an OpenAlex ID. The description assumes the user already knows they need to retrieve a specific entity by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of filterable field names and their types for a specified OpenAlex entity.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_type | Yes | The type of OpenAlex entity for which to retrieve filterable fields. |
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 what the tool does but lacks details on traits like whether it's read-only, its response format (e.g., list structure), potential rate limits, or error handling. For a tool with no annotations, this is a significant gap in transparency.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for its complexity, with zero waste, making it easy 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 complexity (metadata retrieval with no output schema) and lack of annotations, the description is incomplete. It does not explain the return values (e.g., format of the list, what 'types' entail) or behavioral aspects like idempotency. For a tool with no structured output information, more detail is needed to guide effective use.
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 100% description coverage, with the parameter 'entity_type' fully documented in the schema (including enum values). The description adds no additional meaning beyond what the schema provides, such as explaining why filterable fields vary by entity type or how the output relates to the parameter. Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('Get a list') and the resource ('filterable field names and their types for a specified OpenAlex entity'), making the purpose evident. However, it does not explicitly differentiate this tool from its siblings (e.g., search_* tools or get_entity), which focus on retrieving entities rather than metadata about filterable fields.
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 does not mention prerequisites, such as needing to know the entity type beforehand, or compare it to sibling tools like autocomplete or classify_text, which might serve related but different purposes in filtering or searching contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search authors and researchers
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Full-text search query | |
| filter | No | Key:value OpenAlex filters. Supports entity attributes (e.g., 'orcid', 'last_known_institution.id'), IDs, and convenience filters (e.g., 'display_name.search'). Example: 'has_orcid:true,last_known_institution.country_code:US' | |
| sort | No | Sort field with optional :desc | |
| page | No | Page number | |
| per_page | No | Results per page (max 200) | |
| cursor | No | Cursor for deep pagination | |
| group_by | No | Group results by field | |
| select | No | Fields to return | |
| sample | No | Random sample size | |
| seed | No | Random seed | |
| mailto | No | Email for rate limits | |
| api_key | No | Premium API key |
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 but offers minimal information. It doesn't mention rate limits (though 'mailto' parameter hints at them), authentication requirements (though 'api_key' parameter suggests premium access), pagination behavior, or what constitutes a successful search result. The description is too brief to adequately inform about the tool's operational characteristics.
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 extremely concise at just three words, with zero wasted language. It's front-loaded with the essential action and target. While it may be too brief for completeness, it earns full marks for conciseness as every word serves a clear purpose.
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?
For a complex tool with 12 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what constitutes a successful search, what format results return, how pagination works, or any behavioral constraints. The agent would need to infer much from the parameter descriptions alone, which is inadequate for a search tool of this complexity.
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 100% schema description coverage, the input schema already documents all 12 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
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 'Search authors and researchers' clearly states the verb (search) and resource (authors/researchers), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_entity' or 'autocomplete' which might also retrieve author information, so it doesn't achieve full sibling differentiation.
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. There are multiple sibling search tools (search_funders, search_institutions, etc.) and retrieval tools (get_entity, autocomplete), but the description offers no context about when this specific author search is appropriate versus other approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search funders
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Full-text search query | |
| filter | No | Key:value OpenAlex filters. Supports entity attributes (e.g., 'country_code', 'grants_count'), IDs, and convenience filters (e.g., 'display_name.search'). Example: 'country_code:DE,grants_count:>10' | |
| sort | No | Sort field with optional :desc | |
| page | No | Page number | |
| per_page | No | Results per page (max 200) | |
| cursor | No | Cursor for deep pagination | |
| group_by | No | Group results by field | |
| select | No | Fields to return | |
| sample | No | Random sample size | |
| seed | No | Random seed | |
| mailto | No | Email for rate limits | |
| api_key | No | Premium API key |
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 but provides none. It doesn't mention whether this is a read-only operation, what rate limits apply, what authentication is required, what the response format looks like, or any behavioral characteristics. For a search tool with 12 parameters, this complete lack of behavioral context is inadequate.
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 maximally concise at just two words. While this represents under-specification rather than ideal conciseness, according to the scoring framework, extremely brief descriptions that don't waste words receive high conciseness scores. Every word in 'Search funders' serves a purpose, even if that purpose is insufficient.
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 (12 parameters, no output schema, no annotations) and the presence of multiple sibling tools, the description is completely inadequate. It doesn't explain what a 'funder' is in this context, what the search returns, how results are structured, or any operational considerations. For a tool with this many configuration options and no structured behavioral annotations, the description fails to provide necessary 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?
The schema description coverage is 100%, meaning all 12 parameters are documented in the input schema itself. The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
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 'Search funders' is a tautology that restates the tool name without adding meaningful context. It doesn't specify what kind of search this performs (full-text, filtered, paginated) or what resources it searches through. While the name implies searching for funders, the description provides no additional clarification about scope or method.
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 absolutely no guidance about when to use this tool versus alternatives. With multiple sibling search tools available (search_authors, search_institutions, search_publishers, etc.), there's no indication that this tool is specifically for funder entities or how it differs from other search tools. No prerequisites, alternatives, or context for usage is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search institutions
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Full-text search query | |
| filter | No | Key:value OpenAlex filters. Supports entity attributes (e.g., 'ror', 'country_code', 'type'), IDs, and convenience filters (e.g., 'display_name.search'). Example: 'country_code:US,type:education' | |
| sort | No | Sort field with optional :desc | |
| page | No | Page number | |
| per_page | No | Results per page (max 200) | |
| cursor | No | Cursor for deep pagination | |
| group_by | No | Group results by field | |
| select | No | Fields to return | |
| sample | No | Random sample size | |
| seed | No | Random seed | |
| mailto | No | Email for rate limits | |
| api_key | No | Premium API key |
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 but offers none. It doesn't mention that this is a read-only operation, doesn't describe rate limits (though mailto and api_key parameters suggest they exist), doesn't explain pagination behavior beyond what's in the schema, and provides no information about response format, error conditions, or performance characteristics.
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?
While technically concise with just two words, this represents under-specification rather than effective brevity. The description fails to provide any of the necessary context that would help an AI agent understand when and how to use this tool. Every word should earn its place, but here the words don't provide meaningful value beyond the tool name itself.
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?
For a complex tool with 12 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what institutions are in this context, how results are returned, what the search capabilities are, or how this differs from other search tools. The agent would have to rely entirely on the parameter schema without any higher-level guidance about the tool's purpose and behavior.
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 schema description coverage is 100%, so all 12 parameters are documented in the schema itself. The description adds zero additional information about parameter usage, relationships, or semantics beyond what's already in the structured schema. This meets the baseline of 3 when the schema does all the parameter documentation work.
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 'Search institutions' is a tautology that merely restates the tool name without adding any meaningful clarification. It doesn't specify what 'search' entails (full-text, filtered, paginated) or what 'institutions' refers to in this context. While the name itself suggests searching educational or research institutions, the description fails to elaborate on scope or purpose beyond the obvious.
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 absolutely no guidance on when to use this tool versus the many sibling tools listed (search_authors, search_works, search_funders, etc.). There's no indication of what distinguishes institution searching from other entity searches, nor any context about when this tool would be appropriate versus alternatives like get_entity or autocomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search publishers
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Full-text search query | |
| filter | No | Key:value OpenAlex filters. Supports entity attributes (e.g., 'country_codes', 'hierarchy_level'), IDs, and convenience filters (e.g., 'display_name.search'). Example: 'country_codes:US,hierarchy_level:0' | |
| sort | No | Sort field with optional :desc | |
| page | No | Page number | |
| per_page | No | Results per page (max 200) | |
| cursor | No | Cursor for deep pagination | |
| group_by | No | Group results by field | |
| select | No | Fields to return | |
| sample | No | Random sample size | |
| seed | No | Random seed | |
| mailto | No | Email for rate limits | |
| api_key | No | Premium API key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers zero behavioral information beyond the basic 'search' action. With no annotations provided, the description carries full burden but fails to disclose any behavioral traits - no information about rate limits, authentication requirements (though api_key parameter hints at premium access), pagination behavior, or what the search actually returns. For a 12-parameter search tool with no annotations, this is completely inadequate.
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?
While technically concise with only two words, this represents under-specification rather than effective conciseness. The description fails to provide any meaningful information that would help an AI agent understand or use the tool. Every word should earn its place, but here the words don't provide sufficient value to justify their inclusion.
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?
For a complex search tool with 12 parameters, no annotations, and no output schema, the description is completely inadequate. It provides no information about what the tool returns, how results are structured, what 'search' actually means in this context, or any behavioral characteristics. The description fails to compensate for the lack of structured metadata, leaving significant gaps in 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?
With 100% schema description coverage, the input schema already provides comprehensive documentation for all 12 parameters. The description adds absolutely no parameter information beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.
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 'Search publishers' is a tautology that merely restates the tool name without adding any meaningful context. It lacks a specific verb-resource combination and doesn't distinguish this tool from its many search-related siblings (search_authors, search_funders, etc.). While it indicates the general domain (publishers), it fails to specify what kind of search this performs or what makes it unique.
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 absolutely no guidance about when to use this tool versus alternatives. With multiple sibling search tools (search_authors, search_funders, search_institutions, etc.), there's no indication that this tool is specifically for publishers or when one would choose it over other search tools. No context, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search journals and sources
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Full-text search query | |
| filter | No | Key:value OpenAlex filters. Supports entity attributes (e.g., 'issn', 'country_code', 'is_oa'), IDs, and convenience filters (e.g., 'display_name.search'). Example: 'is_oa:true,type:journal' | |
| sort | No | Sort field with optional :desc | |
| page | No | Page number | |
| per_page | No | Results per page (max 200) | |
| cursor | No | Cursor for deep pagination | |
| group_by | No | Group results by field | |
| select | No | Fields to return | |
| sample | No | Random sample size | |
| seed | No | Random seed | |
| mailto | No | Email for rate limits | |
| api_key | No | Premium API key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'search' but doesn't describe key behaviors: whether this is a read-only operation, rate limits (though 'mailto' parameter hints at this), pagination behavior, or what the output looks like. The description is minimal and fails to compensate for the lack of annotations.
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 extremely concise—just three words—with zero wasted text. It's front-loaded and efficiently states the core function. However, this conciseness comes at the cost of completeness, but for this dimension alone, it scores highly.
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 (12 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's scope, behavioral traits, or output format. While the schema covers parameters well, the description fails to provide necessary context for a search tool with many options and no structured output information.
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 100%, with detailed parameter descriptions in the input schema (e.g., 'Full-text search query' for 'search', 'Key:value OpenAlex filters' for 'filter'). The description adds no parameter-specific information beyond what's in the schema. According to rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
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 'Search journals and sources' states the action (search) and target resources (journals and sources), providing a basic purpose. However, it's vague about what 'sources' encompasses and doesn't distinguish this tool from sibling search tools like search_authors, search_works, etc., which all search different entity types. It lacks specificity about what makes this search unique.
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. With multiple sibling search tools (e.g., search_authors, search_works), there's no indication that this is for journals/sources specifically, nor any context about prerequisites or exclusions. Usage is implied by the name but not explicitly stated in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search research topics (formerly concepts)
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Full-text search query | |
| filter | No | Key:value OpenAlex filters. Supports entity attributes (e.g., 'domain.id', 'level'), IDs, and convenience filters (e.g., 'display_name.search'). Example: 'domain.id:D1,level:0' | |
| sort | No | Sort field with optional :desc | |
| page | No | Page number | |
| per_page | No | Results per page (max 200) | |
| cursor | No | Cursor for deep pagination | |
| group_by | No | Group results by field | |
| select | No | Fields to return | |
| sample | No | Random sample size | |
| seed | No | Random seed | |
| mailto | No | Email for rate limits | |
| api_key | No | Premium API key |
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. It only states the basic action ('Search research topics') without mentioning rate limits, authentication requirements (though api_key parameter hints at premium access), pagination behavior, or expected response format. For a search tool with 12 parameters, this is a significant gap in behavioral context.
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 extremely concise - a single parenthetical phrase that efficiently communicates the resource type and historical context ('formerly concepts'). Every word earns its place, and the information is front-loaded with no wasted verbiage.
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?
For a complex search tool with 12 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what constitutes a 'research topic', what fields are searchable, the expected return format, or how results are structured. The agent would need to infer much from parameter names alone.
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 schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 as 'Search research topics (formerly concepts)', which provides a specific verb ('Search') and resource ('research topics'). It distinguishes the resource type from siblings like search_authors or search_works, but doesn't explicitly differentiate functionality beyond 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?
The description provides no guidance on when to use this tool versus alternatives. While the resource type ('research topics') implicitly suggests usage for topic-related searches, there's no explicit mention of when to choose this over other search tools (like search_works for publications) or get_entity for specific topic retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search scholarly works in OpenAlex
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Full-text search query | |
| filter | No | Key:value OpenAlex filters. Supports entity attributes (e.g., 'publication_year', 'is_oa'), IDs, and convenience filters (e.g., 'title.search'). Example: 'is_oa:true,type:journal' | |
| sort | No | Sort field with optional :desc (e.g., 'cited_by_count:desc') | |
| page | No | Page number (max 10,000 results total) | |
| per_page | No | Results per page (max 200) | |
| cursor | No | Cursor for deep pagination (use '*' for first call) | |
| group_by | No | Group results by field for faceting | |
| select | No | Comma-separated list of fields to return | |
| sample | No | Random sample size | |
| seed | No | Random seed for reproducible sampling | |
| mailto | No | Email for rate limits | |
| api_key | No | Premium API key | |
| bearer_token | No | Bearer token for authentication | |
| view | No | The view of the data to return. 'summary' returns a concise version, 'full' returns the complete object. |
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 but only states the basic action without mentioning rate limits (implied by the 'mailto' parameter), authentication needs (implied by 'api_key' and 'bearer_token'), pagination behavior, or error handling. It fails to provide crucial operational context beyond the minimal purpose statement.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly while avoiding redundancy or fluff.
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 (14 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain return values, error conditions, or behavioral traits like rate limiting or authentication requirements. For a search tool with many parameters and no structured safety hints, more descriptive context is needed to guide effective use.
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 100% description coverage, thoroughly documenting all 14 parameters with examples and constraints. The description adds no parameter-specific information beyond what's already in the schema, so it meets the baseline of 3 for high schema coverage without compensating with additional semantic context.
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 action ('Search') and resource ('scholarly works in OpenAlex'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling search tools (search_authors, search_funders, etc.) beyond specifying 'works' as the target, which is good but not explicit about how it differs from other search tools in the same domain.
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 'get_entity' or other search tools for different entity types. It lacks explicit context about use cases, exclusions, or comparisons with sibling tools, leaving the agent to infer usage based on 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
autocompleteclassify_textget_entityget_filterable_fieldssearch_authorssearch_funderssearch_institutionssearch_publisherssearch_sourcessearch_topicssearch_worksEvery tool has a clearly distinct purpose with no ambiguity. The search tools target specific entity types (authors, funders, institutions, etc.), while get_entity, autocomplete, classify_text, and get_filterable_fields serve unique functions. An agent can easily distinguish between searching for works versus classifying text or getting filterable fields.
The tool names follow a highly consistent verb_noun pattern throughout. All search tools use 'search_' prefix followed by the entity type (e.g., search_authors, search_works), while other tools use clear verbs like get_entity, autocomplete, classify_text, and get_filterable_fields. There are no deviations in naming conventions.
With 11 tools, this server is well-scoped for interacting with the OpenAlex scholarly database. Each tool earns its place by covering distinct entity searches, entity retrieval, text classification, and metadata access. The count aligns with the domain's complexity without being overwhelming or insufficient.
The tool surface provides complete coverage for the OpenAlex domain. It includes search capabilities for all major entity types (works, authors, funders, institutions, publishers, sources, topics), direct entity retrieval via get_entity, utility functions like autocomplete and classify_text, and metadata access with get_filterable_fields. There are no obvious gaps that would hinder agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Access the OpenAlex academic research catalog — 270M+ publications.
Academic literature search, retrieval, and private library management on top of OpenAlex.
Scholarly search: OpenAlex, Crossref, arXiv, OpenCitations and PubMed in one endpoint.
OpenAlex MCP — wraps the OpenAlex API (scholarly works, free, no auth)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/reetp14/openalex-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
