Sharing Local MCP Tools Between Machines with MCPWire

A teammate's agent may utilize a tool already operating on your machine, yet running it on their end necessitates server installation, credential configuration, and replication of system access. In instances where the tool relies on local databases, internal networks, or browser sessions, simple configuration copying might prove insufficient.

To facilitate sharing the existing execution environment via MCP while retaining the server and its credentials on the host, I developed MCPWire. The guest establishes a small bridge resembling a local stdio MCP server for their client, with requests traversing a Noise-encrypted peer connection to your machine. The critical aspect lies in where execution and authority reside, as entrusting a credential to your laptop still enables others to exercise certain permissions through authorized tools.

The architecture mandates explicit delegation. MCPWire comprises two commands, 'share' on the host and 'join' on the guest, with the existing MCP server functioning as a child process on the host side. The client and server exchange newline-delimited JSON-RPC via standard input and output. On the guest, 'join' links the client's stdin and stdout to the peer socket, while diagnostic messages are directed to stderr to avoid interfering with the protocol stream.

It accommodates one host connection per 'join' process. On the host, 'share' scrutinizes traffic before forwarding it to the child process, rejecting unauthorized tool calls and modifying tool descriptors delivered to the guest. Each connected peer operates its own MCP child process, preventing shared server processes or in-memory session state.

Nonetheless, they can still access the same files, databases, and external services, without the creation of an operating-system sandbox. Discovery and session tickets Upon initiating sharing, the host generates 32 random bytes, encodes them as a wire:// ticket, and utilizes it as the discovery topic in Hyperswarm. Both sides employ this ticket as the discovery topic in Hyperswarm.

The host broadcasts on this topic, and the guest searches for a host using the identical value. The default discovery network is the public Hyperswarm DHT, with HyperDHT managing connection establishment and attempting UDP hole punching across NATs. MCPWire refrains from maintaining its own relay service, but connection establishment remains dependent on networking infrastructure and the behavior of networks at both ends.

This implies that restrictive firewalls or NAT configurations can obstruct a connection, even when developers possess internet access and possess a valid ticket. The ticket identifies the discovery topic, while the Noise connection provides encryption; the ticket itself is neither an encryption key nor an identity certificate for your teammate.

MCPWire does not associate it with a named user, necessitating handling as an access credential through a trusted channel. The ticket remains viable throughout the host session, generating a new one upon starting a new host session, instead of preserving a permanent address for that server. Custom DHT bootstrap nodes can be configured via MCPWIRE_BOOTSTRAP during network setup.

Following a tool call through the host When exposing a filesystem server with read_file and list_directory authorized, the guest's agent initiates a tools/call request via their local MCP client. The server responds with tool descriptors, which MCPWire filters using the host's policy, providing the guest with the tools permitted for that session.

Upon receiving an actual call, MCPWire validates the requested tool name prior to transmitting the request to the server's stdin. Both checks matter, as concealing write_file from the advertised list does not prevent a client from submitting a request with that name. The execution check prevents disallowed calls from reaching the child process.

The policy implementation assigns explicit denial precedence over allowance, with an omitted allowlist permitting no tools beyond those explicitly allowed. An empty allowlist prohibits all tools. With the '--confirm' flag, an allowed call additionally necessitates approval in the host terminal, where the operator can reject, approve once, or authorize that tool for the remainder of the session.

This latter choice represents shared session policy, not limited to a single guest connection. The boundary of a tool permission Granting read_file controls the permitted operation, but the filesystem server determines the valid paths and files it can read. Similarly, permitting a SQL tool provides no insight into the safety of the submitted queries, unless the server or database enforces such restrictions.

The current policy scrutinizes tool names without validating their arguments, filtering MCP resources or prompts, or restricting the child process's access to the host. Therefore, credentials with restricted permissions and a narrowly configured server remain essential, even when only one tool is exposed. This explanation elucidates the distinction between maintaining credentials locally and keeping data locally, as a tool can utilize a local credential to retrieve information, which it subsequently returns to the guest.

MCPWire precludes requiring the guest to configure this credential, yet the permitted responses still traverse the connection and enter the guest's MCP client. The optional '--redact-secrets' processing scans outbound messages for recognized patterns before transmission, substituting matches with '[REDACTED_BY_MCPWIRE]'. While pattern matching may overlook certain private values or patterns, MCPWire mitigates the need for the guest to configure those credentials.