Dicey Table

Get started

How the DiceyTable MCP bridge works

Your MCP app runs the bridge on your computer. Your DiceyTable tab connects to it on 127.0.0.1, or through DiceyTable's relay when it can't.

On this page7 sections

Your MCP app starts the bridge on your computer. Your DiceyTable tab connects to the bridge on 127.0.0.1 after you type a pairing code, and then every tool call travels from the agent, through the bridge, into the tab and back.

If your browser can't reach 127.0.0.1, the same messages go through DiceyTable's relay server instead. Both paths do the same work, and the tab tells you which one it's using.

The two pieces#

  • The bridge (@diceytable/mcp-bridge) runs on your computer. Your MCP app starts it and talks to it through the program's text input and output, called stdio. The bridge tells the agent which tools exist and passes each call to your tab. It also reads local files for imports, but only inside folders you allow.
  • Your DiceyTable tab runs in your browser, signed in as you. It owns every tool. A call runs through the same code a click would, with your role, your seat and your editor lease. The lease is what lets only one tab at a time change a project.

So the bridge is the messenger, and the tab does the work. That's why nothing happens until you pair a tab. Pair a DiceyTable tab with your agent shows how.

How the MCP app, the bridge, your tab and the relay connect The MCP app talks to the bridge over stdio. The bridge and your tab connect directly on 127.0.0.1 ports 47621 to 47625, which stays on your computer. If that is blocked, a dashed fallback path goes through DiceyTable's relay at api.diceytable.com/agent-relay. Your computer MCP appyour AI client bridgeruns on your computer stdio your tabdiceytable.com 127.0.0.1 :47621–47625 direct: stays on your computer relayDiceyTable serverapi.diceytable.com/agent-relay fallback
Two paths, one job. The direct path stays on your computer. The dashed relay path goes through DiceyTable when the direct one is blocked.

The path of one tool call#

Say you ask for a screenshot. Here's the trip it takes.

  1. The agent picks screenshot_viewport and your MCP app sends the call to the bridge.
  2. The bridge checks which paired tab should get it and sends it on.
  3. The tab checks the call against your key's permissions and your role on that page.
  4. The tab takes the picture and sends the image back to the bridge.
  5. The bridge hands it to your MCP app, and the agent sees the result.

The local connection#

The bridge opens a small server on 127.0.0.1, the address that always means "this computer". It's called the loopback address, and it isn't reachable from your network. The bridge listens on port 47621. If another program holds that port, it tries the next one, up to 47625. DiceyTable only looks at those five ports.

The bridge only accepts tabs from https://diceytable.com and any extra sites you add with a flag. It also checks each request's host name. So a random website can't talk to your bridge. Even a program that pretends to be the bridge can't attach your tab, because attaching needs a pass DiceyTable's server gives only to your key.

The first time Chrome or Edge connects, it asks whether DiceyTable may reach devices on your local network. That question is about this connection. Allow local network access for the bridge explains the prompt.

When does the relay step in?#

The relay is a backup path through DiceyTable's server. The tab uses it when it can't reach 127.0.0.1. That happens in Safari every time, because Safari blocks it. It also happens when you block local network access in Chrome or Edge.

Both ends of the relay must be you: the bridge with your key, and the tab with your sign-in. The relay passes each message along without reading what's inside, and it never stores or logs one. But your screenshots and table views do leave your computer on this path. The consent dialog and the agent indicator both tell you when the relay is in use. Over the relay, screenshots shrink to about 400 KB.

Want the direct path only? Start the bridge with --no-relay. Safari then can't pair at all.

What happens with several agents at once?#

Each MCP app runs its own bridge. The first one to need the port becomes the hub, the one that holds the port. Each later bridge checks that the hub really is a DiceyTable bridge, then connects through it. If the hub's app closes, another bridge takes over the port within about a third of a second, and your tabs reconnect on their own. No bridge keeps running after its app closes.

What DiceyTable's server sees#

The bridge talks to DiceyTable's server for a few things. It checks your key, starts and ends the agent session, and fetches web files for URL imports. While a session runs, it also sends a "still here" signal every 30 seconds. That signal carries counts, like how many calls ran, never what they contained. On the direct path, your tool calls and screenshots never reach our server. AI agent privacy lists exactly what leaves your computer.

Did this page answer your question?