Documentation

Expose your machines' capabilities to AIs

Every machine on the mesh runs software that knows things and knows how to do things: a robot controller knows its errors, a supervision system knows the state of a line, a business application knows how to trigger an action. The local MCP bridge lets any software publish those capabilities to the VIGIL client on its machine, which exposes them to the mesh. An AI assistant connected to the workspace then discovers a live inventory — which machines, which software, which capabilities — and can supervise an entire fleet without a single port being opened anywhere.

What it is for

Today, connecting an AI to a fleet of machines means custom work: every application has its own API, every machine its own network access, every site its own VPN. The local MCP bridge turns the problem around: the software declares what it can do, the machine publishes it, and the mesh transports it. The assistant has a single entry point — the workspace's MCP connector — for the whole fleet.

Live inventory

The assistant sees which machines exist, which software runs on them and which capabilities they offer — machine name, software, version, instance label.

Remote diagnostics

Retrieve a robot controller's errors, the state of a line, a log — without physical access and without exposing the machine to the Internet.

Tool-driven action

Trigger a capability — recalibration, restarting a service, an export — within the exact limits of the console's policy.

How it works: publication, lease, proxy

The mechanism rests on three ideas: the software stays in charge of its own server, publication is a lease that must be renewed, and the VIGIL client is what exposes. The software needs to know nothing about the mesh; the mesh learns nothing about the software beyond what it publishes.

1
A local MCP server on a random portThe software starts a standard MCP server on the machine's local interface (loopback), on a random port picked at launch. Nothing is reachable from the network: the port only exists for the machine itself.
2
Publication opens a leaseThe software announces to the machine's VIGIL client what it exposes: software name, version, instance label, capability description and the local port where they live. That announcement opens a short-lived lease.
3
Renew, or disappearAs long as the software runs, it renews its lease. On clean shutdown it closes it. If it crashes, the lease expires on its own: the capability vanishes from the inventory instead of lingering as a ghost.
4
The VIGIL client proxies to the meshThe VIGIL client relays calls from the mesh to the software's local port. Seen from the network, the capability belongs to the machine; seen from the software, everything arrives from loopback. No open port, no direct exposure.

Many applications, many instances

A real machine does not host “one” application: it runs several, sometimes several copies of the same one — two instances of a controller, each driving an arm. The model accounts for this from the start: the unit of publication is not the software, it is the instance.

Each instance opens its own lease, with its own random port: two copies of the same software never step on each other.
A capability's identity combines the machine, the software and an instance label (“arm-07”, “line-3”) provided at publication time.
The inventory aggregates everything: the assistant can ask which machines offer a given capability without knowing ports or processes.
The disappearance of one instance affects only that instance: the machine's other leases remain valid.

Managing a fleet with an AI assistant

The use case that motivated the design is industrial: a fleet of robots or equipment spread across several sites, each behind its own network, with no public address. Each device runs the VIGIL client; each on-board application publishes its capabilities. The assistant connects to a single place — the workspace's MCP connector — and sees the whole fleet.

Query the health of every device on a site in one tool call.
Retrieve the errors of one specific controller and correlate them with the rest of the fleet.
Trigger a maintenance action on the relevant device, if policy allows it.
Automatically document an incident: which machines, which software, which versions, which errors.

An open protocol, a VIGIL transport

The boundary is clean. The publication protocol — how software announces its capabilities, opens and renews its lease — is meant to be public, with an open-source reference bridge to integrate it in a few lines or sit next to an existing MCP server. Transport is VIGIL's job: machine identity, end-to-end encryption, traversal without open ports, the console's access policy.

The open-source bridge

A small free-software brick: it announces the software's MCP server to the VIGIL client and keeps its lease alive — the VIGIL client is what relays the calls. Embed it in an application, place it next to an existing MCP server, or use it as a front for a stdio MCP server.

Standard MCP, not a house format

Capabilities are described and called in MCP, the protocol assistants already speak. Any existing MCP server is a publication candidate, unmodified.

The mesh as the guarantee

What is proprietary is what must be guaranteed: who the machine is, who has the right, how traffic travels. The rest is open.

Security

The local MCP bridge touches two sensitive surfaces: what a local process may publish, and what a remote assistant may reach. The design bounds both.

The software's MCP server listens only on the local interface: nothing is reachable from the network, only the VIGIL client relays.
Local publication is visible and governed: live leases are shown to the machine's operator, and nothing is exposed to the mesh without the explicit consent given in the console for that device.
On the assistant side, everything goes through the workspace's MCP connector: OAuth, scopes, and inheritance of the console's rules — see /docs/plateforme-mcp.
Least privilege applies at both ends: publish few capabilities, grant few machines to each connector.
The lease limits the window for mistakes: a forgotten capability disappears on its own when its software stops.

Is the software's random port exposed on the network?

No. It listens only on the machine's local interface. Only the VIGIL client relays it, over end-to-end encrypted mesh sessions, without any port being opened on the network.

What does the assistant see if an application crashes?

Its lease stops being renewed and expires: the capability vanishes from the inventory. The assistant sees no ghost capability; it sees an instance that is no longer there — which is itself useful supervision signal.

Can an assistant reach a machine its policy does not cover?

No. Published capabilities are reached through the workspace's MCP connector, which inherits the console's rules: the machines and scopes granted to the connector bound what the assistant can see and call.

Can I publish an existing open-source MCP server as-is?

That is the point of the bridge: placed next to the server, it announces the port and keeps the lease alive — and it can act as a local front for a stdio MCP server. The VIGIL client is what relays the calls. The server does not need to know about VIGIL.