HTTP local endpoint

One streamable HTTP address on this Mac’s loopback, off until you switch it on, for an assistant that cannot start a program: a container, a VM, a runner, or a client that takes only a URL.

The endpoint exists for the cases stdio cannot serve. Those are an assistant running in a container or a VM, a CI runner, or a script: anything that cannot spawn a process inside your user session, or that takes a URL and nothing else.

It is off until you switch it on, in Pomeroy’s Connections pane under Local address.

The address

http://127.0.0.1:13579/mcp

A streamable HTTP server on loopback. 127.0.0.1 is this Mac’s own address, which no other machine can route to: the endpoint is not bound to your Wi-Fi address, not bound to 0.0.0.0, and there is no interface picker that widens it. A test in Pomeroy’s own repository fails if that ever changes.

The commonest shape an assistant wants it in, with the token Pomeroy generates:

{
  "mcpServers": {
    "pomeroy": {
      "type": "http",
      "url": "http://127.0.0.1:13579/mcp",
      "headers": {
        "Authorization": "Bearer <the key Pomeroy generates>"
      }
    }
  }
}

Clients spell the transport differently (http, streamable-http, streamableHttp, streamable, remote), and some want serverUrl, httpUrl or baseUrl rather than url. Your assistant’s own page has the exact one it takes. Find yours.

You do not normally type any of this. Pomeroy writes the address, and in Token mode the token, into the settings of every assistant it can reach.

What guards the endpoint

A Unix socket is gated by file permissions; a TCP port is not. Any process on your Mac can open a local port. That is why the endpoint is credentialled by default and why it binds only to this Mac’s own loopback address, and never to an address another machine could route to.

The credential belongs to the endpoint, not to a connection. There is exactly one, and you choose which kind from three modes that each admit exactly one thing.

Mode	What the door accepts	What Pomeroy writes into an assistant
Token (default)	One secret, compared against the token on your Mac	The token, into every assistant it can reach
Approval	Only a credential Pomeroy’s own authorization server issued	Nothing. The client asks for itself
Open	A request with no credential, and nothing else	Nothing. You copy the address

The modes are exclusive. A mode that named a credential and then admitted a different one would not be a mode, so in Token and Open the approval endpoints are not merely unused: they return 404.

Token

One bearer token for the whole address, pomeroy_ and 32 random bytes. Pomeroy writes it into the settings of every assistant it can reach, and shows it, behind Reveal, for anything it cannot: a script, a container, or a request made by hand.

Approval

No shared secret at all. A client registers itself, asks, and you answer in a Pomeroy window; what it gets is its own, revocable on its own. Deny is the button the Return key presses.

Use this in front of a tunnel, or anywhere the token would have to be copied somewhere you would rather it were not.

Open

Open is a real choice and a real risk: it means any process running as you on this Mac can call your tools, and read your mail and messages through them. Nothing is checked.

It exists because a buyer with a locked-down runner may prefer to gate at the network layer instead, and because the alternative to offering it is people leaving a token in a shell history.

Who is on the other end

Whatever the mode, the name on a connection row is what the assistant calls itself in its opening request, rather than a checked identity, and Pomeroy labels it that way. The row also says how it got its credential: set up by Pomeroy, approved by you, or came in with nothing.

Ask me before a new assistant connects adds a prompt to the other modes.

Containers and virtual machines

	Reaches the endpoint
Docker Desktop containers	Yes
Dev containers	Yes
UTM, Parallels, VMware Fusion on shared or NAT networking	No

A container on Docker Desktop reaches it because what arrives is a real connection from a process on the Mac. A virtual machine on its own subnet is somewhere 127.0.0.1 cannot be reached from, and needs a forwarder you run.

Another computer cannot reach it

Not on its own. The endpoint answers only on this Mac and refuses every other network interface. Pomeroy embeds no tunnel and runs no relay, so nothing in the app can put your Mac on the internet.

You may put your own tunnel in front of it. That is your Mac and your decision, Pomeroy neither helps nor blocks it, and it is worth being clear about the trade: on this Mac the token guards a door only programs already running here can knock on; on a public address that same token becomes the whole boundary against everyone, carrying your mail and messages behind it. Use Approval mode if you do it, and treat the tunnel’s own authentication as the real gate.

Why cloud assistants still cannot connect · What can reach Pomeroy