Search CERN Open Data, fetch records, files, analysis environments, CMS good-run lists, HLT paths.
Scored across 7 tools
Each tool targets a clearly distinct task: metadata retrieval, full-text/faceted search, file listing, vocabulary decoding, validated-run lookup, HLT trigger-path lookup, and analysis-environment assembly. Boundaries are explicit (e.g. get_records defers file lists to list_files), so an agent can pick the right tool without guesswork.
All seven tools share the cern_opendata_ prefix followed by a consistent verb_noun pattern (get_records, get_validated_runs, get_analysis_env, list_files, list_reference, search_records, search_trigger_paths). No mixing of conventions.
Seven tools is well-scoped for a data-portal domain; each tool earns its place (search, retrieve, files, reference, runs, triggers, environment) with no redundancy or thin single-tool gaps.
The surface covers the full lifecycle: discovery (search_records, list_reference), retrieval (get_records), payload access (list_files with download URLs), and domain-specific needs (validated_runs, trigger_paths, analysis_env). Cross-tool handoffs (menu_recid, file indexes, deferred ids) close what would otherwise be dead ends.
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.
| 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. |
| 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. |
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.
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.
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.
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.
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.
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.
Fetch full metadata for 1-20 records in one call, by recid, DOI, CMS dataset path (/Primary/Era/TIER) or documentation slug. Returns the description, run periods, collision and distribution details, related records, a software-environment summary, the license and a ready citation, plus what a record states of its variable dictionary, physics category, pile-up, keywords, and LHCb magnet polarity and stripping. Documentation and news pages include their markdown body in slices of at most 30,000 characters; body_offset with that one id reads on from where a slice stops. Each response holds to 64,000 bytes, except that the first record always comes back whole: records past the budget, and ids past the first 20, are listed under deferred, to pass back as ids. File lists are not included; use cern_opendata_list_files. Identifiers that do not resolve come back under missing with guidance; they do not fail the call.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Identifiers to resolve: up to 100, of which the first 20 distinct are looked up and the rest returned under deferred. Forms may be mixed; exact duplicates collapse. | |
| body_offset | No | With exactly one documentation or news id: where its body slice starts, in characters (UTF-16 code units), usually the body_next_offset an earlier call returned. 0 (the default) is the body's start and is accepted with any ids; above 0 needs exactly one id. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Caveats about the returned records: a documentation body with more to read, records deferred by the response budget, or ids past the first 20 that were not looked up, each with the call that continues it. |
| missing | No | Identifiers that resolved to no record; empty when every id resolved. |
| records | No | Resolved records, in the order of their first matching input. |
| deferred | No | Inputs left for another call, in input order: those whose records were left out to hold the response to 64,000 bytes (never the first record, which is returned whole even when larger), then ids past the first 20, which were not looked up. Pass them as ids to fetch them. Empty when nothing was left out. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/idempotent/openWorld; the description adds substantial non-obvious behavior: an effective 20-id lookup ceiling, 64,000-byte response budget, the guarantee that the first record is always returned whole, deferral of over-budget records/ids, non-resolving ids surfacing under 'missing' rather than failing, and 30,000-character body slicing. This is well beyond what the annotations convey and is consistent with 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?
Purpose and identifier forms are front-loaded, and nearly every sentence carries substantive constraints. However, the long nested clause stringing together returned fields is dense and slightly harder to parse than it needs to be, keeping it short of a 5.
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?
For a complex batch-fetch tool with an output schema, the description still covers everything an agent needs to call it correctly — accepted id forms, batch ceiling, pagination via body_offset, response-size handling, and error semantics. Nothing material is left to inference.
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 100%, so baseline is 3, but the description adds meaning the schema does not: the first-20-distinct lookup rule, duplicate collapsing, and the precise interaction of body_offset with a single documentation/news id. The only tension is '1-20 records in one call' versus the schema's maxItems of 100, which the deferred sentence partly reconciles.
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?
States a specific verb and resource ('Fetch full metadata for ... records'), enumerates the four accepted identifier forms (recid, DOI, CMS dataset path, documentation slug), and explicitly contrasts itself with a sibling ('File lists are not included; use cern_opendata_list_files'). An agent can distinguish this from get/search siblings 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing for one sibling ('use cern_opendata_list_files') and states the condition that governs body_offset ('with that one id reads on from where a slice stops'). It does not explicitly contrast against cern_opendata_search_records, so the when-not-this-tool story is only partial, but usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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. |
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.
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.
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.
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.
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.
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.
List one record's files: its file indexes (groups of up to ~1,500 files) with their XRootD URI-list URLs, and per file the XRootD URI, HTTPS download URL, size, adler32 checksum and availability. Without index, returns the record's indexes and its regular files; with index, reads only that index and pages through its files. Files marked on demand sit on tape and must be requested on the record's portal page before download.
| Name | Required | Description | Default |
|---|---|---|---|
| index | No | A file index key from the indexes list, matched exactly (a .txt ending is read as .json). Omit to list the record's indexes and regular files. | |
| limit | No | Files per page, 1-500. A value above 500 is served at 500. | |
| recid | Yes | Record id: up to 12 digits (6004), optionally after a lowercase experiment prefix (atlas-160006). cern_opendata_search_records and cern_opendata_get_records return it. | |
| cursor | No | next_cursor from the previous page, unchanged, with the same recid and index. Omit for the first page. |
| Name | Required | Description |
|---|---|---|
| cap | No | The page size (limit) applied to this call. |
| error | No | Present when the call failed. Absent on success. |
| files | No | This page of files: regular files in record scope, the index's files in index scope. |
| recid | No | The record id. |
| scope | No | record: the record's indexes and regular files; index: one index's files. |
| shown | No | Number of items returned on this page. |
| title | No | Record title. |
| notice | No | Guidance for the next call: how to page on, why nothing matched and what to change, or a caveat about the results. |
| indexes | No | Every file index in record scope; only the selected one in index scope. |
| children | No | Set only for an umbrella record holding no files itself: the child recids whose files make it up. Empty otherwise. |
| has_more | No | True when more files remain past this page. |
| truncated | No | True when more results remain past this page; notice says how to reach them. |
| portal_url | No | The record page, where on-demand (tape) files are requested. |
| totalCount | No | Files in scope: regular files in record scope, index files in index scope. |
| next_cursor | No | Pass as cursor, with the same recid and index, for the next page. |
| availability | No | Record-level availability: online, partial, ondemand or requested. |
| availability_details | No | File counts by availability state for the whole record. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only/idempotent/open-world safety, and the description adds real operational context: indexes group up to ~1,500 files, results are paged, and on-demand files are tape-resident and require a portal request before download. That tape caveat is exactly the kind of prerequisite the annotations cannot express.
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?
Three sentences, front-loaded with the core action and result fields, then the index/no-index branch, then the tape caveat. Dense but every clause carries operational information; the first sentence is somewhat long, so not maximally tight.
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?
For a 4-parameter read tool with an output schema present, the description supplies everything an agent needs: what is returned, how index toggles the result set, paging behavior, and the on-demand download precondition. Return-value detail need not be duplicated since an output schema exists.
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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the semantic effect of index (changes the result shape and enables paging) and the paging relationship between limit and cursor. It does not restate the recid prefix syntax or the 500-cap nuance already in the 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?
States a specific verb and resource ('List one record's files') and immediately scopes what 'files' means: file indexes with URI-list URLs plus per-file XRootD/HTTPS URIs, size, checksum and availability. This is clearly distinguishable from siblings like search_records and get_records, which operate on records rather than a record's file listing.
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 gives explicit conditional usage: omit index to get the record's indexes and regular files, supply index to read just that index and page through it. It also warns that on-demand files sit on tape and must be requested on the portal before download. It stops short of naming alternative tools or saying when not to call it, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode the vocabulary the other cern_opendata tools accept: experiments, record types, collision energies and types, file formats and data tiers, availability states, physics categories, LHCb magnet polarities and stripping streams and versions, identifier forms, query syntax, licensing, and the CMS run periods that have validated-run lists. Static and offline; omit topic for every table.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | One table to return: experiments, record_types, collision_energies, collision_types, file_types, availability, categories, lhcb, identifiers, query_syntax, licensing or run_periods. Omit for every table. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| topics | No | The requested table, or every table when topic is omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, and the description usefully reinforces this with 'Static and offline', which confirms results are deterministic and safe to repeat. It adds real behavioral context (no network, cached reference data) beyond the safety flags, though nothing about limits or output shape.
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?
Front-loaded with the core purpose, and the trailing 'omit topic for every table' clause is a useful default up front. The long topic enumeration is somewhat redundant with the enum but does convey the breadth of the vocabulary in one pass.
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?
With an output schema present, return-value explanation is not required, and the description covers scope, default behavior, and offline/static nature. An agent has enough to call it correctly; only a pointer to a concrete alternative tool is missing.
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 100% and the single enum param is fully documented there, so baseline is 3. The description enumerates the same topic values in prose (plus extras like LHCb magnet polarities that map under 'lhcb') and restates the omit-for-all default, adding little beyond the 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?
States a specific verb (decode/list) and resource (the controlled vocabulary) and explains exactly what it contains for the cern_opendata tool family. It is clearly distinguishable from siblings like get_records or search_records, which consume this vocabulary rather than define it.
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?
Explains where this fits: it decodes the terms the other cern_opendata tools accept, so an agent knows to consult it before constructing queries. It also states the no-argument default ('omit topic for every table'). It stops short of naming a specific alternative tool to use instead, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the CERN Open Data Portal's datasets, software, environments, documentation and supplementary records with exact-vocabulary filters and an optional full-text query. The filters are experiment, record type, physics category, keyword, collision energy and type, file format, data-taking year, event count, availability, collection, and LHCb magnet polarity, stripping stream and stripping version. Returns compact hits with recids plus live facet counts. Each facet ignores its own filter, so its counts show the alternatives under the other filters. Filter values are exact upstream; common spellings are normalized, and cern_opendata_list_reference lists the vocabulary. Paging reaches the first 10,000 matches.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, from 1, counting pages of the limit applied. page × limit may not exceed 10,000. | |
| sort | No | bestmatch (relevance), mostrecent (by date_published, newest first), title (A-Z) or title_desc (Z-A). Omitted: bestmatch with a query, mostrecent (newest first) without. | |
| type | No | Record types (OR): a primary (Dataset, Documentation, Environment, Software, Supplementaries, News) or Primary::Secondary such as Dataset::Collision or Dataset::Simulated. Up to 7. Omit for every served type; Glossary is not served. | |
| limit | No | Hits per page, 1-50. A value above 50 is served at 50. | |
| query | No | Full-text query, sent verbatim as an OpenSearch query_string (AND between terms; title matches weigh double). Field forms such as title:"…", recid:(1 OR 2) or run_period:("Run2012B") work; cern_opendata_list_reference with topic query_syntax lists them. Omit to browse by filters alone. | |
| year_to | No | Latest data-taking year, inclusive. Alone, it means up to this year. | |
| category | No | Physics categories of simulated datasets (OR): a primary such as Exotica, Higgs Physics, Standard Model Physics or Supersymmetry, or Primary::Secondary such as Higgs Physics::Standard Model. Up to 20; case and the separator are normalized, and a value holding a comma (Exotica::Heavy Fermions, Heavy Righ-Handed Neutrinos) is one item. Heavy-Ion Physics also matches its leading-space spelling. cern_opendata_list_reference topic categories lists every value. | |
| keywords | No | Record keywords (OR), exact and case-sensitive (Education and education differ), sent as given. Up to 10; a keyword holding a comma is one item. | |
| file_type | No | File formats and data tiers (OR), such as nanoaod, miniaod, aod, root, DAOD_PHYSLITE or csv. Up to 20; case is normalized for known values. | |
| year_from | No | Earliest data-taking year, inclusive. Alone, it means this year onward; for one year, set year_from and year_to to it. | |
| collection | No | Portal collections (OR), exact and case-sensitive, such as CMS-Validated-Runs; copy spellings from a record's collections field. Up to 10. | |
| experiment | No | Experiments (OR): ALICE, ATLAS, CMS, DELPHI, JADE, LHCb, OPERA, PHENIX, TOTEM. Up to 9; case is normalized. | |
| max_events | No | Maximum number of events, inclusive. | |
| min_events | No | Minimum number of events, inclusive. | |
| availability | No | Record availability (OR): online, partial, ondemand (on tape, requested before download) or requested. Up to 4. | |
| collision_type | No | Collision types (OR): pp, PbPb, pPb, e+e-, Interfill. PbPb also matches the Pb-Pb spelling. Up to 6. | |
| magnet_polarity | No | LHCb magnet polarities (OR): MagDown or MagUp, set on LHCb collision datasets. Up to 2; case is normalized. | |
| collision_energy | No | Collision energies (OR), such as 7TeV, 8TeV, 13TeV or 5.02TeV. Up to 15; "13TeV, 13.6TeV" is one upstream value and one item. | |
| stripping_stream | No | LHCb stripping streams (OR), such as BHADRON, CHARM, DIMUON, EW or LEPTONIC; they also match LHCb stripping documentation. Up to 11; case is normalized. cern_opendata_list_reference topic lhcb lists them. | |
| stripping_version | No | LHCb stripping versions (OR), such as stripping21 or stripping21r1p2. Up to 12; case is normalized. |
| Name | Required | Description |
|---|---|---|
| cap | No | The page size (limit) applied to this call. |
| hits | No | Matching records on this page. |
| page | No | The page returned. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of items returned on this page. |
| facets | No | Live facet counts. Each facet ignores its own filter, so its counts show the alternatives under the other filters. Terms facets list the first 10 values alphabetically (file_type up to 100), and type and category buckets their first 10 secondary values. other_count, subtypes_other_count and subcategories_other_count sum the counts of the values past those caps, so a record holding several of them counts once per value; other_count is 0 for year and number_events. cern_opendata_list_reference topics record_types and categories list every secondary value, and a Primary::Secondary type or category filter returns its record count as totalCount. |
| 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. |
| truncated | No | True when more results remain past this page; notice says how to reach them. |
| totalCount | No | Total matches for the query and filters. |
| applied_filters | No | The filters as the server applied them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, so safety is covered. The description adds genuinely non-obvious behavior: facet counts ignore their own filter, values are exact upstream with normalization of common spellings, and paging stops at 10,000 matches. Return shape and pagination detail are somewhat thinner, keeping it below 5.
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?
Purpose and return shape are front-loaded, and every sentence carries information (filters, facet behavior, vocabulary routing, paging cap). The long mid-sentence enumeration of filters is dense but justified for a 20-parameter tool; nothing is redundant.
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?
For a 20-param search tool with an output schema, the description covers what an agent needs: purpose, filter vocabulary, normalization rules, facet semantics, pagination ceiling, and the sibling that supplies valid values. Return-value explanation is correctly left to the output schema.
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 100%, so the schema already documents each of the 20 parameters, establishing a baseline of 3. The description adds cross-cutting meaning the schema scatters: the full filter list as a set, the normalization/exactness policy, and the facet-count semantics that govern how filter values should be chosen.
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?
States a specific verb (Search) plus the exact resource scope (CERN Open Data Portal datasets, software, environments, documentation, supplementary records) and enumerates the filter vocabulary. This clearly distinguishes it from siblings like cern_opendata_get_records or cern_opendata_list_reference without needing to open either schema.
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?
Explains the two usage modes (exact-vocabulary filters, optional full-text query) and routes agents to cern_opendata_list_reference for the controlled vocabulary. It does not explicitly say when to prefer cern_opendata_get_records or the other lookup siblings, so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 factors are not returned: each HLT menu record holds a configuration file (cern_opendata_list_files with a menu_recid) whose PrescaleService block lists the prescale in each column of every path it prescales (a path it leaves out has prescale 1), and the CMS luminosity records (collection CMS-Luminosity-Information) hold prescale files that log which column applied by run and luminosity section.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, from 1, counting pages of the limit applied. 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. 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. A value above 50 is served at 50. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/idempotentHint already covering the safety profile, the description adds real value: the 2011-2016 coverage boundary, the explicit statement that prescale factors are NOT returned, and a description of what each match record contains. This is meaningful context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, but the final sentence on prescale retrieval is a long, tangential run-on about PrescaleService blocks and luminosity-section columns that dilutes the core message. Tighter separation of the primary lookup behavior from the prescale footnote would help.
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?
An output schema exists, so return-value detail is largely redundant but harmless; the description still covers coverage range, wildcard semantics, and the non-HLT path case. Nothing critical is missing, though authentication/rate-limit expectations and pagination interaction (page × limit ≤ 10,000) are left to the schema.
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 100%, and the path parameter's schema text already documents wildcard handling, HLT_ prepending, and version-suffix dropping. The description restates these rather than adding new semantics, so the baseline 3 applies.
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 opens with a specific verb and resource: 'Look up CMS High-Level Trigger paths by exact name ... or prefix pattern,' and clarifies what falls outside the HLT_ family. It distinguishes itself adequately from the generic record-lookup siblings, though it never names them directly.
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?
It states the two valid query modes (exact name vs prefix wildcard), the supported data range (2011-2016), and redirects to cern_opendata_list_files and the CMS-Luminosity-Information collection when prescale data is needed. It lacks an explicit 'use this instead of search_records when...' exclusion, but the context is clear.
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.
cern_opendata_get_analysis_env2 fields changedInput schema / properties / recid / descriptionPrevious 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."Output schema / properties / guides / items / properties / reference_definitionsAdded 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"
+}cern_opendata_get_records4 fields changedInput schema / properties / ids / descriptionPrevious value: -"Identifiers to resolve, 1-20: an array, or one comma-separated string. Forms may be mixed; duplicates collapse."New value: +"Identifiers to resolve: up to 100, of which the first 20 distinct are looked up and the rest returned under deferred. Forms may be mixed; exact duplicates collapse."Input schema / properties / ids / maxItemsPrevious value: -20New value: +100Output schema / properties / deferred / descriptionPrevious value: -"Inputs whose records were left out to hold the response to 64,000 bytes, in input order; pass them as ids to fetch those records. Empty when every resolved record is returned."New value: +"Inputs left for another call, in input order: those whose records were left out to hold the response to 64,000 bytes (never the first record, which is returned whole even when larger), then ids past the first 20, which were not looked up. Pass them as ids to fetch them. Empty when nothing was left out."Output schema / properties / notice / descriptionPrevious value: -"Caveats about the returned records: a documentation body with more to read, or records deferred by the response budget, each with the call that continues it."New value: +"Caveats about the returned records: a documentation body with more to read, records deferred by the response budget, or ids past the first 20 that were not looked up, each with the call that continues it."cern_opendata_get_validated_runs3 fields changedInput schema / properties / limit / descriptionPrevious value: -"Runs to return, 1-2000."New value: +"Runs to return, 1-2000. A value above 2000 is served at 2000."Input schema / properties / limit / maximumPrevious value: -2000New value: +10000Input schema / properties / recid / descriptionPrevious 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."cern_opendata_list_files3 fields changedInput schema / properties / limit / descriptionPrevious value: -"Files per page, 1-500."New value: +"Files per page, 1-500. A value above 500 is served at 500."Input schema / properties / limit / maximumPrevious value: -500New value: +10000Input schema / properties / recid / descriptionPrevious value: -"Record id: up to 12 digits (6004), optionally after an experiment prefix (atlas-160006); 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 (atlas-160006). cern_opendata_search_records and cern_opendata_get_records return it."cern_opendata_search_records32 fields changedInput schema / properties / availability / descriptionPrevious value: -"Record availability (OR): online, partial, ondemand (on tape, requested before download) or requested. Array or comma-separated string, up to 4."New value: +"Record availability (OR): online, partial, ondemand (on tape, requested before download) or requested. Up to 4."Input schema / properties / category / descriptionPrevious value: -"Physics categories of simulated datasets (OR): a primary such as Exotica, Higgs Physics, Standard Model Physics or Supersymmetry, or Primary::Secondary such as Higgs Physics::Standard Model. Array or comma-separated string, up to 20; case and the separator are normalized, and a known value holding a comma is kept whole. Heavy-Ion Physics also matches its leading-space spelling. cern_opendata_list_reference topic categories lists every value."New value: +"Physics categories of simulated datasets (OR): a primary such as Exotica, Higgs Physics, Standard Model Physics or Supersymmetry, or Primary::Secondary such as Higgs Physics::Standard Model. Up to 20; case and the separator are normalized, and a value holding a comma (Exotica::Heavy Fermions, Heavy Righ-Handed Neutrinos) is one item. Heavy-Ion Physics also matches its leading-space spelling. cern_opendata_list_reference topic categories lists every value."Input schema / properties / collection / descriptionPrevious value: -"Portal collections (OR), exact and case-sensitive, such as CMS-Validated-Runs; copy spellings from a record's collections field. Array or comma-separated string, up to 10."New value: +"Portal collections (OR), exact and case-sensitive, such as CMS-Validated-Runs; copy spellings from a record's collections field. Up to 10."Input schema / properties / collision_energy / descriptionPrevious value: -"Collision energies (OR), such as 7TeV, 8TeV, 13TeV or 5.02TeV. Array or comma-separated string, up to 15; \"13TeV, 13.6TeV\" is one upstream value and is kept whole."New value: +"Collision energies (OR), such as 7TeV, 8TeV, 13TeV or 5.02TeV. Up to 15; \"13TeV, 13.6TeV\" is one upstream value and one item."Input schema / properties / collision_type / descriptionPrevious value: -"Collision types (OR): pp, PbPb, pPb, e+e-, Interfill. PbPb also matches the Pb-Pb spelling. Array or comma-separated string, up to 6."New value: +"Collision types (OR): pp, PbPb, pPb, e+e-, Interfill. PbPb also matches the Pb-Pb spelling. Up to 6."Input schema / properties / experiment / descriptionPrevious value: -"Experiments (OR): ALICE, ATLAS, CMS, DELPHI, JADE, LHCb, OPERA, PHENIX, TOTEM. Array or comma-separated string, up to 9; case is normalized."New value: +"Experiments (OR): ALICE, ATLAS, CMS, DELPHI, JADE, LHCb, OPERA, PHENIX, TOTEM. Up to 9; case is normalized."Input schema / properties / file_type / descriptionPrevious value: -"File formats and data tiers (OR), such as nanoaod, miniaod, aod, root, DAOD_PHYSLITE or csv. Array or comma-separated string, up to 20; case is normalized for known values."New value: +"File formats and data tiers (OR), such as nanoaod, miniaod, aod, root, DAOD_PHYSLITE or csv. Up to 20; case is normalized for known values."Input schema / properties / keywords / descriptionPrevious value: -"Record keywords (OR), exact and case-sensitive (Education and education differ), sent as given. Array or comma-separated string, up to 10; pass a keyword holding a comma in an array."New value: +"Record keywords (OR), exact and case-sensitive (Education and education differ), sent as given. Up to 10; a keyword holding a comma is one item."Input schema / properties / limit / descriptionPrevious value: -"Hits per page, 1-50."New value: +"Hits per page, 1-50. A value above 50 is served at 50."Input schema / properties / limit / maximumPrevious value: -50New value: +10000Input schema / properties / magnet_polarity / descriptionPrevious value: -"LHCb magnet polarities (OR): MagDown or MagUp, set on LHCb collision datasets. Array or comma-separated string, up to 2; case is normalized."New value: +"LHCb magnet polarities (OR): MagDown or MagUp, set on LHCb collision datasets. Up to 2; case is normalized."Input schema / properties / page / descriptionPrevious value: -"Page number, from 1. page × limit may not exceed 10,000."New value: +"Page number, from 1, counting pages of the limit applied. page × limit may not exceed 10,000."Input schema / properties / stripping_stream / descriptionPrevious value: -"LHCb stripping streams (OR), such as BHADRON, CHARM, DIMUON, EW or LEPTONIC; they also match LHCb stripping documentation. Array or comma-separated string, up to 11; case is normalized. cern_opendata_list_reference topic lhcb lists them."New value: +"LHCb stripping streams (OR), such as BHADRON, CHARM, DIMUON, EW or LEPTONIC; they also match LHCb stripping documentation. Up to 11; case is normalized. cern_opendata_list_reference topic lhcb lists them."Input schema / properties / stripping_version / descriptionPrevious value: -"LHCb stripping versions (OR), such as stripping21 or stripping21r1p2. Array or comma-separated string, up to 12; case is normalized."New value: +"LHCb stripping versions (OR), such as stripping21 or stripping21r1p2. Up to 12; case is normalized."Input schema / properties / type / descriptionPrevious value: -"Record types (OR): a primary (Dataset, Documentation, Environment, Software, Supplementaries, News) or Primary::Secondary such as Dataset::Collision or Dataset::Simulated. Array or comma-separated string, up to 7. Omit for every served type; Glossary is not served."New value: +"Record types (OR): a primary (Dataset, Documentation, Environment, Software, Supplementaries, News) or Primary::Secondary such as Dataset::Collision or Dataset::Simulated. Up to 7. Omit for every served type; Glossary is not served."Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_query`: query leaves a parenthesis, range bracket or double quote unbalanced, or ends in an escaping backslash (refused before any request); or the portal rejected the query string (invalid query syntax), or answered another 400 the server did not anticipate, whose upstream message is carried. `query_server_error`: Every attempt of a search with query set answered HTTP 500, as the portal does for some malformed queries in place of its 400 syntax rejection. `page_window_exceeded`: page × limit exceeds 10,000, the deepest match the portal pages to. `invalid_range`: year_from is after year_to, or min_events is above max_events. `rate_limited`: The portal's 60-a-minute budget is spent: it answered 429, or the request could not start within the call's deadline. data.retryAfter is set. `upstream_unreadable`: The portal answered with a body the server could not read: not JSON, missing the expected envelope, or over the byte ceiling (then data.retryable is false). Also raised when a search answers 404. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_query`: query leaves a parenthesis, range bracket or double quote unbalanced, or ends in an escaping backslash (refused before any request); or the portal rejected the query string (invalid query syntax), or answered another 400 the server did not anticipate, whose upstream message is carried. `query_server_error`: Every attempt of a search with query set answered HTTP 500, as the portal does for some malformed queries in place of its 400 syntax rejection. `page_window_exceeded`: page × limit, the limit applied (at most 50), exceeds 10,000, the deepest match the portal pages to. `invalid_range`: year_from is after year_to, or min_events is above max_events. `rate_limited`: The portal's 60-a-minute budget is spent: it answered 429, or the request could not start within the call's deadline. data.retryAfter is set. `upstream_unreadable`: The portal answered with a body the server could not read: not JSON, missing the expected envelope, or over the byte ceiling (then data.retryable is false). Also raised when a search answers 404. Other values are possible when a failure originates below the handler."Output schema / properties / facets / descriptionPrevious value: -"Live facet counts. Each facet ignores its own filter, so its counts show the alternatives under the other filters. Terms facets list the first 10 values alphabetically (file_type up to 100). other_count is 0 for year and number_events."New value: +"Live facet counts. Each facet ignores its own filter, so its counts show the alternatives under the other filters. Terms facets list the first 10 values alphabetically (file_type up to 100), and type and category buckets their first 10 secondary values. other_count, subtypes_other_count and subcategories_other_count sum the counts of the values past those caps, so a record holding several of them counts once per value; other_count is 0 for year and number_events. cern_opendata_list_reference topics record_types and categories list every secondary value, and a Primary::Secondary type or category filter returns its record count as totalCount."Output schema / properties / facets / properties / availability / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."Output schema / properties / facets / properties / category / properties / buckets / items / properties / subcategories_other_countAdded value: +{
+ "description": "Summed count of the secondary categories past the 10 listed, not a record count; absent when the list is whole.",
+ "type": "number"
+}Output schema / properties / facets / properties / category / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."Output schema / properties / facets / properties / collision_energy / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."Output schema / properties / facets / properties / collision_type / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."Output schema / properties / facets / properties / experiment / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."Output schema / properties / facets / properties / file_type / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."Output schema / properties / facets / properties / keywords / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."Output schema / properties / facets / properties / magnet_polarity / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."Output schema / properties / facets / properties / number_events / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."Output schema / properties / facets / properties / stripping_stream / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."Output schema / properties / facets / properties / stripping_version / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."Output schema / properties / facets / properties / type / properties / buckets / items / properties / subtypes_other_countAdded value: +{
+ "description": "Summed count of the secondary types past the 10 listed, not a record count; absent when the list is whole.",
+ "type": "number"
+}Output schema / properties / facets / properties / type / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."Output schema / properties / facets / properties / year / properties / other_count / descriptionPrevious value: -"Records past the bucket cap."New value: +"Summed count of the values past the bucket cap, not a record count."cern_opendata_search_trigger_paths5 fields changedInput schema / properties / limit / descriptionPrevious value: -"Records per page, 1-50."New value: +"Records per page, 1-50. A value above 50 is served at 50."Input schema / properties / limit / maximumPrevious value: -50New value: +10000Input schema / properties / page / descriptionPrevious value: -"Page number, from 1. page × limit may not exceed 10,000."New value: +"Page number, from 1, counting pages of the limit applied. page × limit may not exceed 10,000."Input schema / properties / path / descriptionPrevious value: -"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>."New value: +"Trigger path name (HLT_IsoMu24, AlCa_EcalPi0) or prefix with one trailing wildcard (HLT_IsoMu*): a letter or digit, then letters, digits and underscores. 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>."Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `page_window_exceeded`: page × limit exceeds 10,000, the deepest match the portal pages to. `rate_limited`: The portal's 60-a-minute budget is spent: it answered 429, or the request could not start within the call's deadline. data.retryAfter is set. `upstream_unreadable`: The portal answered with a body the server could not read: not JSON, missing the expected envelope, or over the byte ceiling (then data.retryable is false). Also raised when a search answers 404. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `page_window_exceeded`: page × limit, the limit applied (at most 50), exceeds 10,000, the deepest match the portal pages to. `rate_limited`: The portal's 60-a-minute budget is spent: it answered 429, or the request could not start within the call's deadline. data.retryAfter is set. `upstream_unreadable`: The portal answered with a body the server could not read: not JSON, missing the expected envelope, or over the byte ceiling (then data.retryable is false). Also raised when a search answers 404. Other values are possible when a failure originates below the handler."cern_opendata_get_analysis_envcern_opendata_get_recordscern_opendata_get_validated_runscern_opendata_list_filescern_opendata_list_referencecern_opendata_search_recordscern_opendata_search_trigger_pathsSearch DataCite datasets and software, fetch DOI metadata, trace relations, format citations.
Search INSPIRE-HEP papers, authors, experiments, HEPData records; get citation metrics and BibTeX.
Search NOAA CDO stations and datasets, fetch historical weather observations.
Search and resolve Zenodo datasets, software, and publications by DOI; trace versions and funding.
Add one secure layer between your agents and this server.