I worked at one of the quantum computing co's on their compiler stack (so pretty much pure classical compute stuff), but in order to have even a baseline understanding of the computations and programming using qubits, I had to first get a better intuition for the underlying quantum mechanics at play. This was a great introduction to the physics underpinning the computations:
It's long, and the subject matter is intimidating at times, but watch, re-watch, then go deep by finding papers on subjects like superposition and entanglement, which are the key quantum phenomena that unlock quantum computing.
It also helps to understand a bit about how various qubit modalities are physically operated and affected by the control systems (e.g. how does a program turn into qubit rotations, readouts, and other instruction executions). Some are superconducting chips using electromagnetic wave impulses, some are suspending an ion/atom and using lasers to mutate states, or photonic chips moving light through gates - among a handful of other modalities in the industry and academia.
IBM's Qiskit platform may still have tooling, simulators, and visualizers that help you write a program and step through the operations on the qubit(s) managed by the program:
> how does a program turn into qubit rotations, readouts, and other instruction executions
What is actually involved in the "instruction set" for a quantum computer? How do you "compile" to it? If i treat everything below a "logical qubit" (https://en.wikipedia.org/wiki/Physical_and_logical_qubits) as a black-box since from programming pov it does not(?) matter can i think of it using classical computation models?
This is analogous to how one does not need to know Semiconductor Physics (which is Quantum Physics), Electronic Component Physics to understand the logical boolean framework built on top of it which is then synthesized into an instruction set to program against.
It does! They also still have all their summer schools up that you can go through step by step. Although I must promote Strawberry fields as I believe photonic integrated systems really is the better option.
The mcp part is not essential for the actual controlling of the applications. You could “rip out” the mcp functionality and replace it with something else. The only reason why the authors chose mcp is most likely that it was the first and therefore most common plugin interface for llm tools.
Unfortunately, most standards that we end up with are only standard because they're are widely used and not because they are the best or they make the most sense.
It's not even a standard. It's literally not doing anything here. Not only "can" you rip out MCP there is zero technical reason for any of those things to be an "MCP" in the first place.
MCP literally is the "something else", if you have a better idea in mind, now is the time to bring it out before the MCP train is going too fast to catch up.
Code (including shell scripting) allows the LLM to manipulate the results programmatically, which allows for filtering, aggregation and other logic to occur without multiple round trips between the agent and tool(s). This results in substantially less token usage, which means less compute waste, less cost, and less confusion/"hallucination" on the LLM's part.
If one comes to the same conclusion that many others have (including CloudFlare) that code should be the means by which LLMs interface with the world, then why not skip writing an MCP server and instead just write a command-line program and/or library (as well as any public API necessary)?
Isn't that the point they are making? MCP is useful because everyone is using it, not because it has a technical advantage over rolling your own solution. It won mindshare because of marketing and a large company pushing it.
I've actually taken to both approaches recently, using the mcp-client package to give me an interface to a wide array of prebuilt tools in my non-LLM application. I could have written or sourced 10 different connectors, or I can write one client interface and any tool I plug in shares the same standard interface as all the others.
The most hilarious quote from one of those projects:
>The proxy server is required because the public facing API for UXP Based JavaScript plugin does not allow it to listen on a socket connection (as a server) for the MCP Server to connect to (it can only connect to a socket as a client).
Maybe that should have been the sign that this was completely unnecessary and stupid?
>Do you know of another way you can control all of those applications via LLMs?
Seriously. This becoming a bad joke. I mean conceptually, what did you think was happening here? MCP was just magically doing something that didn't already exist before?
So again, how do I automate Ableton live over a network socket with a standard API? I don't know if you've read the remote control API but it doesn't open a magic socket to remote control Live, you have to code the entire integration and protocol yourself to map whatever API messages you want to Live actions manually.
Let's forget about LLMs completely as they are only tangentially relevant to the benefits of MCP. I want to write 15 lines of python that - no matter the software - is going to trigger the "play" button/action in that software. E.g. I want to hit "play" in both Ableton, Unity and Blender without having to write three times the code, without having to manually write them each an extension plug-ins. How do you do that, today, 2025-11-17 ?
you should check out the Extism[0] project and the Elixir SDK[1]. This would allow you to write the core services, routing, message passing, etc in Elixir, and leverage all the BEAM/OTP have to offer, and then embed "agents" written in other languages which are small Wasm modules that act like in-process plugins.
That's a really interesting idea. My original thought was to use MCP as the way to define other agents, but I'll have to do some more research into extism!
https://www.youtube.com/watch?v=lZ3bPUKo5zc&list=PLUl4u3cNGP...
It's long, and the subject matter is intimidating at times, but watch, re-watch, then go deep by finding papers on subjects like superposition and entanglement, which are the key quantum phenomena that unlock quantum computing.
It also helps to understand a bit about how various qubit modalities are physically operated and affected by the control systems (e.g. how does a program turn into qubit rotations, readouts, and other instruction executions). Some are superconducting chips using electromagnetic wave impulses, some are suspending an ion/atom and using lasers to mutate states, or photonic chips moving light through gates - among a handful of other modalities in the industry and academia.
IBM's Qiskit platform may still have tooling, simulators, and visualizers that help you write a program and step through the operations on the qubit(s) managed by the program:
https://www.ibm.com/quantum/qiskit
reply