> I used Google's new Colab MCP server to let an AI agent build, run, debug, and submit a quantum chemistry notebook to real IBM Quantum hardware.
Google just announced the Colab MCP server, an open-source bridge that lets any MCP-compatible AI agent control a live Google Colab notebook.
That sounds useful on paper. But I wanted to see whether it could handle something more demanding than a typical dataset demo.
So I gave an agent a real task: build a quantum chemistry notebook from scratch, install the right dependencies, debug compatibility issues, run a full parameter sweep, and submit a job to real IBM Quantum hardware.
It worked.
A blank Colab notebook became a fully working quantum chemistry workflow, complete with dependency fixes, a 15-point scan, and a real IBM Quantum job submission.
From a blank notebook to a real hardware result, the agent:
- created and structured the notebook
- installed the required packages
- fixed multiple version and runtime errors
- ran a 15-point hydrogen molecule scan
- submitted a real job to IBM's 156-qubit quantum processor
That is what made this experiment interesting to me. Not just the quantum part, but the workflow itself.
Colab MCP turned Colab from a notebook I manually edit into a cloud lab an agent could actively operate.
See the notebook
Here is the actual Colab notebook the agent built and ran during this experiment:
Why this was a good test for Colab MCP
Most product demos stay in safe territory. Load a CSV. Draw a chart. Maybe install one package.
I wanted something messier.
Quantum chemistry is a good stress test because it combines several failure points at once:
- dependency management
- scientific Python tooling
- cloud execution
- notebook organization
- runtime debugging
- optional handoff to real hardware
If Colab MCP could survive that stack, it would tell me much more about its real-world usefulness than a toy notebook ever could.
The setup: Colab MCP
Google's new Colab MCP server gives an MCP-compatible agent programmatic control over a Google Colab notebook. Not read-only access. Real notebook control.
That means an agent can:
- create and edit cells
- write markdown and code
- execute cells
- inspect outputs and tracebacks
- iterate until the notebook actually works
The setup is simple. Add the MCP server to your agent config:
"mcpServers": {
"colab-proxy-mcp": {
"command": "uvx",
"args": ["git+https://github.com/googlecolab/colab-mcp"],
"timeout": 30000
}
}
Prerequisites are minimal:
- Python
- git
- uv
Once the server is configured, it connects to the Colab notebook you already have open in your browser.
The task: compute the H2 potential energy surface
I chose the hydrogen molecule, H₂.
This is the smallest meaningful benchmark in quantum chemistry. It is simple enough to run quickly, but still rich enough to show whether the quantum workflow is doing something real.
The goal was to compute how the molecule's energy changes as the bond between the two hydrogen atoms is stretched. This is called the potential energy surface.
Why does that matter?
Because it lets you compare three things directly:
- a standard classical approximation
- a quantum algorithm
- the exact reference solution
That makes H₂ the perfect test case for both the scientific result and the tooling around it.
What the agent actually did
I opened a fresh Colab notebook, connected the MCP agent, and gave it the task.
From there, the agent generated, executed, and debugged the notebook inside Colab, while I only provided the task and access setup.
Let me start building the notebook in Colab via MCP. First, let me connect and clear the existing test cells.
Good, fresh notebook with one empty cell. Let me start building. I'll delete the empty cell and create the notebook from scratch.
Now let me build the notebook cell by cell. Starting with the title and the dependency install.
Install ran silently (captured output). Let me verify the imports work.
All packages installed and working. Now let me build the H2 single-point demo.
Working perfectly. H2 mapped to 4 qubits with 15 Pauli terms. Now let me add the VQE single-point calculation.
The issue is a V1 vs V2 primitives mismatch. qiskit-algorithms 0.4.0 tries to call the Estimator with V2 tuple syntax but qiskit.primitives.Estimator is V1. I need to use qiskit_aer.primitives.Estimator or use StatevectorEstimator. Let me fix this.
VQE nails it -- captures 100% of the correlation energy, matching the exact solution to machine precision. Now let me build the PES scan.
All 15 points computed in 8.2 seconds. VQE matches exact to 6+ decimal places at every point. You can clearly see HF diverging from the exact solution at stretched distances. Now the visualization.
Plot generated. Now let me move on to the IBM Quantum hardware submission. I need you to provide your IBM key -- let me add the cell that will ask for it.
Smart approach using Colab secrets. Let me update the cell to use that.
Connected to IBM Quantum. We have 4 backends available and selected ibm_fez (156 qubits, 0 pending jobs). Now let me build the hardware submission cell.
The transpiler plugin from qiskit-ibm-runtime is incompatible with qiskit 1.4.x. I need to use qiskit.transpile() directly instead of the preset pass manager with the IBM backend. Let me fix this by transpiling manually.
The IBM runtime transpiler plugins are broken with qiskit 1.4.x. I need to bypass the IBM plugin by explicitly setting translation_method to the default. Let me fix this.
Transpilation worked. Circuit is just depth 1 with 2 X gates (the HF initial state with zero VQE parameters simplifies dramatically). Now let me submit the job to IBM hardware.
The open plan doesn't support sessions. I need to use "single job" mode instead -- submit directly to the backend without a session context.
We got results from real quantum hardware! Job d6tca5msh9gc73digp2g completed on ibm_fez. The hardware result has 13.80 mHartree error (1.21% relative) compared to the exact value -- that's real quantum noise in action.
Now let me add the final comparison visualization and conclusions.
Plot generated. Now let me add the summary and conclusions.
The notebook is complete and fully executed in Colab. Here's what we built and ran:
Notebook summary (17 cells in Colab)
| Cell | Type | What it does |
|---|---|---|
| 1 | Markdown | Title, goal, explanation of PES and VQE |
| 2 | Code | Install deps (qiskit 1.4.x, qiskit-nature, pyscf) |
| 3 | Code | Import verification + version check |
| 4 | Markdown | H2 Hamiltonian explanation |
| 5 | Code | Build H2 Hamiltonian at 0.735 A, Jordan-Wigner mapping (4 qubits, 15 Pauli terms) |
| 6 | Markdown | VQE single-point explanation |
| 7 | Code | Single-point: Exact vs HF vs VQE — VQE captures 100% correlation energy |
| 8 | Markdown | PES scan explanation |
| 9 | Code | 15-point PES scan (0.3-3.0 A) — completed in 8.2 seconds |
| 10 | Markdown | Visualization explanation |
| 11 | Code | PES plot + error plot |
| 12 | Markdown | IBM hardware explanation |
| 13 | Code | Connect to IBM Quantum (Colab secrets), selected ibm_fez (156 qubits) |
| 14 | Code | Transpile circuit for hardware |
| 15 | Code | Submit job to ibm_fez — got -1.1235 Ha (13.8 mHa error, 1.21%) |
| 16 | Code | Final comparison plot (simulator vs hardware) |
| 17 | Markdown | Results table + conclusions |
Real hardware results
-
Job ID:
d6tca5msh9gc73digp2g -
Backend:
ibm_fez(156 superconducting qubits) - Hardware energy: -1.1235 Hartree (1.21% error from exact)
- Simulator energy: -1.1373 Hartree (exact match)
The notebook is ready in your Colab.
1. It resolved the dependency mess
The first real issue was package compatibility.
The Qiskit ecosystem is currently split. Some chemistry-related libraries still depend on the 1.x line and do not yet cleanly support Qiskit 2.x.
The agent figured that out quickly and pinned a working combination:
!pip install 'qiskit>=1.4,<2.0' qiskit-nature==0.7.2 qiskit-algorithms qiskit-aer pyscf qiskit-ibm-runtime
Versions that worked:
- Qiskit 1.4.5
- Qiskit Nature 0.7.2
- Qiskit Algorithms 0.4.0
- PySCF 2.12.1
This is exactly the kind of friction that normally burns time when working manually. The agent saw the environment, adjusted, and moved on.
2. It built the molecular Hamiltonian
Next, the agent used PySCF to compute the electronic integrals for H₂ at equilibrium bond length and mapped the molecule into a qubit Hamiltonian.
The result:
Molecule: H2
Spatial orbitals: 2
Particles (alpha, beta): (1, 1)
Nuclear repulsion energy: 0.719969 Hartree
Qubit Hamiltonian:
Qubits required: 4
Pauli terms: 15
Two hydrogen atoms became a 4-qubit problem with 15 Pauli terms. Small enough to simulate exactly, but still a real quantum chemistry workload.
3. It ran VQE and debugged the first major failure
At equilibrium geometry, the agent ran three methods:
| Method | Energy (Hartree) | Error vs Exact |
|---|---|---|
| Hartree-Fock | -1.11700 | 20.31 mHa |
| VQE (simulator) | -1.13731 | 0.00 mHa |
| Exact diagonalization | -1.13731 | - |
This part mattered scientifically.
The VQE result matched the exact answer on the simulator, while Hartree-Fock left a noticeable gap. That is the core promise of quantum chemistry workflows like this: quantum methods can recover effects that standard approximations miss.
But the first VQE attempt did not work.
The agent hit:
AlgorithmError: The primitive job to evaluate the energy failed!
The cause was a version mismatch between the primitive being used and the API style expected by qiskit-algorithms.
The fix was to switch to StatevectorEstimator, rerun the notebook, and continue.
That debugging loop is the real value of Colab MCP. The agent does not just generate code. It sees the traceback, changes the notebook, and re-executes until the workflow is alive again.
4. It scanned the full potential energy surface
Once the equilibrium point worked, the agent swept 15 bond distances from 0.3 Å to 3.0 Å:
Scanning 15 bond distances from 0.30 to 3.00 Angstrom
[1/15] d = 0.3000 A ... HF=-0.593828 Exact=-0.601804 VQE=-0.601804
[2/15] d = 0.4929 A ... HF=-1.036415 Exact=-1.048389 VQE=-1.048389
[3/15] d = 0.6857 A ... HF=-1.116747 Exact=-1.135016 VQE=-1.135016
...
[14/15] d = 2.8071 A ... HF=-0.671046 Exact=-0.934126 VQE=-0.934125
[15/15] d = 3.0000 A ... HF=-0.656048 Exact=-0.933632 VQE=-0.933632
PES scan complete in 8.2 seconds
This is where the scientific point became obvious.
As the bond stretches, Hartree-Fock gets much worse. At 3.0 Å, it is off by 277 mHartree. VQE stays essentially aligned with the exact result across the full curve.
So this was not just an orchestration demo. The experiment also captured a real chemistry phenomenon that motivates quantum algorithms in the first place.
Then I pushed it to real quantum hardware
After the simulator run, I wanted to see whether the same workflow would survive contact with real hardware.
The agent connected to IBM Quantum using a token stored in Colab Secrets:
from google.colab import userdata
IBM_TOKEN = userdata.get('IBM_TOKEN')
service = QiskitRuntimeService(
channel="ibm_quantum_platform",
token=IBM_TOKEN
)
Available backends included:
-
ibm_fez: 156 qubits, 0 pending jobs -
ibm_torino: 133 qubits, 0 pending jobs -
ibm_kingston: 156 qubits, 119 pending jobs -
ibm_marrakesh: 156 qubits, 0 pending jobs
The agent selected ibm_fez.
Then things got messy again.
More breakage, more fixes
The IBM runtime transpiler plugins were not compatible with the Qiskit 1.4.x environment used by the chemistry stack.
That caused:
TranspilerError: Invalid plugin name ibm_dynamic_circuits
The fix was to bypass the plugin path and transpile directly against the backend's basis gates and coupling map.
Then another issue appeared: IBM's open plan did not support Sessions in this setup.
So the agent switched from a Session-based flow to:
EstimatorV2(mode=backend)
Again, this is where the workflow becomes meaningful.
The agent was not just writing a notebook. It was navigating a real compatibility chain across Colab, Qiskit, and IBM Runtime.
The hardware result
The final hardware run returned:
Job ID: d6tca5msh9gc73digp2g
Backend: ibm_fez (156 qubits)
Electronic energy: -1.843475 Hartree
Nuclear repulsion: 0.719969 Hartree
Total energy: -1.123506 Hartree
Standard deviation: 0.004275
Comparison at equilibrium (0.735 A):
Exact (classical): -1.137306 Hartree
VQE (simulator): -1.137306 Hartree
IBM Hardware: -1.123506 Hartree
Hardware error: 13.80 mHartree (1.21% relative error)
To verify this was not just a simulator handoff, here is the completed IBM Quantum job record from the run:
So the hardware result landed in the right range, but it was clearly degraded compared to the ideal simulator.
That is not a failure. That is the current reality of NISQ-era quantum computing.
The algorithm worked. The notebook worked. The cloud workflow worked. But physical qubits still introduce noise through gate error, decoherence, and measurement error.
And that contrast was valuable to see in one end-to-end run.
Why this experiment was meaningful
There were two reasons this was worth doing.
1. It showed a real scientific difference
H₂ is small, but meaningful.
It is the smallest benchmark that still exposes whether the algorithmic stack is doing real work. The simulator showed that VQE could recover the exact solution for this system, and the full bond scan highlighted where classical approximation methods begin to fail.
2. It showed a new way to work with agents
This was the bigger surprise.
Colab MCP made it practical to hand a messy technical objective to an agent and let it operate inside a cloud notebook until the notebook actually worked.
That included:
- package installation
- notebook structure
- traceback-driven debugging
- reruns after fixes
- cloud execution
- optional handoff to real quantum hardware
That is much more interesting than simple code generation.
It points toward a new working style where Colab becomes an executable cloud workspace for AI agents, not just a place humans paste code into.
What I learned
Colab MCP is genuinely useful
This did not feel like a gimmick.
The agent created 17 cells, handled several compatibility issues, ran a 15-point scientific sweep, submitted a real quantum job, and produced usable outputs quickly.
That is exactly the kind of workflow where local-only agent setups start to feel cramped.
The package ecosystem is still the roughest part
The biggest friction was not the quantum algorithm.
It was Python package compatibility across Qiskit, chemistry libraries, and IBM runtime tooling.
That is where a notebook-controlling agent helps most. It can read the errors and iterate much faster than a human manually bouncing between terminal, browser, and documentation.
Real hardware is still noisy
The simulator matched the exact answer.
The hardware result came back with 1.21% relative error on a very small problem. That is a useful reminder that the software stack may be getting smoother while the hardware frontier is still about error mitigation and long-term fault tolerance.
Colab is an underrated chemistry environment
PySCF installs cleanly in Colab's Linux runtime and avoids the setup pain many people hit on Windows.
For this kind of workflow, the combination of Colab plus MCP is not just convenient. It may actually be the easiest path from idea to result.
How to reproduce it
- Set up the Colab MCP server in your agent config
- Open a Google Colab notebook in your browser
- Add your IBM Quantum token to Colab Secrets as
IBM_TOKEN - Give the agent a concrete task and let it build the notebook
In my case, the task was ambitious enough to break a few times, which is exactly why it was useful.
Final take
Google's Colab MCP announcement is not just about making notebook automation easier.
It changes what Colab can be.
Instead of treating Colab as a notebook you manually edit, you can start treating it as a cloud workspace an agent can actively operate.
This experiment pushed that idea through a workflow that included scientific Python, version conflicts, notebook authoring, parameter sweeps, and real hardware submission.
The result was not magic. It was a real notebook, built in the cloud, debugged in place, and executed end to end by an agent.
That is why I think Colab MCP is worth paying attention to.
> If this was my first stress test of Colab MCP, it was a very convincing one.
Top comments (0)