Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fisicai reinterpret the ATLAS sbottom search using its published likelihood"
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.
An open-source agentic harness for high-energy physics.
fisicai gives an AI agent the tools a particle physicist actually uses: the INSPIRE-HEP literature database, arXiv, HEPData, the Scikit-HEP analysis stack, and — most importantly — published statistical likelihoods from real LHC searches. It doesn't just talk about papers. It reinterprets them.
$ fisicai "download the pyhf likelihood for the ATLAS sbottom 1Lbb search and \
compute the CLs exclusion for the (600, 280, 150) GeV signal point"A real session (full walkthrough): the agent fetches the ATLAS SUSY-2018-31 published likelihood and reproduces its CLs to all published digits — from the analysis's own statistical model, not a digitized curve.
A single LHC analysis takes a team of physicists years: skims, background estimates, systematics, multivariate discriminants, statistical interpretation. Reinterpreting that analysis for a new theory model — the thing that makes a search scientifically durable — usually never happens, because nobody has the time.
But the field quietly built the infrastructure to change that. ATLAS (and increasingly CMS)
now publish their full statistical models as pyhf JSON
workspaces on HEPData. An agent that can read a paper, fetch its
likelihood, patch in a new signal, and run pyhf.infer can do in minutes what today takes a
phenomenologist weeks.
fisicai is the harness that makes that loop routine.
Related MCP server: CERN GitLab MCP Server
Literature — search INSPIRE-HEP, fetch arXiv abstracts and full text.
Data — locate HEPData records and their resources, including published pyhf workspaces.
Statistics — apply signal patches to published likelihoods and compute observed and
expected CLs limits with pyhf.
Analysis — the agent works in a sandbox with the Scikit-HEP stack (uproot, awkward,
hist, pyhf, matplotlib) available for cutflows, histograms, and plots.
Domain knowledge lives in versioned markdown skills (src/fisicai/skills/) — how to
reinterpret a search, how to run a cutflow. This is the community contribution surface: teach
the agent your workflow by writing a skill, not by patching code.
$ pip install fisicai # or: pip install -e . from a checkout
$ fisicai "find the latest CMS top squark search and summarize its exclusion reach"
$ fisicai chat # interactive sessionfisicai is built on the Claude Agent SDK and uses
your existing Claude Code credentials (claude CLI login or ANTHROPIC_API_KEY). Select a
model with --model or FISICAI_MODEL.
The tools are also exposed as a standard MCP server — vendor-neutral, works with Claude Code, Cursor, opencode, LangChain adapters, or any other MCP client:
$ claude mcp add fisicai -- fisicai-mcp # Claude Codeor in any MCP client config:
{ "mcpServers": { "fisicai": { "command": "fisicai-mcp" } } }Your agent then has inspire_search, inspire_bibtex, arxiv_fetch, hepdata_get,
hepdata_download_likelihood, pyhf_list_patches, pyhf_cls — plus the write-up
machinery: note_template, writeup_macros, and bundle_validate, so any MCP client
can produce and validate full analysis bundles, not just query data.
Research output isn't a chat answer — it's an analysis. fisicai analyze makes the agent
deliver a complete, reproducible analysis bundle: the analysis code, every result as
data, and a compiled LaTeX note.
$ fisicai analyze "measure the Z boson mass in the Open Data dimuon skim"produces:
analyses/<name>/
├── analysis.py # deterministic, runs end-to-end
├── results/
│ ├── results.json # every number the note quotes
│ └── results.tex # auto-generated \newcommand macros (python -m fisicai.writeup)
├── figures/*.pdf
└── note/
├── note.tex # quotes numbers ONLY via the macros — no hand-typed values
├── references.bib # every entry fetched from INSPIRE (inspire_bibtex tool)
└── note.pdf # compiled with tectonicThe invariant: the note cannot drift from the code. Prose numbers come from generated
macros; citations come from INSPIRE's own BibTeX; rerunning analysis.py regenerates the
whole artifact. See analyses/zmumu_z_mass for a complete example
produced by the agent.
Notes follow experiment-publication conventions: a shipped LaTeX template
(python -m fisicai.writeup --init-note note/) with the canonical section structure
(Introduction / Detector and data / Event selection / Method / Systematic uncertainties /
Results / Summary), hepnote.sty macros (\pt, \GeV, \stat/\syst, …), and
mplhep-styled figures.
How do you trust an AI with physics? You score it against results that are already known.
HEPAbench is a benchmark of analysis tasks with published reference answers — from a
toy-workspace CLs fit to reproducing a real ATLAS exclusion from its published likelihood.
The scorer is harness-agnostic: any agent that writes an answer.json can be benchmarked.
$ hepabench list
$ hepabench run --offline # tasks that need no network
$ hepabench run # the full suite, driven by the fisicai agent
$ hepabench score toy_cls answer.json # score any agent's answer
$ hepabench validate analyses/zmumu_z_mass # validate an analysis bundlehepabench validate turns "the agent wrote a paper" into "the agent wrote a
reproducible paper": it reruns analysis.py in a clean copy and requires an identical
results.json, checks that results.tex regenerates from it, that no result value is
hand-typed in the note, that every citation resolves, and that the note compiles from
scratch. The shipped Z-mass bundle passes all six checks.
Every check carries a continuous score in [0, 1] — numeric answers earn more the closer they land to the reference (1.0 exact, 0.5 at the tolerance edge, 0 beyond twice the tolerance) — and the suite reports one aggregate number. That makes HEPAbench a target function: harnesses, models, and prompts can be optimized against it, and improvements show up as score, not anecdotes.
Current v0 suite — the fisicai agent scores 4/4:
Task | Reference | Agent result |
| 0.0525 (pyhf docs) | 0.05251 |
| arXiv:2301.08096 | exact |
| 0.24444 | 0.24444 |
| 91.1876 GeV (PDG) | 90.95 GeV |
The opendata_zmumu skim ships with the package (3.7 MB, regenerable from CERN Open Data
with scripts/make_zmumu_skim.py), so that task runs offline on a laptop.
The recorded agent answers behind this table are committed under hepabench_results/ and re-scored on every push in CI, which also runs the full bundle validation — the claims above are continuously verified, not prose.
Contributing a task = one YAML file with a prompt and a published reference value
(src/fisicai/hepabench/tasks/) — see CONTRIBUTING.md. Tasks that
agents fail are the most valuable ones.
M1 — Literature agent: end-to-end INSPIRE/arXiv research tasks. (done)
M2 — Reinterpretation: reproduce a published ATLAS exclusion point from its HEPData likelihood — an objective, physics-grade correctness check. (done — see examples/reinterpret_sbottom.md)
M3 — Community: grow HEPAbench (CMS Open Data cutflow tasks, more published likelihoods), recast scans over patchsets, simplified-likelihood support, and whatever the reinterpretation community asks for first.
Beyond: the simulation chain for reinterpreting new models (MadGraph → fast sim → efficiency maps → patched likelihoods), and new results on new data.
The long-term goal is not tooling — it is to advance physics itself. Agents that can hold the entire literature, run every published likelihood, and test a theory against all existing data at once change what a single physicist can ask. Deeper questions — unification, what lies beyond the Standard Model — stay on this README as the direction of travel. The wedge is making today's analyses fast, reproducible, and reinterpretable.
Issues and PRs welcome — especially new skills, support for more published-likelihood formats, and reports of analyses the agent gets wrong. Physics correctness bugs are the highest-value contributions (there's an issue template for them). See CONTRIBUTING.md for dev setup and the HEPAbench task-authoring guide.
Apache-2.0
Fetch an arXiv paper.
section='abstract' returns title, authors, and abstract; section='fulltext' returns the plain-text body from arXiv's HTML rendering (availability varies by paper).
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | abstract | |
| arxiv_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It mentions that fulltext availability varies by paper, which is a useful behavioral trait. However, it omits details on authentication, rate limits, and error handling that would be expected for network-based fetch operations.
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 description consists of two efficient sentences. The first sentence front-loads the core purpose, and the second provides parameter details without excess text. Every sentence contributes meaning.
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 simple two-parameter tool with an output schema, the description covers the key usage points: what each section returns and the availability caveat for fulltext. It lacks mention of error conditions or ID format, but given the tool's simplicity and presence of an output schema, it is largely complete.
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?
The schema has 0% description coverage, so the description must compensate. It explains the 'section' parameter's allowed values and what each returns, adding value beyond the schema. The 'arxiv_id' parameter is implied by context but not explicitly described (e.g., format or examples), leaving some ambiguity.
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 clearly states 'Fetch an arXiv paper' with specific verb and resource. It distinguishes itself from sibling tools focused on HEP data (inspire_search, hepdata_get) by explicitly targeting arXiv papers.
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 explains the two section options (abstract vs fulltext) and their return types, providing context for usage. However, it does not explicitly state when to use this tool over alternatives or mention prerequisites, missing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an analysis bundle: layout, reproducibility (rerun analysis.py in a clean copy and require identical results.json), macros in sync, no hand-typed result values in the note, citations resolve, and the note compiles.
| Name | Required | Description | Default |
|---|---|---|---|
| run | No | ||
| bundle_dir | Yes | ||
| compile_pdf | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavior. It mentions reproducibility (rerun and verify results) but lacks details on side effects, permissions, or failure modes. Adequate but not fully transparent.
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 description is one sentence with a list of checks, which is efficient. However, it could be more structured (e.g., bullet points) for readability.
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?
Given an output schema exists, the description covers the tool's actions adequately. Parameter details are missing, but the core purpose is clear. Adequate for a validation tool with simple parameters.
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 0%, and the description provides no parameter-level details. It mentions 'bundle_dir' implicitly but does not explain 'run' or 'compile_pdf'. Fails to compensate for missing schema descriptions.
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 clearly lists all validation checks (layout, reproducibility, macros, etc.), leaving no ambiguity about the tool's purpose. It distinguishes from siblings, which are unrelated search/fetch tools.
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 implies usage for validating analysis bundles but does not explicitly state when to use versus alternatives. However, sibling tools are very different, so context suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download and extract a published pyhf likelihood archive from HEPData.
Pass the resource URL found via hepdata_get and a local output directory.
| Name | Required | Description | Default |
|---|---|---|---|
| output_dir | Yes | ||
| archive_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'download and extract' without disclosing side effects (e.g., file overwriting, required permissions, or error handling). This is insufficient for an AI agent to understand the full behavioral impact.
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 description is two sentences, front-loaded with the core action, and contains no extraneous words. Every sentence adds value.
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?
The description covers the basic function and a key prerequisite (URL from hepdata_get), but fails to describe output behavior, error conditions, or whether the output directory must exist. With an output schema available, the description could have referenced it.
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 0%, yet the description merely names the parameters ('resource URL' and 'local output directory') without adding constraints, formats, or defaults. The agent gains little extra meaning 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?
The description clearly states the verb 'Download and extract' and the resource 'published pyhf likelihood archive from HEPData', distinguishing it from sibling tools like hepdata_get which presumably retrieves metadata, and other tools.
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 specifies that the resource URL comes from hepdata_get, giving clear context on prerequisite usage. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a HEPData record by INSPIRE record id (e.g. 1748602).
Lists its data tables and additional resources, flagging ones that look like published statistical models (pyhf likelihoods).
| Name | Required | Description | Default |
|---|---|---|---|
| inspire_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool lists tables, resources, and flags pyhf likelihoods. It does not mention side effects or permissions, but for a GET-like tool this is acceptable. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action, second adds key detail. No redundant words. Efficient and clear.
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?
Given a single parameter and existing output schema, the description covers the tool's purpose and return structure well. However, it omits mention of error handling or edge cases (e.g., invalid ID).
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 0%, so the description must compensate. It provides an example (1748602) and explains that the parameter is an INSPIRE record ID, adding meaning beyond the schema's bare string type. Could specify format more precisely.
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 clearly states it fetches a HEPData record by INSPIRE ID, lists data tables and resources, and flags statistical models. It distinguishes from siblings like hepdata_download_likelihood which downloads a specific likelihood.
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 implicitly conveys usage (fetch metadata for a record), but does not explicitly state when to use it vs alternatives or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the official BibTeX entry for a paper from INSPIRE-HEP.
Accepts an INSPIRE record id (e.g. 1748602) or arXiv id (e.g. 2301.08096). Always use this for bibliography entries — never write BibTeX by hand.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the operation is read-only, requires authentication, has rate limits, or what happens on invalid identifiers. For a fetch tool, such details are missing.
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-load the purpose and key guidance with no extraneous words. Every sentence earns its place.
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?
Given that there is an output schema, the description does not need to detail return values. It covers inputs and use case well. However, it could mention that only the first matching entry is returned or error behavior.
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 0%, but the description fully compensates by explaining that 'identifier' accepts an INSPIRE record id or arXiv id, and provides concrete examples (1748602, 2301.08096). This adds significant clarity beyond the bare 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?
The description clearly states the verb 'Fetch', the resource 'official BibTeX entry', and the source 'INSPIRE-HEP'. It distinguishes from sibling tools like arxiv_fetch and inspire_search by focusing on bibliographic entry retrieval.
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 provides explicit guidance: 'Always use this for bibliography entries — never write BibTeX by hand.' It tells when to use and when not to, but does not directly compare to siblings like arxiv_fetch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the INSPIRE-HEP literature database for high-energy physics papers.
Supports the full INSPIRE query syntax, e.g. 'title top squark and collaboration CMS', 'a Witten and tc p', 'arxiv 2301.08096'. Returns titles, authors, arXiv ids, journal references, citation counts, abstracts, and INSPIRE record ids (needed for HEPData).
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | ||
| sort | No | mostrecent | |
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially discloses behavior by listing returned fields (titles, authors, arXiv IDs, etc.) and mentioning query syntax. However, it omits details like rate limits, authentication, error handling, or pagination behavior.
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 description is concise with two paragraphs and front-loads the main purpose. Every sentence adds value, though the structure could be more organized with bullet points for the returned fields.
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?
Given the presence of an output schema, the description adequately lists returned fields. However, it does not mention that results are returned as a list, how pagination works, or error scenarios. The default sort order and size are not explained.
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 0%, so the description must compensate. It includes query examples but does not explain the 'size' and 'sort' parameters. This leaves significant ambiguity about their meaning and allowed values.
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 clearly states the tool searches the INSPIRE-HEP literature database for high-energy physics papers, with specific examples of query syntax. It distinguishes itself from siblings like arxiv_fetch and hepdata_get by focusing on the INSPIRE database.
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 provides examples of queries but does not explicitly guide when to use this tool versus alternatives. It implies usage for literature search but lacks direct 'when to use' or 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the signal patches (model points) in a downloaded published-likelihood directory containing a patchset.json.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_dir | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses the core action (list patches) and mentions the required file (patchset.json), but does not discuss behavior like error handling or whether it's read-only. Simplicity and presence of output schema make this adequate.
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?
Single sentence that front-loads the action and includes key context. No extraneous words.
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?
Given the tool's simplicity (1 param, has output schema), the description covers the essential context: what is listed, from what source. Could mention the output type implicitly via schema, but overall complete.
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 0%, yet the description only adds that the directory must contain patchset.json, not clarifying the parameter's type or format. The meaning of workspace_dir is partially inferred but not explicit.
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?
Description clearly states the tool lists signal patches (model points) from a downloaded published-likelihood directory containing patchset.json, with a specific verb and resource. It distinguishes from sibling tools like hepdata_download_likelihood.
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?
Implies the tool should be used after downloading a likelihood directory, but does not explicitly state when to use or when not, nor does it mention alternatives. Siblings are provided but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource and action: arXiv fetching, HEPData metadata and download, INSPIRE search and BibTeX, likelihood patch listing, and bundle validation. No two tools have overlapping purposes.
All names use snake_case and are lowercase. Most follow a resource_verb or resource_verb_object pattern (e.g., arxiv_fetch, hepdata_get), but 'inspire_bibtex' is just resource_object and slightly inconsistent. Overall, the pattern is clear and predictable.
With 7 tools, the set is well-scoped for the domain of high-energy physics data access and validation. Each tool serves a clear purpose without redundancy or unnecessary complexity.
The tools cover core workflows: searching literature, fetching papers and BibTeX, accessing HEPData records and likelihoods, and validating analysis bundles. Minor gaps include no direct PDF download from arXiv and no HEPData search, but these are not critical for the intended use.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Altmetric APIs - track research attention across news, policy, social media, and more
arXiv MCP — preprint server search (free, no auth)
QuLab MCP remote server (Streamable HTTP) for computational science and lab tools.
Auditable MCP server for PubMed, Europe PMC, ClinicalTrials.gov, and bioRxiv/medRxiv queries
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/diogodebastos/fisicai'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
