Rucio community discussion · 2026-07-09

rucio-mcp

One MCP server for the Rucio community

Giordon Stark · UC Santa Cruz / SCIPP

github.com/kratsg/rucio-mcp
rucio-mcp.readthedocs.io
rucio-mcp.af.uchicago.edu

claude — real session · 2026-07-08

> which sites have a complete replica of my DAOD_PHYS container?

⏺ rucio_list_container_replicas
  (mc20_13TeV:…700320…DAOD_PHYS…p6697)

✓ NET2_DATADISK: 100% complete (821.17 GB, 558 files).
  Five other sites hold only partial scratch fragments.

This is already happening, with or without us

  • Claude Code, Gemini CLI, Codex: on our users' laptops and facilities today
  • They already get Rucio questions: where is my dataset, why is my rule stuck, do I have quota?
  • Without a real interface, the agent improvises: guessed CLI calls, scraped output. Mistakes made with your credentials
  • MCP (Model Context Protocol) is the industry standard for structured, permissioned agent access

The question isn't whether agents talk to Rucio. It's whether we design, review, and control the interface.

Three implementations in under a year: that's a signal

Belle II · BNL

Rucio MCP PoC

  • Cédric Serfon: ~10 tools, shown Nov 2025 (DDM workshop)
  • Demo: classifying stuck rules from a Gemini CLI prompt
  • Plus a RAG support-bot prototype

EIC / ePIC · also DUNE

rucio-eic-mcp-server

  • Forked from the Belle II PoC within weeks
  • 13 tools; x509 and userpass auth
  • Used by EIC and DUNE

this talk

rucio-mcp

  • 44 tools, read + write, any Rucio instance
  • Hosted multi-user, per-user identity
  • PyPI & conda-forge; docs, tests, Helm chart

Three independent builds in months: the demand is real. The waste is staying split: 3× security reviews, 3× auth code, 3× every bugfix.

MCP in 30 seconds

any MCP client

Claude, Gemini CLI, Codex, VS Code, Cursor, …

the LLM lives here

⇄

rucio-mcp

typed tools + site context, authenticated per user

the only thing we have to build

⇄

Rucio server

untouched: standard rucio.client calls

no server-side changes

  • Tools: typed functions the LLM may call (rucio_list_dids, …)
  • Resources: context the LLM can read (your dataset nomenclature)
  • One server → every MCP client works
  • The LLM never touches Rucio directly: only what the tools allow, as the authenticated user

What rucio-mcp is today

v0.6.0 · started March 2026 · production use on the UChicago Analysis Facility

A complete toolbox, built for LLM ergonomics

6 DID discovery

3 replicas

11 rules (read + write)

8 RSEs & storage

2 transfers

5 accounts & quotas

2 subscriptions

2 locks

2 scopes

3 connectivity & proxy

designed for agents

  • Every tool paginates and returns next-step hints
  • Errors classified and explained, never raw tracebacks
  • Bytes humanized; DIDs parsed with Rucio's own extract_scope

engineering hygiene

  • Unit, integration, and live test suites; CI + coverage
  • Docs on ReadTheDocs; typed, linted, pre-commit
  • pip / uvx rucio-mcp / pixi add rucio-mcp (conda-forge)

The full Rucio user surface: discovery, replicas, rule lifecycle, quotas, transfers.

Experiment-agnostic core, per-site knowledge

Site presets bundled today

atlas

cms

dune

escape

belleii · PR #38 open

  • A preset is just the site's rucio.cfg + one registry entry
  • “Contributing a new site” guide in the docs
  • Belle II drafted with Giacomo; config under validation

Nomenclature as context

  • One markdown file per site, served to the LLM: naming, scopes, conventions
  • ATLAS exists (AMI tags, DAOD formats)
  • Open invitations: DUNE #30, CMS #31, ESCAPE #32

Your conventions get a slot. Contributing your site is a one-file PR, not a fork.

Runs where your users are

stdio · local

Your laptop or login node

  • Your existing credentials: x509 proxy, userpass, or OIDC
  • If the rucio CLI works, this works
  • One line of MCP client config

http · multi-user

Hosted for a community

  • One deployment: many users, many sites
  • OAuth 2.1 in front; each user's own Rucio identity behind
  • Nothing to install

http · shared secret

Pre-authenticated service

  • One service identity (e.g. a VOMS proxy) behind a static bearer
  • For group accounts, dashboards, shifter bots

--read-only works in every mode. Helm chart for operators; Prometheus metrics built in.

Security was the design problem

An MCP server sits in a sensitive spot. That constraint shaped every architecture choice.

The OAuth bridge: agent-friendly auth, Rucio-native trust

the mismatch

  • MCP clients speak standard OAuth 2.1 (auth code + PKCE)
  • Rucio speaks its own OIDC polling flow; users never hold IdP tokens
  • Registering clients at every IAM doesn't scale; proxying credentials is worse

the bridge

  • Presents an OAuth 2.1 authorization server to the client…
  • …and drives Rucio's own /auth/oidc polling flow behind it
  • The MCP access token is the Rucio session token, verbatim

  1. Client connects → browser opens → user logs in at their own IdP

  2. Rucio mints the session token, exactly as for the CLI

  3. Every tool call carries that token: normal identity, permissions, audit trail

No IAM registration by anyone. Click, log in, done.

Security stance

  • Rucio stays the sole authority. Tokens pass through unmodified; stale token → 401 → fresh login
  • No stored credentials. In-flight state in memory, 5-minute TTL
  • Every action is the user's own identity. Rucio ACLs, quotas, audit apply unchanged
  • No open registration. DCR removed; clients identified by CIMD, SSRF-guarded
  • Writes are opt-in. --read-only gates all mutating tools server-side
  • Observable. Prometheus metrics: auth outcomes, tool calls, sessions

This layer deserves community security review. One implementation: one review, hardened once, for everyone.

Running today: rucio-mcp.af.uchicago.edu

  • One deployment at the UChicago Analysis Facility
  • Serving ATLAS, CMS, DUNE, ESCAPE; Belle II next
  • Helm-deployed, Prometheus-scraped
  • Users bring their own identity; nothing to install

the entire client setup

// .mcp.json — any experiment, same server

"rucio-dune": {

  "type": "http",

  "url": "https://rucio-mcp.af.uchicago.edu/site/dune/"

}

Four communities, one server, zero IAM registrations, zero per-user setup.

One server, together

What convergence buys us, and the maintenance question, honestly.

What converging buys us

security

One codebase to review, one auth layer to harden, one place to patch as the spec moves (CIMD replaced DCR within months)

effort

Client quirks, pagination, errors: fixed once. Experiments contribute a preset and a nomenclature file, not servers

users

Same tools, docs, and behavior on every experiment; support knowledge and prompts transfer

the prior art

Belle II and EIC's work validated the demand and shaped requirements. Missing a tool? That's an issue, not a fork

We don't each maintain a private FTS. An agent interface deserves the same treatment.

The honest slide: maintenance & governance

Rucio can't bless something unmaintained in a sensitive spot. Agreed. The options:

option 1 · endorse

Community-blessed

Rucio docs point here as the MCP server. Lowest commitment; defers the maintenance question

option 2 · affiliate

Rucio-adjacent project

Shared org, co-maintainers from ≥2 institutes, Rucio security review. No upstream burden

option 3 · adopt

Experimental upstream

Experimental component under rucio/, inside its release & security process

What I bring: active maintenance, releases, docs. I run this in production.

What it needs: 1–2 co-maintainers, a security review, a site owner per experiment.

Live demo · 3 minutes, no rehearsed pipeline

  • Stock Claude Code, pointed at rucio-mcp.af.uchicago.edu
  • Live login through the OAuth bridge, my own identity
  • Real questions. Suggest your own!

prompts on deck

> find DAOD_PHYS containers for DSID 700320 in mc20_13TeV

> which sites have a complete replica of the p6697 one, and how big is it?

> do I have any stuck or suspended rules? group them by error

> what's my quota and usage at MWT2_UC_LOCALGROUPDISK?

The ask

this afternoon

uvx rucio-mcp serve
  --site <yours> --read-only

…or point your client at the hosted URL. File issues.

this month

Bring your site: a rucio.cfg preset + a nomenclature file. DUNE, CMS, ESCAPE slots open.

as a community

Pick a maintenance model (endorse, affiliate, adopt) and name the people. I'm committed either way.

To Cédric, and the EIC and DUNE folks: you proved everyone wants this. Let's finish it once, together.

github.com/kratsg/rucio-mcp · rucio-mcp.readthedocs.io · rucio-mcp.af.uchicago.edu · backup slides below ↓

Backup: the bridge, end to end

  1. MCP client hits /authorize with a CIMD client_id (an https URL); server fetches + validates the metadata document

  2. rucio-mcp calls Rucio /auth/oidc, gets the user-facing polling URL, starts a background poll of /auth/oidc_redirect

  3. User logs in at their IdP in the browser; Rucio mints the session token exactly as for the CLI

  4. Poll completes → rucio-mcp mints a one-time auth code (PKCE-bound, 5-min TTL, in-memory)

  5. Client exchanges the code at /token → access_token is the Rucio session token; expires_in mirrors the token's real expiry, no refresh tokens

  6. Tool calls carry the bearer → injected as X-Rucio-Auth-Token; 401 from Rucio → client re-runs the flow

Full sequence diagram: rucio-mcp.readthedocs.io → “Rucio OAuth Bridge Architecture”. Upstream flow discussion: rucio/rucio#8568.

Backup: the 44 tools

DIDs: list_dids, get_did, list_content, list_files, get_metadata, list_parent_dids

Replicas: list_replicas, list_dataset_replicas, list_container_replicas

Scopes: list_scopes, list_scopes_for_account

Rules: list_did_rules, list_replication_rules, get_replication_rule, list_rule_history, add_rule, delete_rule, update_rule, reduce_rule, move_rule, approve_rule, deny_rule

RSEs: list_rses, get_rse, list_rse_attributes, get_rse_usage, get_rse_limits, get_rse_protocols, get_distance, list_transfer_limits

Accounts: list_accounts, get_account, get_local_account_usage, get_local_account_limits, list_account_rules

Transfers: list_requests, list_requests_history

Subscriptions: list_subscriptions, list_subscription_rules

Locks: get_dataset_locks, get_dataset_locks_by_rse

Connectivity: ping, whoami, voms_proxy_info

All names carry the rucio_ prefix. Write tools respect --read-only. Plus rucio_token_info on HTTP transport.

21a43a5 · 2026-07-09