An open standard · Released April 2026

Every physical device,
a native MCP Server.

PhysMCP is the open standard that lets AI agents talk directly to the physical world. No gateway. No proprietary platform. No translation layer. A mesh of devices, each speaking the Model Context Protocol natively.
StatusWorking Draft
Version0.1
LicenseCC-BY-SA 4.0
Reference SDKApache 2.0
AuthorsEnthalpyDW
Hero illustration: network of physical devices connected directly to an LLM agent
§01 — The Inversion

The gateway was a workaround, not a feature.

Industrial IoT was architected for hardware that no longer exists. Devices were dumb, networks were brittle, intelligence had to live elsewhere. Every constraint that justified the centralized hub has dissolved — but the architecture survived as inertia.

Yesterday's stack

Sensor → Cloud → Hub → Translator → Agent

Five layers of abstraction. Vendor-locked gateways at $50,000 USD per site. Each integration is a custom project. Each agent is a fragile bridge to physical reality. The LLM never reaches the device — it negotiates with a translator that negotiates with another translator.

Legacy chain diagram: Sensor → Cloud → Hub → Translator → Agent
PhysMCP

Device ⇌ Agent

One layer. The device is the MCP Server. Devices form a mesh. Agents connect anywhere on the mesh and reach everything through semantic discovery. No translator. No vendor lock-in. No five-figure gateway. The LLM speaks directly to the physical world.

PhysMCP diagram: LLM agent connecting directly to a mesh of devices
§02 — The Vocabulary

Three verbs.
One closed lexicon.

The standard defines exactly three tool patterns. Two for action. One for negotiation. Anything more is implementation. Anything less breaks the contract.

→ READ

read_capability

Retrieves a value from the physical world. Strongly typed. Semantically tagged. Each capability is a distinct MCP tool with its own schema, range, and unit.

tool: read_temperature_0 returns: value: 24.7 unit: celsius quality: good
→ DO

do_capability

Acts upon the physical world. Validated against ranges declared in the manifest. Enforced by local policy on the device itself. No central bypass possible.

tool: do_fan_speed_0 input: value: 70 range: [0, 100] side_effects: [noise, energy]
→ NEGOTIATE

can_do

Asks the mesh whether an intent is feasible. Returns candidates, blocked devices, current state, and side effects — in a single round trip. Routed semantically across the mesh.

query: tags: [cooling, zone_3] candidates: - do_fan_speed_0 - do_hvac_setpoint_0 blocked: [offline]
§03 — The Mesh

Peer-to-peer by default.
Gateway-optional by design.

The standard treats devices as first-class citizens. Each runs its own MCP Server, enforces its own policy, and participates in a semantically-organized gossip mesh. Coordination floats — any device can coordinate any query. There is no leader to lose.

Small-world mesh topology with same-zone, same-capability, and long-distance links

Semantic gossip, not flood broadcast.

Each node maintains 8–13 active peers categorized by physical proximity, capability affinity, and topological diversity. Queries route by semantic tags, not by exhaustive search.

A can_do query for "lower temperature in Zone 3" reaches 6–10 relevant devices in 2–3 hops — not 200 devices in flood broadcast. Diameter is O(log n). Latency stays sub-second at any deployment scale.

Insight
Devices have semantic metadata. Use it for routing — not for decoration.

The floating coordinator pattern.

When an agent calls can_do, the receiving device assumes coordination duty for that single query. It dispatches, aggregates, and responds — then discards all state.

No leader election. No persistent role. If a coordinator dies mid-query, the agent retries against any other peer. The protocol is byzantine-tolerant because no node is essential.

Property
Stateless coordination. Any node, any time, no recovery.
Floating coordinator lifecycle timeline
§04 — Mesh Properties

Built for hardware that doesn't exist yet.

Every property of the mesh layer was chosen assuming hardware capability is on a 10× / 5-year curve. Today, every constraint cited as a problem is solvable. Tomorrow, the constraints will not exist.

P · 01

SWIM-based gossip

Membership and metadata propagation via the same proven protocol that runs Cassandra, Consul, and Redis Cluster. Convergence is O(log n) rounds. Tolerance to failure is built in.

P · 02

Small-world topology

Three peer slot categories — same_zone, same_capability, long_distance — produce graphs with logarithmic diameter and high clustering. Queries converge fast even in large meshes.

P · 03

Quorum protection

Critical actuators declare quorum requirements. During network splits, devices that cannot see enough peers refuse dangerous actions. Split-brain on safety-critical hardware is structurally prevented.

P · 04

Self-healing partitions

Suspected partitions trigger intensified scouting. Reconnection runs a deterministic merge protocol. No operator intervention required to recover from network splits.

§05 — Declarative Bindings

A device is what its manifest declares.

The manifest maps semantic capabilities to physical interfaces. Each tool's name, type, range, unit, and binding lives in a single declarative YAML file. Implementation reads from the manifest. The LLM reads from the same source.

Manifest example

An HVAC controller exposing one read and one do, with full semantic tags, ranges, side effects, and policy hints.

# physmcp.manifest.yml device: id: node_hvac_zone3_007 type: hvac_controller location: zone: zone_3 capabilities: - name: temperature_zone_3 kind: read binding: type: i2c address: "0x48:reg=0x00" unit: celsius semantic_tags: [temperature, hvac, zone_3] - name: setpoint_0 kind: do binding: type: modbus address: "slave=1:reg=40001" range: [18, 26] semantic_tags: [cooling, hvac, zone_3] requires_permission: operator

CapabilityReport

The canonical response to any can_do. Every candidate, every blocked option, every relevant context — in a single round trip.

// can_do response { "feasible": true, "candidates": [ { "device_id": "node_001", "capability": "do_fan_speed_0", "confidence": 0.92, "current_state": {"value": 30}, "constraints": { "min": 0, "max": 100 }, "permission": "allowed" } ], "blocked": [ { "device_id": "node_012", "reason": "device_offline", "permission": "unreachable" } ], "context": { "current_observations": { "temperature": 26.8 } } }
§06 — Roadmap

The standard evolves
with the silicon.

Each version targets a hardware tier that didn't exist when the previous version shipped. The protocol stays stable across versions. The capabilities deepen as the silicon catches up.

v0.1
2026

Mesh foundation

Three-tool vocabulary, semantic gossip, floating coordinator, manifest schema, policy schema, quorum protection, partition recovery.

Target hardware · ESP32-S3 · RP2040 · Linux SBCs
v0.2
2027

On-device semantics

Quantized embeddings on the device for local can_do matching. Multi-site mesh federation. Capability composition.

Target hardware · ESP32-P4 · NPU-equipped MCUs
v0.3
2028

Local reasoning

Small language models on-device for intent parsing. Multi-modal capabilities (vision in cameras, audio in microphones). Fully offline operation as default.

Target hardware · $20 BoM with native NPU
v1.0
2029

Standard ratification

Frozen protocol surface. Backward compatibility guarantee. Certification program at scale. Multi-vendor interoperability tested across thousands of certified devices.

Target · Industry standard adoption
§07 — Ecosystem

An open standard
creates a marketplace.

Adoption compounds. Hardware manufacturers implementing PhysMCP become universally consumable. Buyers requesting PhysMCP-certified gear pull the rest of the supply chain into the standard. The flywheel is the moat.

04

Enterprise SaaS

Fleet management, observability, compliance dashboards, multi-site analytics. Built on top of the standard, not into it.

MRR / ARR
03

Skill Pack marketplace

Vertical-specific configurations: ISO/Quality, HVAC, Agriculture, HealthTech, Predictive Maintenance. Pre-bundled capabilities + policies.

Revenue share
02

Third-party certification

Hardware vendors certify devices PhysMCP-compliant. Annual fee. Conformance test suite. Listing in the certified hardware directory.

Recurring
01

Reference hardware

PhysMCP Node and PhysMCP Aggregator — the canonical implementations. Open hardware, certified by definition.

Product margin
§08 — Philosophy

Spec for capability,
not constraint.

The hardware of 2024 is a temporary embarrassment. The hardware of 2028 will run this standard without effort. Every protocol that endured was designed for the silicon that came after it — TCP/IP, HTTP, MQTT, Matter. PhysMCP is built on the same wager.
— Founding principle, PhysMCP specification
TCP/IP
1974
Designed for hardware ridiculously weaker than today's microcontrollers. The protocol waited for the silicon — and the silicon arrived.
HTTP/1.0
1996
Specified when bandwidth made it painful. Now runs the web. The standard didn't compromise to fit the era — the era grew into the standard.
MQTT
1999
Built for "millions of connected devices" when there were 50,000. There are now 21 billion connected devices. The protocol was ready.
Matter
2022
Heavy mesh stack, criticized as too much for cheap chips. Three years later, every smart home chip ships with Matter support by default.

Read the
specification.

Eleven hundred lines of protocol. Three verbs. One mesh. A complete blueprint for plugging artificial intelligence into the physical world — without permission, without intermediaries, without lock-in.