Tools and Egress
Server-executed tools let a model act (fetch a page, search the web, read a file) instead of just answer. Power like that is governed, not assumed: this guide covers the layers that decide WHAT may run and WHERE it may reach, and how the same governance extends to agents connected over MCP.
1The layers, outermost first#
| Layer | Decides | Where |
|---|---|---|
| Tools toggle | Whether server-executed tools exist at all | Tools section |
| Tools policy | Which tools are enabled for chat, from the catalog | Tools section, per tool |
| Per-key tool grants | Which of the policy's tools ONE key may use; a grant can only narrow the policy, never widen it | Access section, per key |
| Egress gate | Which hosts network-touching tools may reach | Tools section |
A tool runs only when every layer agrees. A key with no grants follows the policy; a key with grants is confined to them; a locked-down key runs nothing.
This guide covers the governance. The end-to-end story of connecting Claude, IDEs, and other harnesses to this server's tools is The MCP Server.
2The egress gate#
Tools that touch the network pass one gate with two modes:
- Public web (the default): requests may reach public internet hosts, and the gate REFUSES anything that resolves to a private, loopback, or link-local address, so a model can never be steered into probing the server's own network.
- Allowlist: only the hosts you name, nothing else.
In either mode, deliberate intranet exceptions can be named explicitly (one host per line): those are the only names allowed to resolve to non-public addresses. A configuration that predates the mode setting but names hosts keeps its restrictive meaning.
3One catalog, one discipline#
Each built-in tool does exactly one thing (one tool, one operation), carries its own risk metadata, and is listed in the Tools section with what it may touch. That granularity is what makes the policy layers meaningful: allowing "HTTP GET" never smuggles in "HTTP POST", and denying one operation never requires denying a family.
4MCP exposure#
The MCP endpoint exposes document tools to connected agents (IDEs, assistants, Claude Code).
Exposure is governed the same way: the MCP section decides which tools the
endpoint offers, the connection page shows the live catalog exactly as the endpoint
serves it, and callers authenticate with the same keys as every other surface (see
Keys and Authentication). An agent is just another caller: its key's grants
and the egress gate apply unchanged. Clients that launch their MCP servers as child
processes over standard input and output connect through the
lmkit mcp bridge instead of the HTTP endpoint directly.
5Stated plainly#
- Tools are opt-in, per tool, and narrowable per key; nothing a key carries widens the policy.
- The egress gate's default protects your own network first: private ranges are unreachable unless you name the exception yourself.
- MCP adds an audience, not an exception: same tools, same keys, same gates.