Loading ToolBench
Exposes live IBM Quantum and IonQ device data, quantum chemistry simulation tools, and circuit submission capabilities to AI assistants via the MCP protocol.
42 tools with highly inconsistent quality. Most lack visible input schemas in the provided source. Descriptions range from terse (8-15 chars: 'all machines + status') to detailed (chemistry tools). No parameter descriptions visible for majority of tools. Tool names follow verb_noun pattern well (list_*, get_*, submit_*, etc.), but schema documentation is largely absent. Chemistry tools (analyze_molecule, plan_quantum_chemistry_run) show proper JSON Schema with typed parameters and descriptions; remaining 35 tools have no visible schema definitions. Error handling and output schemas not documented. Composition is reasonable (tools are single-purpose), but lack of schema visibility prevents confident assessment of parameter validation.
Work out what a molecule costs to simulate on a quantum computer. Computes the qubit Hamiltonian from geometry, then reports how far entanglement forging and Pauli grouping can cut the problem down.
best n qubits on a machine right now (calibration-based)
emit OPENQASM, self-checked on a simulator first
cancel a queued or running job
detect a silent hardware swap or qubit relabeling via real per-qubit calibration fingerprint history
predict SWAP inflation from qubit interaction graph (degree > 3 = danger)
40 of 42 tools have NO visible input schemas. Cannot verify parameter types, constraints, or descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
dry-run analysis — fidelity estimate, gate counts, qubit map
reconstruct the energy once the jobs finish
rank machines by error rate / queue / combined score
bug detector — finds errors before you waste queue time
historical snapshots for one machine over N days
historical stats for a machine on a specific past date
scout — filters ALL k-pairs for hardware-feasible collisions before spending QPU credits
classically find C(n1,k1)=C(n2,k2) pairs, encode as Ising h_i for LNAA collision search
convert Boolean conditions into Ising h_i / J_ij for LNAA circuits
upper bound on observable error from gate counts
run Estimator primitive to compute observable expectation values
predict transpiled gate count from logical gates + qubit degree
estimate how many minutes a circuit will cost on a device
calibration drift alerts — devices that spiked or went offline
compute amplification factor from a completed search job
deep info on one machine
list IonQ quantum computers and simulators
retrieve measurement counts from a completed IonQ job
check the status of a submitted IonQ job
submit an OpenQASM 2 circuit to IonQ hardware or simulator
retrieve measurement counts from a completed job
check the status of a submitted job
all machines + status
list recent jobs with status and backend
Given a molecule and a budget, recommend how to actually run it. Answers the practical question: what is the most accurate result I can buy for this much money? Works through every Schmidt rank, applies the circuit optimisations, and reports which options fit.
current queue depth for every machine
which techniques help, from measurements not theory
compute 0-1 reproducibility score after runs complete
recommend the cheapest device that fits your circuit + time budget
submit those circuits to real hardware
built-in Grover's search demo on real hardware
ONE job, MULTIPLE k-pair searches on parallel 9-qubit rails across ibm_marrakesh's 156 qubits
ONE CALL does everything — encode → build circuit → pick best machine → submit → amplification
classical Lucas' theorem sieve — eliminates 98%+ of Pascal's Triangle search space before any QPU job
submit same circuit N times to measure reproducibility
compile + submit an OpenQASM 2 or 3 circuit to IBM hardware
Most tool descriptions are under 50 characters and lack context for LLM selection. E.g., 'all machines + status', 'deep info on one machine', 'current queue depth for every machine'. These terse descriptions do not explain WHEN to use the tool or what it returns.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., device_id, job_id) without knowing response structure.
No error handling guidance visible. Tools like submit_job, cancel_job, and run_forged_energy are destructive/reversible but provide no recovery hints.
Two chemistry tools (analyze_molecule, plan_quantum_chemistry_run) have proper schemas with typed parameters and descriptions; remaining 40 tools show no schema definitions in provided source. This inconsistency suggests schemas may exist in server.py but are not visible in the excerpt provided, or are missing entirely.