The MCP mount — the node's entire external surface.

The tool list is declared here and nowhere else, and it is read at this module's compile: a tool whose action schemas are malformed fails the build rather than the first request. That is also why the list is written out literally instead of read from configuration — naming the modules here is what records the compile-time dependency that keeps the check from going stale.

Loopback is the security model

/mcp carries no authentication. The compensating control is that the node is not reachable from the network: ip/0 defaults to loopback, so the node binds 127.0.0.1 and nothing off-box can reach it.

A node run in a container cannot keep that pin: a process bound to loopback inside a container is unreachable through a published port, so whoever runs it there widens the bind within the container's own network namespace, and the pin moves to the host publish. That publish must then carry the 127.0.0.1: prefix itself — a -p 8012:8012 without it publishes on every interface and exposes an unauthenticated SQL surface to the LAN.

Widening the bind is a committed configuration, config :ymer_node, YmerNode.Mcp, :ip, and nothing in ymer_node widens it: the node reads that key from the application environment alone, and no variable of its own turns it on. The configuration that runs the node must not fill the key from the environment either, or a variable set at start would be enough to widen it.

Widening either layer without adding authentication first is the mistake both paragraphs exist to prevent. Scripts do not widen either layer, and they are not bounded by them: an accepted script runs with the node's own permissions and reaches whatever this process can reach, so the boundary there is which scripts are accepted rather than which interface the node binds. YmerNode's ## Scripts section states it.

Signing in to ymer is a different axis entirely — it proves the install is yours; it does not gate local calls, and no local call consults it.