If you have spent any time around coding agents in the last year, you have probably bumped into three letters that keep showing up: MCP. People talk about “MCP servers,” “MCP tools,” and “connecting Claude over MCP” as if everyone already knows what it means. Most of us picked it up by osmosis, never got the straight answer, and quietly nodded along. So here is the straight answer. What is MCP? MCP, the Model Context Protocol, is an open standard that lets an AI agent call external tools and read external data through one common interface — instead of every app inventing its own bespoke integration. That is the whole idea. And for Bitcoiners, it matters because MCP is exactly the plumbing that lets you point your own agent at your own miner and control it locally, without handing the keys to a cloud dashboard.
This is the definitional explainer. If you want the hands-on walkthrough of controlling hardware with an agent, that is a separate piece. Here we answer the question a pleb actually types into a search box — “what is MCP” — in plain English, then show why the Model Context Protocol is the worked Bitcoin example we care about: DCENT_axe control.
The problem MCP solves
A language model on its own is a very smart text box. It can reason, summarize, and write code, but it cannot do anything in the real world — it cannot read your files, hit an API, query a database, or restart a hashboard. To make a model useful, you have to give it hands. The industry term for those hands is “tool calling”: the model emits a structured request (“call get_miner_status with these arguments”), some piece of software actually runs that request, and the result is fed back to the model.
The trouble is that, until recently, every tool integration was a one-off. If you wanted Claude to read your Notion, someone wrote a Claude-to-Notion bridge. If you wanted a different agent to read the same Notion, someone wrote that bridge again from scratch. Multiply that by every model, every app, and every data source, and you get the classic N-times-M integration mess — a combinatorial explosion of glue code that nobody wants to maintain.
MCP collapses that mess into a single, reusable contract. Build one MCP server for a tool, and any MCP-aware agent can use it. Build one MCP client into an agent, and it can talk to any MCP server. That is the same trick the web pulled with HTTP and the same trick USB pulled with the port on the side of your laptop: agree on one interface once, and the ecosystem stops re-soldering connectors.
Model Context Protocol explained: how it actually works
MCP is a client-server protocol. There are two roles, and the naming trips people up at first, so it is worth being precise:
- MCP host / client — the application the agent lives in (a coding agent, a chat client, an IDE). It speaks MCP and decides which servers to connect to.
- MCP server — a small program that exposes capabilities to the agent. It is the thing that knows how to read a file, query an API, or talk to a device.
The server advertises three kinds of capabilities, and understanding the difference is most of understanding MCP:
| Primitive | What it is | Mining-world example |
|---|---|---|
| Tools | Functions the agent can call to do something (with side effects) | set_power_profile, restart_hashboard |
| Resources | Read-only data the agent can pull into its context | Live hashrate, chip temperatures, error logs |
| Prompts | Reusable prompt templates the server offers the user/agent | “Diagnose a dead hashboard” workflow |
When the agent starts, it asks each connected MCP server, “what can you do?” The server replies with a machine-readable description of its tools, resources, and prompts — names, descriptions, and the exact shape of the arguments each one expects. The agent now knows the menu. When you ask it to do something, the model decides which tool fits, fills in the arguments, and sends the call. The server executes it and returns a structured result. The model reads that result and continues. That loop — discover, call, read, continue — is the entire dance.
Under the hood, MCP uses JSON-RPC messages and can run over a local pipe (the server runs as a process on your own machine) or over a network transport. The crucial point for sovereignty-minded readers: a local MCP server runs on your hardware. The agent talks to it on your own machine or your own LAN. Nothing about the protocol forces your miner’s telemetry through someone else’s cloud.
Where Claude MCP and “agent tool calling” fit
You will often hear “Claude MCP” because Claude’s clients were among the early adopters of the standard, and a coding agent like Claude Code is a natural MCP host — it is already in your terminal, already reading your files, already running commands. But MCP is deliberately not tied to one model or one vendor. It is an open specification. Other agents and clients implement it too, which is the entire point: write the server once, and whatever agent the pleb prefers next year can still use it.
“Agent tool calling” is the generic capability; MCP is the standardized way to expose those tools so they are portable. Think of tool calling as the ability and MCP as the connector standard that stops you from rewriting that ability for every app. The shoulders this stands on are real: the broader open-tooling and agent community spent years building bespoke function-calling glue before a shared standard emerged, and MCP is the consolidation of those lessons, not a bolt from the blue.
Why this matters to Bitcoiners: the DCENT_axe worked example
Here is where the abstraction earns its keep. A Bitcoin miner — whether it is a bitaxe on your desk or an industrial Antminer in the garage — is just a device with a control interface. It reports status, accepts configuration, and runs jobs. That is precisely the kind of thing an MCP server can wrap. Expose “read the hashrate” as a resource and “change the power profile” as a tool, and suddenly your agent can manage the machine the same way it manages your code.
That is the DCENT_axe MCP idea: a worked, Bitcoin-native example of the Model Context Protocol. You run a local agent, point it at an MCP server that speaks to your miner, and you control your own hardware with your own agent — locally, on your terms. Ask it in plain language to check on your fleet, to tune a unit down when grid prices spike, or to pull the last hour of error codes, and the agent translates that into MCP tool calls against your device. No third-party dashboard sitting between you and your machine. No telemetry shipped off to a SaaS you do not control.
This is the same decentralization throughline that runs through everything we build: own your data, own your compute, own your code, and now own the control loop too. An MCP server you run yourself is one more layer decentralized. For the deeper hands-on flow — wiring an agent to a miner step by step — see the dedicated walkthrough on controlling your miner with a coding agent, and the broader picture in the pleb’s guide to self-hosted AI.
Local-first MCP: keep it on your own iron
The reason this fits the sovereign stack so cleanly is that MCP does not require the cloud. You can run the host agent on a local model, run the MCP server on the same box or on your node, and keep the whole thing air-gapped if you want to. That is the difference between renting your automation and owning it. If you would rather your agent never phone home at all, the approach in running coding agents fully offline pairs naturally with a local MCP server, and running an agent on your Bitcoin node shows the same self-hosting instinct applied to a node.
MCP also composes with the other agent-economy primitives. An MCP tool can sit behind a Lightning paywall, so an agent pays per call in sats — we covered exactly that pattern in our piece on an MCP tool that pays per call over L402. That is MCP as the connector and Lightning as the meter: open tools, sound money, no middleman.
A quick mental model to remember it by
- Tool calling is giving the model hands.
- MCP is the standard wall socket those hands plug into, so you wire each device once.
- An MCP server is the adapter for one specific thing — your files, an API, or your miner.
- Local-first means the socket and the adapter live on your hardware, not a vendor’s.
Frequently asked questions
What does MCP stand for?
MCP stands for Model Context Protocol. It is an open standard for connecting AI agents to external tools and data through one common interface, so the same tool works across different agents instead of needing a custom integration each time.
What is an MCP server?
An MCP server is a small program that exposes capabilities — tools (actions), resources (read-only data), and prompts (templates) — to an MCP-aware agent. You can run one locally on your own machine, which is how you let an agent read or control something like your miner without routing through a third-party cloud.
Is MCP only for Claude?
No. People say “Claude MCP” because Claude clients were early adopters, but MCP is an open, vendor-neutral specification. Other agents and clients implement it too, which is the whole point — you write a server once and any MCP-capable agent can use it.
How does MCP relate to controlling a Bitcoin miner?
A miner is a device with a control interface, which is exactly what an MCP server can wrap. Expose “read hashrate” as a resource and “change power profile” as a tool, and your agent can manage the hardware in plain language — locally, on your own machine, with no SaaS dashboard in the middle. That is the DCENT_axe MCP example.
The bottom line
MCP is not hype, and it is not complicated once the jargon is stripped away: it is the agreed-upon way to give AI agents hands, in a form that is portable across agents and — crucially for us — runnable on your own hardware. For Bitcoiners, that turns “AI agent” from a cloud novelty into a sovereignty tool: your agent, your miner, your control loop, no intermediary.
We are building toward exactly this future at the firmware layer. DCENT_OS is the first open-source firmware aimed at industrial Antminer hardware — written in Rust, targeting a 0% mandatory dev fee, currently in active beta on the Antminer S9 with S19/S21 incoming, GPL-3.0, with a public beta planned for summer 2026. It is built on the shoulders of Braiins OS+, VNish, and LuxOS, and it is the natural place for open, agent-friendly miner control to live. If owning your control loop appeals to you, join the beta from the DCENT_OS page, grab the web flasher at D-Central’s flasher, and explore the rest of our local-AI and sovereignty work in the D-Central AI section. One more layer decentralized — your code, your compute, your machine.
