MCP at the LHC: Coordinating the World’s Largest Machine by Georg Šumailov
(link)Summary
This talk explains how CERN scheduling for the Large Hadron Collider (LHC) can be made easier with the Model Context Protocol (MCP). The speaker walks through the challenges of LHC planning, including limited machine access, safety and technical constraints, and the complexity of the MS Project schedule used as the source of truth. The core idea is to put an MCP server on top of CERN scheduling backends so a local LLM can query tasks in natural language. The talk shows a progression from dumping raw schedule data to the model, to shaping the output, and finally to moving conflict-detection logic into code so the LLM receives only clear, structured signals. The result is a more practical scheduling assistant for tasks like finding whether a planned activity conflicts with existing work in a given location and time window.
Key Takeaways
- LHC scheduling is constrained by access windows, safety requirements, technical dependencies, and location-based conflicts.
- MCP can expose scheduling APIs and database-backed tools to an LLM client in natural language workflows.
- Raw task dumps are too large and noisy; shaping tool output reduces context window pressure.
- Conflict detection should stay in code, not be delegated to the LLM.
- Structured MCP outputs make it easier for an LLM to answer scheduling questions and support analytics use cases.
Sections
Why LHC scheduling is hard
The LHC cannot be accessed while beams are running, so maintenance and interventions must fit into short machine-off windows. Scheduling also has to account for physical conflicts, safety constraints such as emergency alarm tests, technical dependencies like shared power circuits, and operational constraints tied to specific locations or people.
The MS Project schedule as the source of truth
CERN’s scheduling data lives in a large MS Project table with thousands of tasks. Looking for a free slot or a conflict by manually scanning that table is slow and unpleasant, which motivates adding a more usable interface on top of the existing planning data.
Using MCP as an interface layer
The talk introduces MCP as a way to wrap existing backend APIs so a local or on-prem LLM can interact with them using natural language. In this setup, the MCP server sits on top of a Java scheduling backend and database, exposing tools that let a model query LHC planning data without directly navigating the raw table.
From raw data to shaped tool output
An initial MCP tool can return all tasks for a project, but that produces too much data and wastes context window space. By filtering out unnecessary fields, the tool output becomes smaller and easier for the LLM to use. This improves responses while keeping the model focused on relevant scheduling information.
Keep the logic in code
The speaker argues that the LLM should not be responsible for computing schedule truth. Instead, conflict detection and other deterministic logic should run in the MCP server or backend code. In the final version, the tool returns a compact conflict result rather than thousands of tasks, leaving the LLM to interpret clear signals instead of doing the heavy lifting itself.
Example use case and limitations
An example query checks for conflicts for a planned activity at a specific CERN location and date. The MCP tool finds multiple conflicting tasks and reports that the requested slot is unsuitable. In the Q&A, the speaker notes that prompt instructions can help, but programmatic logic is still more reliable and deterministic than asking the model to infer everything.
Keywords: model context protocol, mcp server, cern, lhc scheduling, large hadron collider, ms project, llm tool use, context window management, conflict detection, natural language querying, backend api integration, python mcp server, scheduler orchestration, deterministic logic, structured tool output