Why a gateway
An AI assistant is only as useful to a physicist as the systems it can reach. On an analysis facility those systems are Rucio for data, AMI for metadata, HTCondor for batch, JupyterLab for interactive work, and behind them the grid: x509 proxies, ATLAS IAM tokens, Kerberos tickets. The obvious shortcut, handing those credentials to the assistant so it can call each service directly, multiplies the places a user has to trust with their identity and leaves no single record of what the assistant did.
The AF MCP Platform takes the other path. Every backend sits behind one Model Context Protocol endpoint. The assistant logs in once, as the user, to the facility’s own identity service. From then on the broker decides what the caller may do, mints the right short-lived credential for each backend on the user’s behalf, forwards the call, and writes an audit record. The assistant never sees a proxy, a token for CERN, or a Kerberos ticket. In Giordon’s phrase, MCP is the USB-C port to a service; this platform is the facility’s single, trusted port.
How it works
The broker is four subsystems behind one HTTP contract.
- Identity. Every caller, whether a browser, Claude Desktop or a script, presents its own bearer token. The broker validates it directly against the facility’s Keycloak. A token says who is calling and nothing more.
- Authorization. Permissions are an attribute of the person, not the token. On every request the broker re-reads the caller’s groups and POSIX identity from the Keycloak directory and maps them to permissions through a declarative policy file. A tool the caller is not entitled to does not appear in their tool list at all.
- Credential. For each backend the broker resolves the credential that backend needs: an OAuth token for Rucio, an ATLAS IAM token brokered through a linked CERN account for AMI and PanDA, an HTCondor IDTOKEN, a CERN Kerberos ticket, or an x509/VOMS proxy. Credentials are short-lived, cached per user and per backend, and minted by small single-purpose services. The VOMS service is the only pod that touches a user’s grid certificate; the passphrase is used once and never stored, and the proxy is redeemed by the backend itself so it never transits the aggregator.
- Audit. Each tool invocation produces one structured record with the identity attached and an outcome of success, denied or error. Prometheus metrics stay aggregate and never per user; the audit log is the per-user source of truth, and a usage store serves each user their own history, including wall time, bytes returned and an estimate of the tokens the result injected into their assistant’s context.
Adding the next backend is a configuration change, not a code change: one entry registers the server and the permission it requires, and if it needs its own credential flow, one more entry declares the identity provider. The reference deployment has grown this way from Rucio alone to the catalog below.
What a physicist does
Point the assistant at the endpoint and nothing else. The first request is refused, the client discovers the broker’s OAuth endpoints, a browser window opens on the facility’s login page, and the client stores the resulting token itself. Claude Desktop and Claude Code both work this way today.
{
"mcpServers": {
"atlas-af": { "url": "https://mcp.af.uchicago.edu/mcp" }
}
}
From there the assistant can look up datasets and replicas, query metadata, submit and monitor batch jobs, start or stop the user’s JupyterLab server and read the user’s own files on the facility, all as that user and only within what their group membership allows. A client that cannot open a browser, such as a CI job, uses a token minted on the portal’s Tokens page instead.
The portal at mcp-portal.af.uchicago.edu is for setup, not daily work. Its four screens show the connection snippet and a dashboard, the catalog of backends and tools the signed-in account can reach, the Identities page for linking a CERN account and the x509 grid certificate, and the Tokens page.
The reference deployment
The platform runs on the UChicago ATLAS Analysis Facility for its roughly 800 users, with the broker at mcp.af.uchicago.edu and the portal at mcp-portal.af.uchicago.edu, both on the facility’s Kubernetes cluster and deployed from the project’s Helm chart. The hostnames, realm names and group mappings on this page are that deployment’s configuration; nothing about them is built into the software.
| Component | What it does | Repository |
|---|---|---|
| af-mcp-platform | The broker, the portal and the Helm chart | maniaclab/af-mcp-platform |
| rucio-mcp | ATLAS and ESCAPE distributed data management: datasets, files, replicas | kratsg/rucio-mcp |
| ami-mcp | ATLAS Metadata Interface: provenance and physics metadata | kratsg/ami-mcp |
| condor-mcp | Submit and monitor HTCondor jobs on the facility | bbockelm/golang-htcondor |
| af-jupyterlab-mcp | Create, inspect and delete the user's own JupyterLab servers | maniaclab/af-jupyterlab-mcp |
| af-filesystem-mcp | Browse and read the user's own files on the facility's home and data storage | maniaclab/af-filesystem-mcp |
| servicex-mcp | ServiceX columnar data delivery as MCP tools (in development) | maniaclab/servicex-mcp |
| voms-token-service | Mints x509/VOMS proxies; the only pod that touches grid certificates | maniaclab/voms-token-service |
| condor-token-service | Issues HTCondor IDTOKENs; the pool signing key never leaves HTCondor | maniaclab/condor-token-service |
| krb5-token-service | Mints CERN Kerberos tickets for CERN-authenticated identities | maniaclab/krb5-token-service |
| af-credentials | Library a backend uses to redeem a proxy from the broker at call time | maniaclab/af-credentials |
| servicex-token-service, atlas-search-mcp-bridge | ServiceX refresh-token redemption; auth translation for ATLAS OpenSearch | maniaclab on GitHub |
For other facilities
The platform is written to be deployed, not copied. A facility installs the Helm chart against its own Keycloak, registers whichever backend MCP servers it runs, and declares the identity providers those backends need. The credential-minting services follow one small, auditable pattern: one endpoint, one credential type, one binary, so a facility can add its own without touching the broker. The broker is in Python on FastAPI and FastMCP; the portal is a Vue application linted for accessibility with WCAG 2.1 AA as the target. Everything is MIT licensed.
Where it fits
The gateway is the facility-side half of the Lab’s agentic work. The USATLAS Marketplace carries the portable know-how, skills and plugins, that tell an assistant how to use a facility; the gateway is where that assistant’s calls actually land, under the user’s identity and the facility’s policy. Elwood, the Lab’s agentic analysis framework, reaches the Analysis Facility through it. In the team metaphor Giordon uses for Elwood, the gateway is the stadium entrance: everyone comes in through the same door, shows the same badge, and is on the record.
The work was presented at the Throughput Computing 2026 meeting in June 2026 and is part of the IRIS-HEP agentic-analysis roadmap and the CLARIPHY community effort on agentic analysis systems.
