MCP Already Connects Your AI to Everything. So What Would DoSync Add?

If you've connected an AI assistant to anything this year, your calendar, your files, a database, GitHub, there's a good chance MCP was doing the connecting. The Model Context Protocol has quietly become the standard way an AI reaches beyond its chat window: one

protocol, thousands of tools, plug and play. It's genuinely good, and it's everywhere.

So when a project like DoSync shows up describing itself as a protocol between AI and physical devices, the fair question is: why would I need that? My AI already calls tools through MCP. Isn't controlling a lamp just another tool call?

That's the right question, people keep searching for the difference between MCP and DoSync as if they were rivals, and I want to answer it honestly, including the part where the answer is "you probably don't need DoSync." Full disclosure before anything

else: I build DoSync. Read everything below with that in mind.

What MCP is, precisely

MCP is an open protocol, introduced by Anthropic, that standardizes how an AI application connects to tools and data. Before it, every integration was bespoke: one connector for your calendar, another for your database, each written against each AI product. MCP replaces that with a single contract, an AI client on one side, any number of "MCP servers" on the other, each server exposing tools the model can discover and call.

The metaphor everyone uses is USB-C, and it's earned: one port, anything plugs in. To say it precisely rather than metaphorically: MCP defines how a model discovers what tools exist and invokes them, it moves the request and the result, faithfully, in both

directions. What the tool actually does when called is entirely the tool's business.

Transport isn't judgment, and that's not a flaw, it's the design. Keep that phrase, the whole rest of this post hangs on it.

When to use it: whenever an AI needs to reach something outside itself. Which today is almost always. If your AI reads your email, queries a database, or files a ticket, MCP is the right layer, and it is complete for that job. Nothing below changes that.

What DoSync is, precisely

DoSync is an open protocol (Apache 2.0) that sits between an AI and physical devices, lights, locks, sensors, alarms. It does one job: it turns a goal expressed in plain terms into a coordinated, supervised, recorded set of physical actions.

The word doing the work there is goal. You don't send DoSync "turn on lamp 3, then lamp 4, then unlock the door." You send it an intent, ensure_safety and a resolver (the part that works out which devices matter) matches it against capabilities the devices

themselves declared when they joined. Then three things happen that no generic tool layer does for you:

• 
  The operator's own rules apply. Policies are a space's standing rules, declared in a file its operator controls — "never unlock these doors overnight," "this zone stays out of alarm patterns," "sirens need explicit confirmation." The AI doesn't need to remember these, and can't talk its way around them.


• 
  Every action is recorded in a tamper-evident audit log — what acted, when, and why, in a hash chain where altering history is detectable. Not a debug log: a record you could show someone afterward.


• 
  Completion is confirmed, not assumed. A command being accepted is not the same as it being done — DoSync waits for the device to confirm reality before calling a step finished.

When to use it: when the "tool" your AI is calling is the physical world, and getting it wrong has consequences beyond a failed API call.

They're not rivals. One literally speaks the other.

Here's the part that dissolves the versus framing: DoSync ships as an MCP server. The way an AI reaches DoSync is MCP.

Picture any building full of devices, an office, a clinic, a warehouse, a store. It's 2 a.m. and something goes wrong. The person responsible types one sentence to an AI: "there's an emergency in the building." Corridor lights go to full, exit doors unlock, the alarm fires, the on-call people get a message, as one coordinated response, not twenty lucky ones. Walk backward through what happened: the model understood the sentence (that's the AI), found and called a tool named dosync_fire_intent (that's MCP doing exactly its job — delivering the call), and that one call became a coordinated, recorded response across every relevant device (that's DoSync). Three layers, one loop, zero conflict. (This isn't hypothetical machinery, to be clear, the reference implementation runs this exact loop 24/7 on real hardware; the scenario is generic because the protocol is: nothing in it assumes what kind of building it's serving.)

Now give the building one rule of its own, because every real one has them. Say it's a care facility, and one wing houses patients who must never be startled by flashing lights — so the operator declared a policy: that wing's lights stay out of alarm patterns. No exceptions. Not even in an emergency. When the emergency fires, the resolver proposes — correctly — every device capable of helping, including those lights: they genuinely can flash, and they truthfully say so. The policy removes them before anything fires, and the record shows both facts: what was proposed, and what the

building's own rules decided. Notice that nobody made a mistake, not the model, not the transport, not the resolver. Everyone did their job right, and the operator's judgment about their own building still had the last word. That's the layer.

At a glance:

What DoSync adds to MCP

If you're building agents that touch the physical world, DoSync makes MCP safer to use seriously:

• 
  One tool instead of fifty. Without a coordination layer, an agent controlling a building full of devices needs a tool per device per action, and the model has to orchestrate twenty calls correctly, in order, under pressure. With DoSync, the agent calls one tool with one goal — the orchestration happens below, deterministically, where a language model's bad day can't scramble it.


• 
  A place for the owner's rules to live. MCP deliberately has no opinion about what a tool should refuse — that's the tool's job. DoSync is where those refusals are declared once, by the human who owns the space, and enforced regardless of what the AI asks for.


• 
  A record. When an agent acts on the world, "what exactly happened and why" stops being a debugging question and becomes an accountability one.

What MCP adds to DoSync

This direction matters just as much, and it's the reason DoSync didn't invent its own AI interface:

• 
  Every MCP-speaking AI is already a DoSync client. Claude today; any model or agent framework that speaks MCP, tomorrow, no per-model integration, no SDK to maintain. MCP gave DoSync its entire front door for free.


• 
  The intelligence stays where it belongs. DoSync deliberately contains no language model. Understanding "make sure everything's safe for the night" is the AI's craft; MCP is what lets that understanding arrive as a clean, structured intent. DoSync gets smarter every time the models do, without changing a line.

That's the honest shape of it: MCP without something like DoSync can reach the physical world but brings no judgment to it. DoSync without MCP would be a nervous system with no brain attached. Each one makes the other worth more.

And here's the part most projects won't say

For the vast majority of what people use MCP for today — email, calendars, code, files, databases — you do not need DoSync. MCP alone is complete for that, full stop. Even for casual device control — "turn on the porch light" — an MCP server for your smart-home platform covers it, and adding a coordination layer would be infrastructure earning you nothing.

DoSync earns its place only when three things matter at the same time: one goal has to fan out across many devices reliably, the operator's own rules must hold even when the AI is wrong, and you need a trustworthy record of what acted and why. A cold-chain failure in a store at 3 a.m. — the manager woken, the sector locked, maintenance dispatched, before the stock is lost, with proof afterward of exactly what fired and why. That's the narrow set of cases, and it looks the same whether the building is a store, a clinic, or a home. Outside it, stay with MCP alone and enjoy it — that's not modesty, it's me not selling you a layer you won't use.

How they actually fit together

The picture isn't MCP versus DoSync. It's a loop: the AI thinks, MCP connects, DoSync acts with judgment — and telemetry closes the circle back to the AI. If you're building

agents that stop at screens, you already have everything you need. If yours are starting to reach into the world, that last layer is the part I've been building — and if you're not sure which side of the line you're on, open an issue describing your case and I'll

tell you straight.

GitHub: https://github.com/giulianireg-spec/dosync-protocol

Web (with a 2-minute live demo): https://dosync.dev/

License: Apache 2.0