cern-opendata-mcp-server

Get CERN Open Data Analysis Environment

cern_opendata_get_analysis_env

Read-onlyIdempotent

Assemble what is needed to analyse a record: its container images, CMSSW release and global tag; the condition-data, VM and validated-run records for its run periods; example software that declares it works with the record; and quoted sections of the guides the record links (the first two are fetched). Container images, software and guide code are licensed separately from the CC0 data. Use cern_opendata_list_files for the record's files.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`recid`	Yes	Record id: up to 12 digits (6004), optionally after a lowercase experiment prefix (cms-93956). cern_opendata_search_records and cern_opendata_get_records return it.

Output Schema

TableJSON Schema

Name	Required	Description
`type`	No	Record type as the portal classifies it.
`error`	No	Present when the call failed. Absent on success.
`recid`	No	The record id.
`title`	No	Record title.
`guides`	No	Every portal guide linked in the usage section.
`notice`	No	What could not be assembled and how to get it: an empty environment, linked records that could not be read, guides not fetched, not found or cut, a guide anchor no heading carries, or more linked records than shown.
`software`	No	The record's own software environment (system_details).
`experiment`	No	Experiments the record belongs to.
`run_period`	No	Run periods the record covers, such as Run2012B.
`other_links`	No	The other usage links (getting-started pages and the like).
`license_note`	No	How the environment is licensed.
`example_software`	No	Software records that declare they work with this record.
`environment_records`	No	Condition, VM and validation records for the run periods, and others linking here.
`separately_licensed`	No	Always true: images, software and guide code are licensed apart from the CC0 data.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 18, 2026

changedInput schema / properties / recid / description

Previous value: -"Record id: up to 12 digits (6004), optionally after an experiment prefix (cms-93956); recid:6004 or a portal record URL also work. cern_opendata_search_records and cern_opendata_get_records return it."New value: +"Record id: up to 12 digits (6004), optionally after a lowercase experiment prefix (cms-93956). cern_opendata_search_records and cern_opendata_get_records return it."

addedOutput schema / properties / guides / items / properties / reference_definitions

Added value: +{
+  "description": "The guide's [label]: destination lines from outside the section whose label a [...] span of the section uses: verbatim, in body order, the first per label; a definition past a cut counts as outside. Empty when the section uses none; absent when the guide was not fetched.",
+  "items": {
+    "description": "One definition line, verbatim.",
+    "type": "string"
+  },
+  "type": "array"
+}

First observedOct 2, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so the safety profile is covered. The description still adds real behavioural nuance beyond them: only the first two guide sections are actually fetched, the result is an assembly of many linked record types, and container images, software and guide code carry licenses separate from the CC0 data.

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 purpose and component list are front-loaded in the first sentence, and the licensing caveat and the list_files redirect each earn their place. The middle sentence is a long semicolon-chained list and the licensing sentence sits between two operational points, which slightly hurts scanability.

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?

For a multi-source aggregation tool this is close to complete: it names what is collected, notes the guide-fetch cap, warns about licensing, and defers return-value detail to the existing output schema. The only gap is that it never states failure/partial-result behaviour when a linked record is missing.

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% and the single recid parameter is fully documented there, including its pattern and which sibling tools return it. The description adds nothing about the parameter, so the baseline 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?

States a specific verb and a well-defined aggregate resource (the analysis environment for a record) and then itemises the components: container images, CMSSW release and global tag, condition-data/VM/validated-run records, example software, and guide excerpts. That enumeration lets an agent distinguish it from the sibling read tools without opening any schema.

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?

Explicitly routes the agent away from this tool for record files: 'Use cern_opendata_list_files for the record's files.' It clearly signals the aggregation use case, but offers no guidance on when to prefer cern_opendata_get_records or the validated-run tool directly, so the sibling differentiation is only partial.

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

All cern-opendata-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.