Retrieves and provides Digital Object Identifiers (DOIs) for research papers, journal articles, and other academic works to ensure unique identification and linking.
Enables filtering and identification of scholarly works based on their open access status, supporting the discovery of freely available research.
Utilizes ORCID identifiers for high-accuracy author disambiguation and profile matching, allowing for precise identification of academic researchers.
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 Author Disambiguation MCP Server Find J. Abreu at EMBO and show their recent papers with citation counts."
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 streamlined Model Context Protocol (MCP) server for author disambiguation and academic research using the OpenAlex.org API. Specifically designed for AI agents with optimized data structures and enhanced functionality.
Advanced Author Disambiguation: Handles complex career transitions and name variations
Institution Resolution: Current and past affiliations with transition tracking
Academic Work Retrieval: Journal articles, letters, and research papers
Citation Analysis: H-index, citation counts, and impact metrics
ORCID Integration: Highest accuracy matching with ORCID identifiers
Streamlined Data: Focused on essential information for disambiguation
Fast Processing: Optimized data structures for rapid analysis
Smart Filtering: Enhanced filtering options for targeted queries
Clean Output: Structured responses optimized for AI reasoning
Multiple Candidates: Ranked results for automated decision-making
Structured Responses: Clean, parseable output optimized for LLMs
Error Handling: Graceful degradation with informative messages
Enhanced Filtering: Journal-only, citation thresholds, and temporal filters
MCP Best Practices: Built with FastMCP following official guidelines
Tool Annotations: Proper MCP tool annotations for optimal client integration
Resource Management: Efficient HTTP client management and cleanup
Rate Limiting: Respectful API usage with proper delays
Related MCP server: OpenAlex MCP Server
Python 3.10 or higher
MCP-compatible client (e.g., Claude Desktop)
Email address (for OpenAlex API courtesy)
For detailed installation instructions, see INSTALL.md.
Clone the repository:
git clone https://github.com/drAbreu/alex-mcp.git
cd alex-mcpCreate a virtual environment:
python3 -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activateInstall the package:
pip install -e .Configure environment:
export OPENALEX_MAILTO=your-email@domain.comRun the server:
./run_alex_mcp.sh
# Or, if installed as a CLI tool:
alex-mcpAdd to your Claude Desktop configuration file:
{
"mcpServers": {
"alex-mcp": {
"command": "/path/to/alex-mcp/run_alex_mcp.sh",
"env": {
"OPENALEX_MAILTO": "your-email@domain.com"
}
}
}
}Replace /path/to/alex-mcp with the actual path to the repository on your system.
You can load this MCP server in your OpenAI agent workflow using the agents.mcp.MCPServerStdio interface:
from agents.mcp import MCPServerStdio
async with MCPServerStdio(
name="OpenAlex MCP For Author disambiguation and works",
cache_tools_list=True,
params={
"command": "uvx",
"args": [
"--from", "git+https://github.com/drAbreu/alex-mcp.git@4.1.0",
"alex-mcp"
],
"env": {
"OPENALEX_MAILTO": "your-email@domain.com"
}
},
client_session_timeout_seconds=10
) as alex_mcp:
await alex_mcp.connect()
tools = await alex_mcp.list_tools()
print(f"Available tools: {[tool.name for tool in tools]}")This MCP server is specifically optimized for academic research workflows:
# Optimized for academic research workflows
from alex_agent import run_author_research
# Enhanced functionality with streamlined data
result = await run_author_research(
"Find J. Abreu at EMBO with recent publications"
)
# Clean, structured output for AI processing
print(f"Success: {result['workflow_metadata']['success']}")
print(f"Quality: {result['research_result']['metadata']['result_analysis']['quality_score']}/100")# Standard launch
uvx --from git+https://github.com/drAbreu/alex-mcp.git@4.1.0 alex-mcp
# With environment variables
OPENALEX_MAILTO=your-email@domain.com uvx --from git+https://github.com/drAbreu/alex-mcp.git@4.1.0 alex-mcpGet multiple author candidates using OpenAlex autocomplete API for intelligent disambiguation.
Parameters:
name (required): Author name to search (e.g., "James Briscoe", "M. Ralser")
context (optional): Context for disambiguation (e.g., "Francis Crick Institute developmental biology")
limit (optional): Maximum candidates (1-10, default: 5)
Key Features:
โก Fast: ~200ms response time
๐ฏ Smart: Multiple candidates with institutional hints
๐ง AI-Ready: Perfect for context-based selection
๐ Rich: Works count, citations, institution info
Streamlined Output:
{
"query": "James Briscoe",
"context": "Francis Crick Institute",
"total_candidates": 3,
"candidates": [
{
"openalex_id": "https://openalex.org/A5019391436",
"display_name": "James Briscoe",
"institution_hint": "The Francis Crick Institute, UK",
"works_count": 415,
"cited_by_count": 24623,
"external_id": "https://orcid.org/0000-0002-1020-5240"
}
]
}Usage Pattern:
# Get multiple candidates for disambiguation
candidates = await autocomplete_authors(
"James Briscoe",
context="Francis Crick Institute developmental biology"
)
# AI selects best match based on institutional context
# Much more accurate than single search result!Search for authors with streamlined output for AI agents.
Parameters:
name (required): Author name to search
institution (optional): Institution name filter
topic (optional): Research topic filter
country_code (optional): Country code filter (e.g., "US", "DE")
limit (optional): Maximum results (1-25, default: 20)
Streamlined Output:
{
"query": "J. Abreu",
"total_count": 3,
"results": [
{
"id": "https://openalex.org/A123456789",
"display_name": "Jorge Abreu-Vicente",
"orcid": "https://orcid.org/0000-0000-0000-0000",
"display_name_alternatives": ["J. Abreu-Vicente", "Jorge Abreu Vicente"],
"affiliations": [
{
"institution": {
"display_name": "European Molecular Biology Organization",
"country_code": "DE"
},
"years": [2023, 2024, 2025]
}
],
"cited_by_count": 316,
"works_count": 25,
"summary_stats": {
"h_index": 9,
"i10_index": 5
},
"x_concepts": [
{
"display_name": "Astrophysics",
"score": 0.8
},
{
"display_name": "Machine Learning",
"score": 0.6
}
]
}
]
}Features: Clean structure optimized for AI reasoning and disambiguation
Retrieve works for a given author with enhanced filtering capabilities.
Parameters:
author_id (required): OpenAlex author ID
limit (optional): Maximum results (1-50, default: 20)
order_by (optional): "date" or "citations" (default: "date")
publication_year (optional): Filter by specific year
type (optional): Work type filter (e.g., "journal-article")
authorships_institutions_id (optional): Filter by institution
is_retracted (optional): Filter retracted works
open_access_is_oa (optional): Filter by open access status
Enhanced Output:
{
"author_id": "https://openalex.org/A123456789",
"total_count": 25,
"results": [
{
"id": "https://openalex.org/W123456789",
"title": "A platform for the biomedical application of large language models",
"doi": "10.1038/s41587-024-02534-3",
"publication_year": 2025,
"type": "journal-article",
"cited_by_count": 42,
"authorships": [
{
"author": {
"display_name": "Jorge Abreu-Vicente"
},
"institutions": [
{
"display_name": "European Molecular Biology Organization"
}
]
}
],
"locations": [
{
"source": {
"display_name": "Nature Biotechnology",
"type": "journal"
}
}
],
"open_access": {
"is_oa": true
},
"primary_topic": {
"display_name": "Biomedical Engineering"
}
}
]
}Features: Comprehensive work data with flexible filtering for targeted queries
This MCP server provides focused, structured data specifically designed for AI agent consumption:
Identity Resolution: Names, ORCID, alternatives for disambiguation
Affiliation Tracking: Current and historical institutional connections
Impact Metrics: Citation counts, h-index, and scholarly impact
Research Context: Fields, concepts, and domain expertise
Career Analysis: Temporal affiliation changes and transitions
Publication Metadata: Title, DOI, venue, and publication details
Impact Assessment: Citation counts and scholarly influence
Access Information: Open access status and availability
Authorship Details: Complete author lists and institutional affiliations
Research Classification: Topics, concepts, and domain categorization
# Target high-impact journal articles
works = await retrieve_author_works(
author_id="https://openalex.org/A123456789",
type="journal-article", # Focus on journal publications
open_access_is_oa=True, # Open access only
order_by="citations", # Most cited first
limit=15
)
# Career transition analysis
authors = await search_authors(
name="J. Abreu",
institution="EMBO", # Current institution
topic="Machine Learning", # Research focus
limit=10
)from alex_mcp.server import search_authors_core
# Comprehensive author search
results = search_authors_core(
name="J Abreu Vicente",
institution="EMBO",
topic="Machine Learning",
limit=20
)
print(f"Found {results.total_count} candidates")
for author in results.results:
print(f"- {author.display_name}")
if author.affiliations:
current_inst = author.affiliations[0].institution.display_name
print(f" Institution: {current_inst}")
print(f" Metrics: {author.cited_by_count} citations, h-index {author.summary_stats.h_index}")
if author.x_concepts:
fields = [c.display_name for c in author.x_concepts[:3]]
print(f" Research: {', '.join(fields)}")from alex_mcp.server import retrieve_author_works_core
# Comprehensive work retrieval
works = retrieve_author_works_core(
author_id="https://openalex.org/A5058921480",
type="journal-article", # Academic focus
order_by="citations", # Impact-based ordering
limit=20
)
print(f"Found {works.total_count} publications")
for work in works.results:
print(f"- {work.title}")
if work.locations:
journal = work.locations[0].source.display_name
print(f" Published in: {journal} ({work.publication_year})")
print(f" Impact: {work.cited_by_count} citations")
if work.open_access and work.open_access.is_oa:
print(" โ Open Access")# Analyze career transitions
def analyze_career_path(author_result):
affiliations = author_result.affiliations
if len(affiliations) > 1:
print("Career path:")
for aff in sorted(affiliations, key=lambda x: min(x.years)):
years = f"{min(aff.years)}-{max(aff.years)}"
print(f" {years}: {aff.institution.display_name}")
# Research evolution
if author_result.x_concepts:
print("Research areas:")
for concept in author_result.x_concepts[:5]:
print(f" {concept.display_name} (score: {concept.score:.2f})")
# Usage
results = search_authors_core("Jorge Abreu Vicente")
if results.results:
analyze_career_path(results.results[0])# Required
export OPENALEX_MAILTO=your-email@domain.com
# Optional settings
export OPENALEX_MAX_AUTHORS=100 # Maximum authors per query
export OPENALEX_USER_AGENT=research-agent-v1.0
export ALEX_MCP_VERSION=4.1.0
# Rate limiting (respectful usage)
export OPENALEX_RATE_PER_SEC=10
export OPENALEX_RATE_PER_DAY=100000# For comprehensive research applications
config = {
"max_authors_per_query": 25, # Detailed author analysis
"max_works_per_author": 50, # Complete publication history
"enable_all_filters": True, # Full filtering capabilities
"detailed_affiliations": True, # Complete institutional data
"research_concepts": True # Detailed concept analysis
}alex-mcp/
โโโ src/alex_mcp/
โ โโโ server.py # Main MCP server
โ โโโ data_objects.py # Data models and structures
โ โโโ utils.py # Utility functions
โโโ examples/
โ โโโ basic_usage.py # Simple examples
โ โโโ advanced_queries.py # Complex query examples
โ โโโ integration_demo.py # AI agent integration
โโโ tests/
โ โโโ test_server.py # Server functionality tests
โ โโโ test_integration.py # Integration tests
โโโ docs/
โโโ api_reference.md # Detailed API documentation# Install test dependencies
pip install -e ".[test]"
# Run functionality tests
pytest tests/test_server.py -v
# Test with real queries
python examples/basic_usage.py
# Test AI agent integration
python examples/integration_demo.py# Test author disambiguation
python examples/basic_usage.py --query "J. Abreu" --institution "EMBO"
# Test work retrieval
python examples/advanced_queries.py --author-id "A123456789" --type "journal-article"
# Test integration patterns
python examples/integration_demo.py --workflow "career-analysis"Perfect integration with AI-powered research analysis:
# Enhanced academic research agent
from alex_agent import AcademicResearchAgent
agent = AcademicResearchAgent(
mcp_servers=[alex_mcp], # Streamlined data processing
model="gpt-4.1-2025-04-14"
)
# Complex research queries with structured data
result = await agent.research_author(
"Find J. Abreu at EMBO with machine learning publications"
)
# Rich, structured output for AI reasoning
print(f"Quality Score: {result.quality_score}/100")
print(f"Author disambiguation: {result.confidence}")
print(f"Research fields: {result.research_domains}")# Collaborative research analysis
async def research_collaboration_network(seed_author):
# Find primary author
authors = await alex_mcp.search_authors(seed_author)
primary = authors['results'][0]
# Get their works
works = await alex_mcp.retrieve_author_works(
primary['id'],
type="journal-article"
)
# Analyze co-authors and build network
collaborators = set()
for work in works['results']:
for authorship in work.get('authorships', []):
collaborators.add(authorship['author']['display_name'])
return {
'primary_author': primary,
'publication_count': len(works['results']),
'collaborator_network': list(collaborators),
'research_impact': sum(w['cited_by_count'] for w in works['results'])
}We welcome contributions to improve functionality and add new features:
Fork the repository
Create a feature branch: git checkout -b feature/enhanced-filtering
Add tests: Ensure your changes maintain data quality and structure
Submit a pull request: Include examples and documentation
Enhanced filtering capabilities
Additional data enrichment
Performance optimizations
Integration examples
Documentation improvements
This project is licensed under the MIT License. See LICENSE for details.
Enhanced autocomplete authors with intelligent filtering and ranking.
Args: name: Author name to search for (e.g., "James Briscoe", "M. Ralser") context: Optional context to help with disambiguation (e.g., "Francis Crick Institute developmental biology", "Max Planck Institute Kรถln Germany") limit: Maximum number of candidates to return (default: 10, max: 15) filter_no_institution: If True, exclude candidates with no institutional affiliation (default: True) enable_institution_ranking: If True, rank candidates by institutional context relevance (default: True)
Returns: dict: Serialized AutocompleteAuthorsResponse with filtered and ranked candidate authors, including: - openalex_id: Full OpenAlex author ID - display_name: Author's display name - institution_hint: Current/last known institution - works_count: Number of published works - cited_by_count: Total citation count - external_id: ORCID or other external identifiers - search_metadata: Information about filtering and ranking applied
Example usage: # Get high-quality candidates with institutional filtering candidates = await autocomplete_authors("Ivan Matiฤ", context="Max Planck Institute Biology Ageing Kรถln Germany")
# For seasoned researchers, institution hints and ranking help disambiguation
# AI can then select the best match or retrieve works for further verificationEnhanced Features: - Filters out candidates with no institutional affiliation (reduces noise) - Institution-aware ranking when context is provided (improves accuracy) - Higher default limit (10 vs 5) for better candidate coverage - Detailed logging for debugging and optimization
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| context | No | ||
| limit | No | ||
| filter_no_institution | No | ||
| enable_institution_ranking | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Get publications/works from an ORCID profile.
Args: orcid_id: ORCID identifier (e.g., "0000-0000-0000-0000" or full URL) max_works: Maximum number of works to retrieve (default: 20, max: 100)
Returns: dict: Publications data with: - orcid_id: Cleaned ORCID identifier - total_works: Number of works found - works: List of publications with titles, journals, DOIs, PMIDs
Example usage: # Get works for specific ORCID get_orcid_publications("0000-0000-0000-0000")
# Get limited number of works
get_orcid_publications("0000-0000-0000-0000", max_works=10)| Name | Required | Description | Default |
|---|---|---|---|
| orcid_id | Yes | ||
| max_works | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Get detailed author sample from PubMed with institutional information.
Args: author_name: Author name to search for (e.g., "Ivan Matic", "J Smith") sample_size: Number of recent works to analyze in detail (default: 5, max: 10)
Returns: dict: Author analysis including: - total_works: Total number of works found in PubMed - sample_works: Detailed information for sample works - institutional_keywords: Common institutional terms found - name_variants: Different name formats found - email_addresses: Email addresses extracted from affiliations
Example usage: # Get institutional profile for author pubmed_author_sample("Ivan Matic", sample_size=5)
| Name | Required | Description | Default |
|---|---|---|---|
| author_name | Yes | ||
| sample_size | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Enhanced MCP tool wrapper for retrieving author works with flexible filtering.
Args: author_id: OpenAlex Author ID (e.g., 'https://openalex.org/A123456789') limit: Maximum number of results (default: None = ALL works via pagination, max: 2000) order_by: Sort order - "date" for newest first, "citations" for most cited first publication_year: Filter by specific publication year type: Filter by work type (e.g., "journal-article", "letter") journal_only: If True, only return journal articles and letters (default: True) min_citations: Only return works with at least this many citations peer_reviewed_only: If True, apply balanced peer-review filters (default: True)
Returns: dict: Serialized OptimizedWorksSearchResponse with author's works.
Usage Patterns: # For AI validation (sample of high-impact works) retrieve_author_works(author_id, limit=20, order_by="citations")
# For complete benchmark evaluation (ALL works, minimal filtering)
retrieve_author_works(author_id, peer_reviewed_only=False, journal_only=False)
# For peer-reviewed works only (default behavior)
retrieve_author_works(author_id)| Name | Required | Description | Default |
|---|---|---|---|
| author_id | Yes | ||
| limit | No | ||
| order_by | No | date | |
| publication_year | No | ||
| type | No | ||
| journal_only | No | ||
| min_citations | No | ||
| peer_reviewed_only | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Optimized MCP tool wrapper for searching authors.
Args: name: Author name to search for. institution: (Optional) Institution name filter. topic: (Optional) Topic filter. country_code: (Optional) Country code filter. limit: Maximum number of results to return (default: 15, max: 100).
Returns: dict: Serialized OptimizedSearchResponse with streamlined author data.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| institution | No | ||
| topic | No | ||
| country_code | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Search ORCID for author profiles by name and affiliation.
Args: name: Author name to search (e.g., "John Smith", "Maria Garcia") affiliation: Optional institutional affiliation for disambiguation max_results: Maximum number of results to return (default: 10, max: 50)
Returns: dict: ORCID search results with: - total_found: Total number of matches found - results_returned: Number of results returned - results: List of author profiles with ORCID IDs, names, and affiliations
Example usage: # Basic name search search_orcid_authors("John Smith")
# Search with affiliation for better disambiguation
search_orcid_authors("Maria Garcia", "University of Barcelona")| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| affiliation | No | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Search PubMed database for publications.
Args: query: Search query (author name, DOI, title, or keywords) search_type: Type of search - "author", "doi", "title", or "keywords" (default: "author") max_results: Maximum number of results to return (default: 20, max: 50)
Returns: dict: Search results with PMIDs, article metadata, and summary statistics
Example usage: # Search for author search_pubmed("Ivan Matic", search_type="author", max_results=10)
# Search by DOI
search_pubmed("10.1038/nprot.2009.36", search_type="doi")
# Search by keywords
search_pubmed("ADP-ribosylation DNA repair", search_type="keywords")| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| search_type | No | author | |
| max_results | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Optimized MCP tool wrapper for searching works.
Args: query: Search query text author: (Optional) Author name filter institution: (Optional) Institution name filter publication_year: (Optional) Publication year filter type: (Optional) Work type filter (e.g., "article", "letter") limit: Maximum number of results (default: 25, max: 100) peer_reviewed_only: If True, apply peer-review filters (default: True) search_type: Search mode - "general" (title/abstract/fulltext), "title" (title only), or "title_and_abstract" (title and abstract only)
Returns: dict: Serialized OptimizedGeneralWorksSearchResponse with streamlined work data.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| author | No | ||
| institution | No | ||
| publication_year | No | ||
| type | No | ||
| limit | No | ||
| peer_reviewed_only | No | ||
| search_type | No | general |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v4.8.2autocomplete_authorsget_orcid_publicationspubmed_author_sampleretrieve_author_workssearch_authorssearch_orcid_authorssearch_pubmedsearch_worksThe 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Academic literature search, retrieval, and private library management on top of OpenAlex.
Access the OpenAlex academic research catalog โ 270M+ publications.
OpenAlex MCP โ wraps the OpenAlex API (scholarly works, free, no auth)
Scholarly search: OpenAlex, Crossref, arXiv, OpenCitations and PubMed in one endpoint.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/drAbreu/alex-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
