OpenAlex MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Every 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 2.6/5 across 11 of 11 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness2/5
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.
Completeness1/5
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.
Parameters3/5
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.
Purpose2/5
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.
Usage Guidelines1/5
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.
Behavior1/5
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.
Conciseness2/5
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.
Completeness1/5
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.
Parameters3/5
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.
Purpose2/5
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.
Usage Guidelines1/5
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.
Behavior1/5
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.
Conciseness5/5
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.
Completeness1/5
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.
Parameters3/5
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.
Purpose2/5
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.
Usage Guidelines1/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![openalex-mcp MCP server](https://glama.ai/mcp/servers/reetp14/openalex-mcp/badges/card.svg)](https://glama.ai/mcp/servers/reetp14/openalex-mcp)

Score Badge

Copy to your README.md:

[![openalex-mcp MCP server](https://glama.ai/mcp/servers/reetp14/openalex-mcp/badges/score.svg)](https://glama.ai/mcp/servers/reetp14/openalex-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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