MCPWire lets a teammate's AI agent use a tool running on your machine

The problem it targets

MCP, short for Model Context Protocol, is a common standard that lets AI assistants plug into tools and data. A tool that works on your laptop often depends on things that a teammate does not have: credentials, a local database, an internal network or a browser session. Copying the configuration may not be enough.

As dev.to reported, the developer behind MCPWire built it to share the existing environment instead of rebuilding it. The server process and its configured credentials stay on the host's machine, and the teammate's agent reaches them through a bridge.

How the two halves connect

MCPWire has two commands. share runs on the host and starts the existing MCP server as a child process. join runs on the guest and presents itself to the guest's AI client as an ordinary local server, so the client needs no special support.

When sharing starts, the host generates 32 random bytes and encodes them as a wire:// ticket. Both sides use it as a meeting point on Hyperswarm, a peer-to-peer discovery network, and the connection is encrypted with the Noise protocol. MCPWire runs no relay service of its own.

That has a cost. The connection tries to punch through home and office routers, and a strict firewall can block it even when the ticket is correct. The ticket is also not tied to a named person, so it should be treated like a password and sent through a trusted channel. It stays valid while the host session runs, and a new session creates a new one.

Each guest gets its own server process, so their sessions do not mix in memory. They can still reach the same files, databases and services, because this is not an operating-system sandbox.

What the host can control

The host lists which tools the guest may use. MCPWire filters the tool list the guest sees, and it checks the tool name again when a call arrives. The second check matters because a client can send a call for a hidden tool anyway. An explicit deny beats an allow, and an empty allowlist permits nothing.

• --confirm asks the host to approve calls in the terminal. Approving a tool for the whole session applies to every guest, not just one.
• --ttl sets a time limit and --max-calls caps forwarded calls across all peers.
• --redact-secrets scans outgoing messages for known secret patterns and replaces matches with a placeholder.

None of these is on by default, so a careless host gets very little protection.

Where the protection stops

Allowing a tool controls which operation can be requested. It does not control what the tool does with its input. Allowing a file-reading tool still leaves path rules to the filesystem server, and allowing a database tool says nothing about whether a query can change data. MCPWire does not inspect arguments, filter MCP resources or prompts, or restrict the child process.

Keeping a credential local also does not keep data local. A tool can use your credential to fetch information and return it to the guest. Redaction can miss a private value or alter harmless output, so it is a partial check. The practical advice is to use limited-permission credentials and a narrowly set up server, even when only one tool is exposed.

Failures are awkward too. If a guest disconnects, the host asks for that guest's server process to stop, but that cannot undo a write already committed. MCPWire does not replay calls, since a retry could repeat the write. The optional session recorder keeps the ticket, the server command and unredacted argument previews, so a recording can itself hold sensitive data.

Where it fits

The design suits temporary collaboration: a teammate borrows your environment for a while, then the session ends. For a permanent team endpoint, needs such as named-user login, central policy and dependable connectivity may point to a hosted setup instead. The project looks early-stage and no price is stated.

The author's own summary is that execution stays on the host with a few controls in front, while argument checks, data permissions and recovery from unclear outcomes stay with the underlying systems. A remote agent can be limited only as tightly as those systems allow.