IBM Quantum MCP for AI. Manage entire quantum job lifecycles from your chat.
Works with every AI agent you already use
…and any MCP-compatible client








Connect to your AI in seconds.
IBM Quantum MCP lets your AI agent manage complex quantum computing tasks. You can list available hardware providers, submit jobs for execution, track job status in real-time, and retrieve final results without leaving your chat client.
It’s built to handle the entire lifecycle of a large-scale quantum experiment.
What your AI can do
Cancel job
Stops a quantum job that is currently running on the platform.
Get backend details
Retrieves detailed technical specifications for a specific piece of quantum hardware.
Get job result
Retrieves the final computed data or output from a completed quantum job.
List available quantum providers or get specific technical details on any known backend device.
Send a job to the platform for execution and track its status from submission through completion.
Fetch detailed information about a specific quantum job's outcome or logs after it finishes running.
Ask an AI about this
IBM Quantum MCP: 8 Tools for Compute Management
Use these eight specific tools to control the entire quantum job lifecycle, from checking available providers to retrieving final computational results.
Make your AI actually useful.
Add this MCP to Claude, Cursor, or Windsurf and your AI stops guessing. It gets real tools to look things up, take action, and handle the stuff you keep doing by hand.
Start using IBM Quantum on VinkiusCancel Job
Stops a quantum job that is currently running on the platform.
Get Backend Details
Retrieves detailed technical specifications for a specific piece of quantum hardware.
Get Job Result
Retrieves the final computed data or output from a completed quantum job.
Get Job Details
Fetches the current status, history, and metadata for an existing job ID.
List Backends
Lists all available quantum hardware devices that are currently online and ready for...
List Jobs
Provides a list of all jobs submitted to the platform, along with their current status.
List Providers
Lists all available quantum service providers supported by the IBM Quantum system.
Submit Job
Sends a new quantum computation job to run on the selected hardware backend.
Security and governance baked right in.
Pick your AI client below to get set up. Just create a Vinkius account, subscribe, and you're instantly up and running. We handle the entire backend infrastructure, delivering out-of-the-box support for HTTPS Streamable, SSE, and OAuth2—zero messy routing required.
Choose How to Get Started
Build a custom MCP for your own tools, or connect a ready-made integration from our catalog.
Build Your Own
Turn any API into an MCP. Import a spec, define Agent Skills, or deploy with MCPFusion.
- Import from OpenAPI, Swagger, or YAML specs
- Create Agent Skills with progressive disclosure
- Deploy to edge with MCPFusion framework
- Built in DLP, auth, and compliance on every call
- Real time usage dashboard and cost metering
- Publish to catalog or keep private
Make Your AI Do More
Start with IBM Quantum, then connect any of our 5,100+ other servers whenever your AI needs more. One click, no limits.
- Use this MCP plus 5,100+ others, all in one place
- Add new capabilities to your AI anytime you want
- Every connection is secured and compliant automatically
- Track usage and costs across all your servers
- Works with Claude, ChatGPT, Cursor, and more
- New servers added to the catalog every week
Independent Platform Disclaimer: Vinkius is an independent platform and is not affiliated with, endorsed by, sponsored by, verified by, or otherwise authorized by IBM Quantum. All third-party trademarks, logos, and brand names are the property of their respective owners. Their use on this website is strictly for informational purposes to identify service compatibility and interoperability.
VINKIUS INFRASTRUCTURE
Cloud Hosted
Managed infra
V8 Isolated
Sandboxed per request
Zero-Trust Proxy
No stored credentials
DLP Enforced
Policy on every call
GDPR Compliant
EU data residency
Token Compression
~60% cost reduction
Works with Claude, ChatGPT, Cursor, and more
The Model Context Protocol standardizes how applications expose capabilities to LLMs. Instead of operating in isolation, your AI gains direct access to external platforms, live data, and real-world actions through secure, standardized connections.
This connection provides 8 powerful capabilities that interface natively with Claude, ChatGPT, Cursor, and other compatible AI platforms. No middleware. No custom integration required.
Tracking complex scientific jobs used to be a mess of dashboards and logins.
Today, managing quantum computing means hopping between the vendor's website, checking job IDs against status pages, waiting for emails that confirm completion, then copying those results into your local system. It’s tedious, time-consuming, and prone to manual error.
With this MCP, your agent handles all of that behind the scenes. You submit a job (`submit_job`) through conversation, and it manages the entire waiting period, giving you updates on status or pulling the final outcome when ready.
Controlling Experiments with `cancel_job`
If a job starts running but turns out to be flawed, or if you need to test a different configuration immediately, the manual process involves finding the exact ID and navigating to an admin panel just to hit 'stop'.
Now, your agent handles that cleanup instantly. You tell it which job needs stopping, and calling `cancel_job` terminates the run cleanly, saving time and compute credits.
What your AI can actually do with this
Running an experiment on a specialized backend requires careful coordination—you gotta know which machines are available before you can run anything. This MCP lets your agent handle that whole process. You tell it what you need, and it figures out the best way to get started with IBM Quantum. It controls everything from finding the right hardware through listing providers and backends, submitting a job for execution via submit_job, all the way up to getting the final output or canceling the run if something goes wrong.
It works like having an expert operator sitting next to you: your agent can check backend details with get_backend_details before deploying code. If the job starts, you track its progress using list_jobs and get real-time updates on status or results. You don't have to jump between dashboards; you just ask your AI client through Vinkius, and it handles the API calls for you.
This means getting complex quantum data into your workflow is as simple as asking a question.
019d75b7-28eb-73c4-8b2c-f7c58d88784c Here's how it actually works
The bottom line is that your AI client handles all the necessary API calls—from checking capacity to grabbing results—so you just get the answer you need.
First, your agent asks the MCP to list available providers or backends. This checks which hardware is ready for work.
Next, you instruct the agent to submit a job using submit_job. The system queues the experiment and returns an initial job ID.
Finally, you ask the agent to check the status with get_job_details or retrieve the outcome using get_job_result once the execution is finished.
Who is this actually for?
Computational scientists and HPC engineers who spend too much time manually logging into specialized cloud dashboards. They’re tired of copy-pasting job IDs or refreshing status pages every five minutes while waiting for a complex computation to finish.
Needs to prototype and test multiple quantum circuits quickly, requiring the ability to submit jobs (submit_job) and validate results (get_job_result).
Manages resource allocation, needing to check hardware health using list_backends before starting any major computation.
Monitors job queues and resources across multiple providers, requiring the ability to list active jobs (list_jobs) or cancel failed runs (cancel_job).
What Changes When You Connect
Track status instead of refreshing: Use get_job_details to get the current state of any running experiment, eliminating manual dashboard checks.
Full resource visibility: Before writing a line of code, check available hardware using list_backends or review provider options with list_providers to ensure compatibility.
Instant termination capability: If an experiment hits a snag, you can stop it immediately and cleanly by calling cancel_job, saving compute credits.
Single point for results: Once the run is done, use get_job_result to pull the final data directly into your agent's context, instead of hunting through emails or portals.
Automated workflow building: Your AI client can string together multiple steps—from running a test job (submit_job) to checking its outcome—into one coherent task.
See it in action
Debugging failed experiments
A quantum scientist runs an experiment and it fails. Instead of guessing what went wrong, they ask their agent to first check the job status using get_job_details, then pull any available logs with get_job_result to pinpoint the error.
Preparing for a new project
An HPC specialist needs to know what hardware is best. They ask their agent to run list_providers and then select two promising options, checking them with get_backend_details before committing to code.
Monitoring a long-running job
A computational engineer submits a massive simulation using submit_job. Rather than waiting hours on a dashboard, they ask their agent for periodic status updates via list_jobs until the results are ready.
Resource cleanup and testing
After running several tests, an ops specialist wants to clear out old jobs. They first run list_jobs to see what's active, then use cancel_job on any stale or unwanted runs.
The honest tradeoffs
Assuming the result is ready
The user tries to get results immediately after submitting a job: 'What are my quantum outcomes?' This fails because computation takes time, and they don't know when it finishes.
First, run submit_job. Then wait. Periodically check the status using get_job_details. Only once the status confirms completion should you call get_job_result.
Ignoring hardware constraints
Writing code that assumes a specific quantum backend exists when it might be offline or unavailable.
Always check available resources first. Use list_backends to verify the current device list, then use get_backend_details on your target machine before running any job.
Over-relying on manual tracking
Keeping a spreadsheet of dozens of unique Job IDs and checking them one by one in the console.
Let your agent run list_jobs to get a clean list. You can then pass multiple job IDs back into the chat for status checks, streamlining the process.
When It Fits, When It Doesn't
Use this MCP if your primary need is managing complex, asynchronous, compute-intensive tasks across specialized cloud hardware. Specifically, you need to track a full lifecycle: submit -> monitor -> retrieve. Don't use it if you just need simple API calls or basic data lookups; those are better handled by standard REST client tools. If you only need to list providers and nothing else, the dedicated list_providers tool is sufficient. But if your workflow involves submitting code and retrieving results, this MCP is necessary.
Questions you might have
How do I find out what quantum jobs are running with list_jobs? +
Running list_jobs gives you a comprehensive overview of all submitted experiments. This is the first step if you need to check status across multiple runs or see which resources are currently tied up.
What's the difference between get_job_details and get_job_result? +
get_job_details tells you what is happening (the status, current phase). get_job_result only runs after completion and gives you the actual data output or outcome.
Can I check hardware availability using list_backends? +
Yes. Using list_backends pulls a real-time inventory of all available quantum devices, allowing you to select the best target for your next run before submitting code.
How do I use the submit_job tool when I'm ready to run a quantum calculation? +
You must provide the job parameters, including the specific circuit and backend target. The system validates these inputs before submitting your work. It returns a unique Job ID that you need for all subsequent status checks.
What happens if I run a quantum job that I need to stop early using cancel_job? +
The system attempts to terminate the running computation immediately, freeing up resources. If the job is already finished or in an uncancelable state, the tool will return an appropriate error message.
If I need to know what quantum providers are connected and available, should I use list_providers? +
Yes, list_providers shows all registered IBM Quantum services accessible through this MCP. This helps you determine which organizational scope your calculations belong to.
Beyond just listing them, how do I get specific performance metrics about a backend using get_backend_details? +
This tool retrieves detailed specifications for an individual quantum device. You can check parameters like coherence time and number of available qubits, which is critical before submitting work.
I just submitted a job; how do I use get_job_details to verify its initial status or expected parameters? +
Using get_job_details lets you inspect the setup and current state of the job before it fully processes. This confirms that all necessary inputs were correctly received by the quantum backend.
We've already built the connector for IBM Quantum. Just plug in your AI agents and start using Vinkius.
No hosting. No infrastructure. No complex setup.
All 8 tools are live and waiting.
You're up and running in seconds.
Vinkius gives your AI agents access to the full catalog of app connectors, all fully managed, secure, and enterprise-ready. One subscription, every tool you need.
Built, hosted, and secured by Vinkius. You just connect and go.