Lesson 7 of 7 · 5 min

Controlling what Atlas can do with external tools

Set a per-tool allowlist on an MCP server and understand when Atlas has to ask before acting.

Tools arrive namespaced

When a server is connected, its tools become callable by Atlas under a predictable name: mcp_ followed by the server slug followed by the tool name. The naming keeps tools from two different servers from colliding, and it makes it obvious in a chat which server an action came from.

The per-tool allowlist

Each MCP server row carries an allowlist of its tools, with a read or write badge on each one so you can tell which tools only look and which ones change something. Leave the allowlist untouched and every tool on that server is available to Atlas. Check a subset and you restrict Atlas to just those, and Pinnora saves the choice.

Picture it like handing a contractor a key ring with only the rooms you want them in. The read and write badges are the difference between a room they can look into and one they can rearrange. This is the main control for letting Atlas read a service while holding back the ability to write.

Write actions still ask

Beyond the allowlist, Atlas does not quietly perform write-shaped external actions. A tool the server reports as a write routes through an approval step, so a person confirms before anything changes on the outside service. Reads can be set to run without a prompt, per connection, since looking is safe and asking every time gets tiring.

Who can change this

Setting an allowlist, connecting a server, or removing one is owner and admin only, the same gate as every other connection on this page. Members can see what is connected and read the badges, but cannot change the permissions.

Reference

Keep going