cern-opendata-mcp-server

Get CMS Validated Runs

cern_opendata_get_validated_runs

Read-onlyIdempotent

Get a CMS validated-run (good-run) list, which certifies the luminosity sections that are good for physics in each run. Select it by a CMS collision dataset recid, a validated-run list recid, or a run period such as Run2012B (give exactly one of recid and run_period). Choose the full validation or the muons-only variant, and narrow to a run range; a dataset recid defaults the range to the first and last run the dataset lists. Returns the runs with their luminosity-section ranges and the list file download URL. CMS only.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Runs to return, 1-2000. A value above 2000 is served at 2000.
`recid`	No	A CMS collision dataset recid (its linked list is used) or a validated-run list recid (used as named): up to 12 digits, optionally after a lowercase experiment prefix (cms-93956). Give this or run_period.
`run_max`	No	Highest run to return, inclusive. Defaults with run_min for a dataset recid.
`run_min`	No	Lowest run to return, inclusive. With a dataset recid and neither bound set, run_min and run_max default to the first and last run the dataset lists; run_bounds echoes the range applied.
`variant`	No	full (every detector certified) or muons_only (certified for muon physics). Omitted: a list recid is used as named; a dataset recid or run_period selects full.
`run_period`	No	A CMS run period such as Run2012B, matched case-insensitively; 2012B also matches Run2012B. Give this or recid. cern_opendata_list_reference with topic run_periods lists them.

Output Schema

TableJSON Schema

Name	Required	Description
`cap`	No	The page size (limit) applied to this call.
`list`	No	The selected list, when exactly one matched.
`runs`	No	Certified runs, ascending, inside run_bounds and cut at limit; empty when no single list was selected.
`error`	No	Present when the call failed. Absent on success.
`shown`	No	Number of items returned on this page.
`notice`	No	Guidance for the next call: how to page on, why nothing matched and what to change, or a caveat about the results.
`dataset`	No	The dataset, when recid named a dataset rather than a list.
`summary`	No	The whole selected list, before run_bounds.
`truncated`	No	True when more results remain past this page; notice says how to reach them.
`run_bounds`	No	The run range runs was filtered to; absent when no bound applies.
`totalCount`	No	Runs in the selected list inside run_bounds.
`matched_lists`	No	Every list the selector matched in the requested variant. Several means none was read: call again with recid set to one of them.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 18, 2026

changedInput schema / properties / limit / description

Previous value: -"Runs to return, 1-2000."New value: +"Runs to return, 1-2000. A value above 2000 is served at 2000."

changedInput schema / properties / limit / maximum
```
Previous value: -2000New value: +10000
```

changedInput schema / properties / recid / description

Previous value: -"A CMS collision dataset recid (its linked list is used) or a validated-run list recid (used as named): up to 12 digits, optionally after an experiment prefix (cms-93956); recid:N or a portal record URL also work. Give this or run_period."New value: +"A CMS collision dataset recid (its linked list is used) or a validated-run list recid (used as named): up to 12 digits, optionally after a lowercase experiment prefix (cms-93956). Give this or run_period."

First observedOct 2, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, so the safety profile is covered. The description adds real behavioral context beyond them: the dataset-recid default range, the variant resolution rules when omitted, and the CMS-only constraint. It stops short of noting rate limits or how the returned list file is served, so not a 5.

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?

A single front-loaded paragraph where the resource comes first and the selection constraints follow. It is dense but each clause carries a distinct rule; a slight trim of the return-value sentence (since an output schema exists) would improve it.

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?

For a filter-heavy, zero-required-param retrieval tool with a full schema and an output schema, the description supplies everything an agent needs: how to select, mutual exclusion, defaults, variant semantics, and scope. Return-value detail is redundant given the output schema but harmless.

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 coverage is 100%, so the schema baseline already documents all six parameters. The description nonetheless adds selection semantics the schema only implies: recid-vs-run_period exclusivity, dataset-recid range defaults, and variant fallback behavior. Marginal but genuine added value over the structured fields.

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 resource ('Get a CMS validated-run (good-run) list') and immediately explains what the artifact certifies (luminosity sections good for physics). It is clearly distinguishable from the search/list/records siblings, and the 'CMS only' scope note removes ambiguity about domain.

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?

Gives explicit selection rules: 'give exactly one of recid and run_period', how to choose full vs muons_only, how to narrow to a run range, and routes the agent to a named sibling (cern_opendata_list_reference) for enumerating run periods. Mutual-exclusion and defaults are stated rather than left to inference.

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.