What can you do with this server?

This MCP server enables searching, retrieving, and browsing documents from the CERN Document Server (CDS). * Search CDS documents (search_cds_documents): Search using keywords with optional filters for experiment (e.g., ATLAS, CMS, LHCb, ALICE), document type (e.g., Article, Thesis, Report), date ranges, sort order (most recent, best match, most cited), and result size (up to 100). * Get document details (get_cds_document_details): Retrieve full metadata for a specific document by its MCP ID (cds:123456), including the complete abstract, authors, and other metadata. * Get document files (get_cds_document_files): Fetch file information and direct download URLs for a specific document by its MCP ID. * List CERN experiments (get_cds_experiments): Browse common CERN experiments available as search filters. * List document types (get_cds_document_types): Browse available CDS document types to use as search filters. * Browse collections (list_cds_collections): Explore the hierarchical taxonomy of CDS collections and sub-collections to identify the correct search keys for filtering.

How do I use cds-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cds-mcp find recent papers from the ATLAS experiment" 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.

cds-mcp

by MohamedElashri

Overview Schema Related Servers Score Discussions

Python

Remote

CDS MCP Server

A Model Context Protocol (MCP) server for integrating with CERN Document Server (CDS), built on the Invenio digital library framework.

WARNING

As of July 28, 2026, CDS places its public search, export, API, and OAI routes behind an Anubis JavaScript proof-of-work challenge. Non-browser clients receive HTML instead of record data, so this MCP server cannot currently query CDS. The CDS team must provide a machine-accessible route or exempt the documented API routes before service can be restored.

Features

Search CDS documents with filters for experiments, document types, and date ranges
Get detailed document information including full abstracts, authors, and metadata
Access document files with download URLs and file metadata
Browse experiments and document types for better search filtering

Related MCP server: Primo MCP Server

Installation

Requires Python 3.10+.

Quickstart (recommended)

No installation needed, just use uvx to run directly:

uvx cds-mcp

From PyPI

pip install cds-mcp

From source

git clone https://github.com/MohamedElashri/cds-mcp
cd cds-mcp
uv sync

Usage

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "cds": {
      "command": "uvx",
      "args": ["cds-mcp"]
    }
  }
}

Note for macOS users: If you see an error about uvx not being found, you may need to provide the absolute path. Claude Desktop does not support ~ or $HOME expansion.

Run which uvx in your terminal to find the path (e.g., /Users/yourusername/.local/bin/uvx).
Use that absolute path in the command field:

"command": "/Users/yourusername/.local/bin/uvx"

Claude Code

Project-specific (default) — installs in the current directory's configuration:

claude mcp add cds-mcp -- uvx cds-mcp

Global — installs for your user account (works in all projects):

claude mcp add --scope user cds-mcp -- uvx cds-mcp

Manual Configuration — you can also manually edit your global config at ~/.claude.json (on Linux/macOS) or %APPDATA%\Claude\claude.json (on Windows):

{
  "mcpServers": {
    "cds": {
      "command": "uvx",
      "args": ["cds-mcp"]
    }
  }
}

GitHub Copilot

Add to your VS Code settings.json:

{
  "mcp": {
    "servers": {
      "cds": {
        "command": "uvx",
        "args": ["cds-mcp"]
      }
    }
  }
}

Or add a .vscode/mcp.json to your project:

{
  "servers": {
    "cds": {
      "command": "uvx",
      "args": ["cds-mcp"]
    }
  }
}

Gemini CLI

Add to your ~/.gemini/settings.json:

{
  "mcpServers": {
    "cds": {
      "command": "uvx",
      "args": ["cds-mcp"]
    }
  }
}

Direct usage

# Run with uvx (no install needed)
uvx cds-mcp

# Or if installed from PyPI
cds-mcp

# Or from source
uv run cds-mcp

Authentication & Access Control

CDS does not document an API key or OIDC audience for its legacy /search JSON endpoint. Although this repository contains experimental CERN OIDC client-credentials code, obtaining a token does not authenticate a request to CDS: API-access tokens require a target audience that accepts the token, and a client-credentials token represents an application identity rather than the CERN user whose experiment memberships grant access to restricted records.

Do not create a Personal API request or OIDC application for this server until CDS Support confirms:

The supported machine-to-machine endpoint and authentication scheme.
The exact OIDC audience, if bearer tokens are supported.
Whether access to restricted records requires a user-delegated flow.
Which API paths are exempt from the Anubis browser challenge.

Tools

search_cds_documents: Search CDS with various filters
get_cds_document_details: Get detailed information about a specific document
get_cds_document_files: Get file information and download URLs
get_cds_experiments: List available CERN experiments for filtering
get_cds_document_types: List available document types for filtering

Development

git clone https://github.com/MohamedElashri/cds-mcp
cd cds-mcp
uv sync
uv run python tests/test_integration.py  # Test real CDS API integration
uv run python tests/test_mcp_server.py   # Test MCP server functionality

License

MIT License - see LICENSE for details.

Available Tools

6 tools

get_cds_document_detailsA

Get detailed information about a specific CDS document including full abstract, authors, and metadata

ParametersJSON Schema

Name	Required	Description	Default
`mcp_id`	Yes	MCP ID of the document (format: 'cds:123456')

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description partially covers behavioral aspects by listing the types of information returned. However, it omits details such as potential errors (e.g., document not found), access restrictions, or rate limits. The description is adequate but not comprehensive.

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, well-structured sentence that front-loads the tool's purpose. Every word contributes value, and there is no redundancy or extraneous 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 no output schema, the description effectively lists the key content elements (abstract, authors, metadata). However, it misses potential context such as how document details might vary by type or whether the tool handles missing IDs gracefully.

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 already fully describes the parameter mcp_id with its format. The description does not add any additional meaning or context beyond the schema, so baseline score of 3 applies.

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 explicitly states the verb 'Get', the resource 'CDS document', and includes specifics like abstract, authors, and metadata. This clearly distinguishes it from sibling tools such as get_cds_document_files and search_cds_documents.

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 exclusions, prerequisites, or when another sibling tool might be more appropriate, leaving the agent without selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_cds_document_filesB

Get file information and download URLs for a specific CDS document

ParametersJSON Schema

Name	Required	Description	Default
`mcp_id`	Yes	MCP ID of the document (format: 'cds:123456')

TDQS

B3.1/5.0

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. It only states the basic function without disclosing behavior such as what happens if the document has no files, any permissions required, or whether the URLs expire. The description is too minimal.

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, concise sentence that directly states the tool's purpose. No unnecessary words or details, making it efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is incomplete given the lack of an output schema. It mentions 'file information and download URLs' but does not specify the structure or format of the return value. For a tool with one parameter, some additional detail on the output would improve completeness.

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 coverage for the sole parameter mcp_id is 100%, and its description in the schema is clear. The tool description does not add additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 retrieves 'file information and download URLs' for a specific CDS document, using a specific verb 'get'. However, it does not explicitly differentiate from sibling tools like get_cds_document_details, which likely also provide information about a document.

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 is provided on when to use this tool versus alternatives such as get_cds_document_details or search_cds_documents. The description does not mention context or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_cds_document_typesA

Get a list of common CDS document types that can be used for filtering searches

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/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. It clearly states it returns a list of common document types, implying a read-only operation. No contradictions.

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?

A single, clear sentence with no extraneous words. Efficient and to the point.

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 simplicity (no parameters, no output schema), the description is fully complete. It explains the output and its utility.

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 tool has no parameters and schema coverage is 100%. The description does not add parameter-specific information, but none is needed. Baseline score of 3 is appropriate.

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 uses a specific verb 'Get' and resource 'common CDS document types', clearly distinguishing it from sibling tools like get_cds_document_details or search_cds_documents. It states the purpose directly.

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 states the use case: for filtering searches. While it doesn't explicitly say when not to use, the sibling tool names imply alternative functionalities. It provides good context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_cds_experimentsA

Get a list of common CERN experiments that can be used for filtering searches

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It describes a simple read operation with no side effects, but lacks details like caching or update frequency.

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 immediately conveys the tool's function with no extraneous 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?

The tool has no parameters and no output schema, but the description gives enough context for a simple list retrieval. Some detail on output format could improve completeness.

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 no parameters and 100% schema coverage, the description adds value by explaining the purpose (list of common experiments for filtering) beyond the empty 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 tool retrieves a list of experiments for filtering, setting it apart from siblings that handle document details, files, types, and searching.

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 as a preparatory step for filtering searches, though it does not explicitly exclude other uses or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_cds_collectionsA

Browse the hierarchical taxonomy of CERN Document Server (CDS) collections and sub-collections. Use this tool BEFORE searching if you are unsure which collection or category to search in. It returns the exact search keys that can be passed into the doc_type argument of search_cds_documents.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It reveals that the output consists of search keys for another tool, but does not explicitly state that it is a read-only operation or other behavioral traits. While helpful, it is not fully transparent about side effects or safety.

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 only two sentences, both tightly packed with essential information. The first sentence states the purpose, and the second provides usage guidance. No unnecessary words.

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?

The tool is simple (no parameters, no output schema). The description fully explains what it returns (hierarchical taxonomy and search keys for a sibling tool) and when to use it. It is complete for the tool's complexity.

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?

The tool has no parameters (input schema is empty), so the baseline per instructions is 4. The description does not need to add parameter info, but it does not contradict or repeat schema information. No further value is needed.

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 'browses the hierarchical taxonomy of CERN Document Server (CDS) collections and sub-collections', which is a specific verb+resource. It distinguishes from siblings by explicitly mentioning its relationship to 'search_cds_documents' and providing the resulting search keys for that tool.

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 explicitly states when to use the tool ('BEFORE searching if you are unsure which collection or category to search in') and what it returns ('exact search keys that can be passed into the doc_type argument of search_cds_documents'). This provides clear guidance on usage and how it relates to an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_cds_documentsA

Search CDS documents with various filters including experiment, document type, and date range

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query string (required)
`experiment`	No	Filter by experiment (e.g., 'ATLAS', 'CMS', 'LHCb', 'ALICE')
`doc_type`	No	Filter by document type (e.g., 'Article', 'Thesis', 'Report')
`from_date`	No	Start date filter in YYYY-MM-DD format
`until_date`	No	End date filter in YYYY-MM-DD format
`size`	No	Number of results to return (max 100, default 10)
`sort`	No	Sort order: 'mostrecent', 'bestmatch', or 'mostcited'	mostrecent

TDQS

A3.5/5.0

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. It does not disclose behavioral traits such as authentication requirements, rate limits, pagination behavior, or what happens when no results are found. The description only states the basic search function.

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 sentence that is appropriately sized and front-loaded with the verb 'Search'. Every word is necessary and adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 7 parameters and no output schema or annotations, the description covers the main purpose and filter types adequately. However, it lacks details on sorting, size limits, default behavior, and result format. It is adequate but has clear gaps.

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 baseline is 3. The description adds marginal value by summarizing filter types (experiment, document type, date range) but these are already detailed in the schema. It does not explain parameter interactions or constraints beyond the 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 verb 'Search' and the resource 'CDS documents', and lists specific filters (experiment, document type, date range). It distinguishes from sibling tools like get_cds_document_details which focus on retrieving details of a single document.

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 for searching with filters but provides no explicit guidance on when to use this tool versus alternatives like get_cds_document_details or list_cds_collections. No 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.2May 29, 2026
- First observedget_cds_document_details
- First observedget_cds_document_files
- First observedget_cds_document_types
- First observedget_cds_experiments
- First observedlist_cds_collections
- First observedsearch_cds_documents

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool has a distinct purpose: details, files, filter lists (types and experiments), collection browsing, and searching. No overlap exists.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_cds_document_details, search_cds_documents), making them predictable.

Tool Count5/5

With 6 tools, the set is well-scoped for a read-only document server API, covering search, retrieval, and exploration without excess.

Completeness5/5

The tool surface covers core operations: searching with filters, retrieving details and files, browsing taxonomy, and accessing filter options. No obvious gaps for the stated domain.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

RU Books MCP
io.github.books-service
MCP server for Russian books search, details, and recommendation candidates.
Search Art & Culture Entertainment & Media
2
Fcc Ecfs A
io.github.pipeworx-io
MCP server for fcc-ecfs
Government Data Open Data
352
FirstData
io.github.Vist233
Hosted MCP server for finding authoritative primary data sources and official portals.
Search Open Data Government Data
2144
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102

Related MCP Servers

mcp-zenodo
Research & Data Open Data
MSKazemi
A
license
A
quality
C
maintenance
A comprehensive MCP server for interacting with Zenodo records, enabling search, retrieval, citation generation, and file downloads.
Updated 2 months ago (2026-07-01 23:23 UTC)
5
6
Apache 2.0
Primo MCP Server
Research & Data Search
geheharidas
A
license
A
quality
D
maintenance
MCP server for searching Ex Libris Primo library catalogues and subscribed databases, enabling search, record retrieval, autocomplete, citation generation, and export to BibTeX, RIS, or CSV.
Updated 5 months ago (2026-04-08 09:05 UTC)
5
7
MIT
arxiv-reader-mcp
Research & Data Search
Sulcate-whipcord611
A
license
A
quality
C
maintenance
MCP server for searching and retrieving arXiv papers with full-text PDF extraction.
Updated 16 hours ago (2026-09-06 04:13 UTC)
5
2
MIT
zenodo-mcp
Research & Data Open Data AI & Machine Learning
Agostynah
A
license
A
quality
C
maintenance
An MCP server for discovering, retrieving, citing, and evaluating scientific records from the Zenodo repository.
Updated 2 months ago (2026-07-17 04:21 UTC)
18
MIT

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/MohamedElashri/cds-mcp'

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