OpenAlex Author Disambiguation MCP Server

Server Quality Checklist

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

Latest release: v4.8.2
Disambiguation3/5
The tools have clear primary purposes but significant functional overlap exists. For example, autocomplete_authors, search_authors, and search_orcid_authors all search for authors by name, while search_pubmed and search_works both search publications. The descriptions help differentiate them (e.g., autocomplete_authors emphasizes filtering/ranking, search_orcid_authors focuses on ORCID profiles), but an agent could still misselect between similar tools without careful reading.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern throughout (e.g., autocomplete_authors, search_authors, retrieve_author_works). All tools use snake_case without deviation. The only minor inconsistency is that some tools include the data source in the name (e.g., search_orcid_authors, search_pubmed) while others do not, but this is reasonable given the domain.
Tool Count4/5
With 8 tools, the count is appropriate for an author disambiguation server. It covers multiple data sources (OpenAlex, ORCID, PubMed) and both author and publication search. The number feels slightly high due to overlapping tools, but each appears to serve a distinct use case within the domain, such as autocomplete for quick filtering versus detailed retrieval for validation.
Completeness4/5
The toolset provides comprehensive coverage for author disambiguation, including search, autocomplete, and retrieval from multiple sources (OpenAlex, ORCID, PubMed). Minor gaps exist, such as no direct tool for merging author profiles or updating disambiguation results, but core workflows (finding, verifying, and analyzing authors and their works) are well-supported. The tools allow agents to cross-reference data effectively.
Average 4/5 across 8 of 8 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, indicating a safe, open-ended search. The description adds context about being 'optimized' and 'streamlined,' but doesn't disclose behavioral traits like rate limits, performance characteristics, or what 'optimized' entails. It doesn't contradict annotations, but adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief purpose statement followed by organized parameter and return sections. It's appropriately sized, though the parameter details are somewhat verbose. Every sentence adds value, but the opening could be more front-loaded with key usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, 0% schema coverage), the description provides comprehensive parameter semantics. With output schema present, it needn't explain return values, and annotations cover safety. It lacks usage guidelines, but otherwise addresses most contextual needs for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing all 8 parameters, including optional status, defaults, and semantics (e.g., 'Search query text,' 'Author name filter,' 'Search mode'). It clarifies enums for search_type and boolean logic for peer_reviewed_only, adding significant meaning beyond the bare 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 as 'searching works' with the 'Optimized MCP tool wrapper' context. It specifies the resource ('works') and verb ('searching'), distinguishing it from sibling tools like search_authors or search_pubmed. However, it doesn't explicitly differentiate from retrieve_author_works, which might also retrieve works.
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 sibling tools like retrieve_author_works or search_pubmed, nor does it specify scenarios where this optimized search is preferred over other methods. Usage is implied through parameter descriptions but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, indicating safe, open-ended operations. The description adds context by specifying the return format (dict with orcid_id, total_works, works) and default/max values for max_works, which are useful beyond annotations. However, it doesn't disclose rate limits, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. It efficiently includes Args, Returns, and Example usage sections without redundancy. Every sentence adds value, such as clarifying parameter formats and providing practical examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, read-only operation) and the presence of an output schema, the description is largely complete. It covers purpose, parameters, and return structure adequately. However, it lacks usage guidelines compared to siblings, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It effectively explains both parameters: orcid_id as 'ORCID identifier' with examples, and max_works as 'Maximum number of works to retrieve' with default and max values. This adds clear meaning beyond the bare 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: 'Get publications/works from an ORCID profile.' It specifies the verb ('Get') and resource ('publications/works from an ORCID profile'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'retrieve_author_works' or 'search_works', which might have overlapping functionality.
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 sibling tools like 'retrieve_author_works' or 'search_works', nor does it specify prerequisites or contexts where this tool is preferred. The example usage only shows how to call it, not when.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, which the description doesn't contradict. The description adds useful context about the return format ('Serialized OptimizedSearchResponse with streamlined author data') and default/max values for limit parameter, which goes beyond what annotations provide. However, it doesn't mention rate limits, authentication needs, or pagination behavior.
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?
Well-structured with clear sections (Args, Returns). Every sentence adds value: the first establishes purpose, parameter descriptions are efficient, and return statement is specific. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations (readOnlyHint, openWorldHint) and an output schema exists, the description provides adequate context. It covers all parameters meaningfully and describes the return format. However, it could better differentiate from sibling tools and explain what 'optimized' means in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries full burden. It provides clear explanations for all 5 parameters including optional status, default values, and constraints (limit default:15, max:100). The description adds meaningful context about what each parameter filters, though it could provide more detail about format expectations (e.g., country_code format).
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 states it's for 'searching authors' which is clear but vague. It doesn't specify what makes this 'optimized' or how it differs from sibling tools like 'search_orcid_authors' or 'search_pubmed'. The description mentions 'streamlined author data' but doesn't clarify what that means compared to other search tools.
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?
No guidance on when to use this tool versus alternatives like 'search_orcid_authors', 'search_pubmed', or 'autocomplete_authors'. The description mentions it's 'optimized' but doesn't explain what optimization means or in what contexts it should be preferred over other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, indicating safe, open-ended operations. The description adds valuable behavioral context beyond this: it explains filtering logic (excludes candidates with no institutional affiliation), ranking behavior (institution-aware ranking with context), and performance details (higher default limit, detailed logging). This enhances understanding without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose but includes extensive sections (Args, Returns, Example usage, Enhanced Features) that, while informative, could be more streamlined. Some sentences, like 'AI can then select the best match or retrieve works for further verification,' are less essential. Overall, it's comprehensive but slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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, 0% schema coverage, no enums, no nested objects) and the presence of an output schema (detailed in Returns section), the description is highly complete. It covers purpose, parameters, behavioral traits, usage examples, and enhanced features, providing all necessary context for an AI agent to invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing all 5 parameters: 'name' (author name to search), 'context' (optional disambiguation context), 'limit' (max candidates with defaults), 'filter_no_institution' (exclusion logic), and 'enable_institution_ranking' (ranking toggle). It provides clear semantics, examples, and default values, adding significant value beyond the bare 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 performs 'enhanced autocomplete authors with intelligent filtering and ranking,' which is a specific verb+resource combination. It distinguishes from siblings like 'search_authors' by emphasizing disambiguation and filtering features. However, it doesn't explicitly contrast with all sibling tools like 'get_orcid_publications' or 'search_works'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through examples ('Get high-quality candidates with institutional filtering') and notes that 'For seasoned researchers, institution hints and ranking help disambiguation,' suggesting context-aware scenarios. However, it lacks explicit guidance on when to use this tool versus alternatives like 'search_authors' or 'search_orcid_authors,' leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, indicating safe read operations with open-world data. The description adds valuable context beyond annotations by specifying return format ('dict: Search results with PMIDs, article metadata, and summary statistics'), default values, and constraints (max_results: max 50). It doesn't contradict annotations and enhances behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Example usage) and front-loaded purpose. It's appropriately sized, but the example usage section is somewhat lengthy with three examples; one might suffice. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search with multiple parameters), annotations covering safety, and an output schema present (implied by 'Returns' section), the description is complete. It explains parameters thoroughly, provides return format details, includes examples, and doesn't need to duplicate output schema information. All essential context is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing all parameters: 'query' as search query with examples (author name, DOI, title, keywords), 'search_type' with enum values and default, and 'max_results' with default and max constraint. It adds comprehensive meaning beyond the bare schema, making parameters fully understandable.
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 PubMed database for publications,' which is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'search_authors' or 'search_works,' which appear to have overlapping functionality. The description is clear but lacks 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance through examples showing different search types (author, DOI, keywords), but it doesn't explicitly state when to use this tool versus alternatives like 'search_authors' or 'search_works.' There's no mention of prerequisites, exclusions, or comparative contexts with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with open-world assumptions. The description adds useful behavioral context beyond annotations by specifying the return format (dict with total_found, results_returned, results), default values (max_results: 10), and limits (max: 50), though it does not mention rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a clear purpose statement, followed by organized sections for Args, Returns, and Example usage. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, annotations covering safety, and an output schema (implied by 'Returns' section), the description is complete. It explains parameters, return values, and usage examples, providing sufficient context for an agent to invoke the tool correctly without needing to rely solely on structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It effectively adds meaning by explaining each parameter: 'name' as author name with examples, 'affiliation' for disambiguation, and 'max_results' with default and max values. However, it does not detail format constraints or edge cases for parameters beyond what's implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 with specific verb ('Search') and resource ('ORCID for author profiles'), distinguishing it from siblings like 'search_authors' or 'search_pubmed' by specifying the ORCID database and author profiles as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage (searching by name and affiliation for disambiguation) and includes an example with affiliation for better results. However, it does not explicitly state when to use this tool versus alternatives like 'search_authors' or 'autocomplete_authors', missing explicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, indicating safe read operations with external data. The description adds valuable behavioral context beyond annotations: it specifies the tool analyzes 'recent works' with a sample size limit (default:5, max:10), describes what information is extracted (institutional keywords, name variants, email addresses), and outlines the return structure. No contradiction with annotations exists.
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 well-structured and front-loaded with the core purpose, followed by organized sections for Args, Returns, and Example usage. Every sentence earns its place by providing essential information without redundancy, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analyzing author samples with institutional data), the description is complete: it covers purpose, parameters, return values, and usage example. With annotations covering safety and an output schema presumably detailing the return dict structure, the description provides all necessary contextual information without needing to explain technical output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics: it explains 'author_name' with examples ('Ivan Matic', 'J Smith') and 'sample_size' with default value, maximum limit, and purpose ('Number of recent works to analyze in detail'). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get detailed author sample from PubMed') and resource ('with institutional information'), distinguishing it from sibling tools like 'search_pubmed' or 'search_authors' by focusing on detailed analysis rather than basic search. The example usage reinforces this specific purpose of obtaining an institutional profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the example ('Get institutional profile for author') and parameter descriptions, but does not explicitly state when to use this tool versus alternatives like 'retrieve_author_works' or 'get_orcid_publications'. It provides clear input guidance but lacks explicit comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, but the description adds valuable context about pagination behavior ('ALL works via pagination'), maximum limit constraints ('max: 2000'), and the meaning of 'balanced peer-review filters'. It doesn't contradict annotations and provides operational details beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Usage Patterns) and front-loaded purpose statement. While comprehensive, every sentence adds value - no redundant information. The usage patterns section could be slightly more concise but effectively demonstrates practical applications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex parameter set (8 parameters), 0% schema coverage, and presence of output schema, the description provides complete context. It explains all parameters, demonstrates usage patterns, mentions behavioral constraints, and references the return type. The output schema handles return value documentation, so the description appropriately focuses on usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all 8 parameters with clear semantics: author_id format examples, limit behavior with pagination, order_by options, filter purposes, and default values. Each parameter's meaning and usage context is explicitly documented beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves author works with flexible filtering, specifying 'peer-reviewed only' in the title and description. It distinguishes from siblings like search_works by focusing specifically on author-centric retrieval rather than general search. The verb 'retrieve' with resource 'author works' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage patterns with three distinct scenarios: AI validation, complete benchmark evaluation, and default peer-reviewed behavior. It distinguishes when to use different parameter combinations and explicitly mentions when to disable default filters (peer_reviewed_only=False, journal_only=False) for alternative use cases.
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:

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

Score Badge

Copy to your README.md:

[![alex-mcp MCP server](https://glama.ai/mcp/servers/drAbreu/alex-mcp/badges/score.svg)](https://glama.ai/mcp/servers/drAbreu/alex-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/drAbreu/alex-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server