AGENT CONTEXT / DOCS

One team. One shared context.

Connect over the same Wi-Fi, a private VPN, an SSH tunnel, or an HTTPS server.

Choose how your team connects

Run one Agent Context server with one persistent database. Every teammate connects their MCP client to that server; their coding agent and model can run on their own computer.

All examples use ./data/context.sqlite3 on the host. Run commands from the same directory, or replace it with the absolute path to your existing database. Stop the old service first if it already uses port 8765.

1. Same Wi-Fi or LAN

Find the host computer’s private IPv4 address in its network settings. For example, if it is 192.168.1.50, run this on the host. Replace that example IP in both allowlists with your actual address.

agent-context-mcp --host 0.0.0.0 --port 8765 --db ./data/context.sqlite3 --allowed-host 192.168.1.50:8765 --allowed-origin http://192.168.1.50:8765

In another host terminal, retrieve the token:

agent-context-mcp token --db ./data/context.sqlite3

Teammates on the same network open http://192.168.1.50:8765/dashboard or configure their MCP client as follows:

Transport: Streamable HTTP
URL: http://192.168.1.50:8765/mcp
Header: Authorization: Bearer <instance-token>

Allow inbound TCP port 8765 in the host firewall only from your team’s private subnet. The host must stay awake and connected. A router DHCP reservation can keep its IP stable. Guest Wi-Fi or client isolation may prevent computers from reaching each other.

Plain HTTP does not encrypt the token or project context. Use this only for a deliberate test on a trusted private network. Use a VPN, SSH tunnel, or HTTPS for encrypted team access. Do not forward port 8765 from your internet router.

2. Private VPN for different networks

A private VPN such as Tailscale or a managed WireGuard network can connect teammates without exposing the application port publicly. With Tailscale Serve, join the host and teammates to an authorized tailnet and allow access through its network policy.

On the host, use its actual Tailscale HTTPS hostname in place of the example below:

agent-context-mcp --host 127.0.0.1 --db ./data/context.sqlite3 --allowed-host machine.tailnet-name.ts.net --allowed-origin https://machine.tailnet-name.ts.net

In another host terminal, configure the private HTTPS proxy:

tailscale serve --bg http://127.0.0.1:8765
tailscale serve status

Use the exact HTTPS address reported by Serve, with /mcp appended, in each client. If its hostname differs from your allowlists, update the server command and restart it. Keep the Agent Context bearer token enabled. Serve is private to your tailnet; a public sharing feature is not required.

Tailscale team-sharing guide · Serve command reference

3. SSH tunnel

If teammates already have SSH access to the host, keep Agent Context bound to loopback:

agent-context-mcp --host 127.0.0.1 --db ./data/context.sqlite3

Each teammate opens a tunnel in their own terminal. Replace the SSH username and hostname with the host’s actual details:

ssh -N -L 8765:127.0.0.1:8765 username@server-address

Keep the tunnel open. The teammate’s client connects to http://127.0.0.1:8765/mcp with the host’s instance token. Here localhost works because SSH forwards that port to the shared server. Stop any local service using port 8765 before opening the tunnel. SSH access and firewall permissions must already be configured.

4. Always-on HTTPS server

Run the service on a persistent server, keep it on loopback, and put a TLS reverse proxy in front of it:

agent-context-mcp --host 127.0.0.1 --db ./data/context.sqlite3 --allowed-host context.example.com --allowed-origin https://context.example.com

context.example.com {
    reverse_proxy 127.0.0.1:8765
}

Point the actual domain at the server, configure the reverse proxy and TLS, and allow the needed HTTPS traffic. Teammates connect to https://context.example.com/mcp with the instance token. Configure the service to restart after reboot and back up its persistent database. See the self-hosting guide and Caddy reverse-proxy documentation.

One shared project, from every computer

Share the server endpoint and token through a private channel. Select Streamable HTTP in each agent’s MCP settings, use the same project ID, and give each session a unique agent ID. Ask one agent to record a test handoff and another to read it before starting real work.

Every token holder can access every project in that instance. There are no individual accounts or project permissions yet. Keep separate instances for unrelated teams. Teammates do not need separate local databases, and must not share a live SQLite file through a network drive.

Connection troubleshooting

• Cannot connect: check the host is awake, IP and port are correct, the firewall allows your network, and any VPN or SSH tunnel is running.
• 421: add the exact hostname or IP with its port to --allowed-host. Do not use 0.0.0.0 as the client URL.
• 403: add the dashboard’s exact browser origin, including scheme and non-default port, to --allowed-origin.
• 401: retrieve the token on the host using the same --db and credential settings as its running service.
• Empty or different history: check every client uses the same server and project ID.

These are setup recipes, not a report that a VPN, tunnel, firewall rule, or hosted server has been configured for you. Verify connectivity on your own network. The Vercel website serves documentation and downloads; it is not the shared MCP server.