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

> Source: <https://dev.to/giulianiregspec/mcp-already-connects-your-ai-to-everything-so-what-would-dosync-add-49ef>
> Published: 2026-07-18 20:17:52+00:00

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.

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.

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:

**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.

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:

MCP |
DoSync |
|
|---|---|---|
What is it? |
A standard for connecting AI to tools and data | A semantic layer between AI and physical devices |
What does it solve? |
Discovery and invocation — one protocol instead of bespoke integrations | Coordination and judgment — goals become supervised physical action |
The unit of work |
A tool call | An intent |
Who decides what's safe? |
The tool being called | The operator's declared policies |
Where does it run? |
Wherever client and servers live — local or cloud | Locally, in the building it serves — no cloud required |
Use it when... |
Your AI needs to reach anything external |
The thing being reached is the physical world, and mistakes have consequences |
Made by |
Anthropic (open protocol) | One independent dev (open, Apache 2.0) |

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

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

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.

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.

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](https://github.com/giulianireg-spec/dosync-protocol)

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

License: Apache 2.0