cern-opendata-mcp-server

Search CMS Trigger Paths

cern_opendata_search_trigger_paths

Read-onlyIdempotent

Look up CMS High-Level Trigger paths by exact name (HLT_IsoMu24) or prefix pattern (HLT_IsoMu*), optionally for one data-taking year. Paths outside the HLT_ family, such as AlCa_EcalPi0, DST_ and DQM_ paths, output modules and HLTriggerFinalPath, are found by their own names, in the case given. Each match is a per-year path record parsed into the primary datasets its title names, the first and last run the path was seen online, per-version run ranges, the L1 seed, and links to the HLT menu records. Covers CMS open data from 2011-2016. Prescale tables are not published.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number, from 1. page × limit may not exceed 10,000.
`path`	Yes	Trigger path name (HLT_IsoMu24, AlCa_EcalPi0) or prefix with one trailing wildcard (HLT_IsoMu): a letter or digit, then letters, digits and underscores. Trimmed. A path starting HLT_ in any case is searched as given, with the prefix case fixed, and matches path names in any case. Any other path is matched against record path names in the case given, the whole name or, with a trailing , its start (AlCa_EcalPi0, AlCa_), and is also searched with HLT_ prepended (IsoMu24 finds HLT_IsoMu24, 60Jet10 finds HLT_60Jet10). A trailing version suffix (_v3 or _v) is dropped, since records list versions as V<n>.
`year`	No	Data-taking year, such as 2012. Trigger records cover 2011-2016.
`limit`	No	Records per page, 1-50.

Output Schema

TableJSON Schema

Name	Required	Description
`cap`	No	The page size (limit) applied to this call.
`page`	No	The page returned.
`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.
`has_more`	No	True when the next page holds matches and lies within the first 10,000. False on the last reachable page even when more matches exist; truncated and notice say so.
`triggers`	No	Matching trigger path records on this page.
`truncated`	No	True when more results remain past this page; notice says how to reach them.
`totalCount`	No	Trigger path records matching the path (and year).
`effectiveQuery`	No	The query sent, after normalization (version suffix dropped): an HLT_ path as given; any other path as title clauses matching it as a record path name, OR HLT_ plus the path.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations declare read-only, idempotent, and open-world behavior, and the description adds significant matching and coverage details beyond them: case behavior, wildcard handling, dropped version suffixes, per-year records, run ranges, L1 seeds, and the 2011–2016 CMS open-data scope. It also discloses a real limitation: 'Prescale tables are not published.' No behavior contradicts the annotations.

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 dense but front-loaded, starting with the core lookup action and matching modes before covering exceptions, return record contents, and source limitations. Every sentence contributes domain-relevant information for a specialized search tool, with no filler.

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

Completeness5/5

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

Given the tool's domain complexity, the description is complete: it explains what is searched, how names and prefixes match, what a match record contains, the available year range, and a known data limitation. An output schema exists, so return-value structure need not be repeated in prose.

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 schema already documents all four parameters in detail, including path pattern rules, year range, and pagination limits. The description adds useful domain context about trigger-path naming but does not expand parameter syntax or semantics beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Look up CMS High-Level Trigger paths by exact name ... or prefix pattern.' It clearly distinguishes this tool from generic record or file searches by focusing on CMS HLT path records and naming the HLT_ family. An agent can identify the tool's narrow purpose without opening the 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?

The description gives clear context for when the tool applies: exact trigger-path names or prefix patterns, optional year filtering, and how non-HLT_ paths such as AlCa_EcalPi0 or DQM_ are handled. It does not explicitly compare this tool against siblings like cern_opendata_search_records, so it stops short of full alternative routing guidance.

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.