Tools, MCP & Approvals

When you chat in Lattis (or run its built-in agent, Sawyer), the model can do real work on your behalf — read files, check git status, drive project tasks, and call tools you’ve connected. This page covers what’s available and, just as important, how Lattis keeps you in control of it.

How the model uses tools

Rather than show the model a giant catalog of tools on every message, Lattis keeps a small, fixed surface: the model searches for a tool when it needs one, then calls it. The practical upshot for you is that adding lots of tools (or whole MCP servers, below) doesn’t slow chats down or run up your token bill — capability grows without bloating every request. You see each call and its result inline in the conversation.

Built-in tools

Out of the box, the model can:

• Read files in the current project (sandboxed to that worktree).
• Check git status for the project.
• Work with projects — list worktrees and branch stats, and, with your approval, create a worktree, run a build, or launch an agent.

Connect your own tools (MCP)

Lattis is an MCP client, so you can plug in any Model Context Protocol server — your issue tracker, a docs search, an internal API — and its tools become available to the model.

Add one under Settings → MCP: give the command and arguments to launch the server (for example, an npx package) and enable it. Lattis connects, indexes its tools behind the search surface, and they’re immediately usable — no restart needed. Remove a server and its tools disappear just as live.

Remote (HTTP) servers

Besides local command-launched servers, Lattis connects to remote Streamable-HTTP MCP servers by URL. For servers that require sign-in, Lattis supports OAuth 2.1 — it discovers the server’s authorization metadata, registers a client, runs the browser sign-in, and refreshes tokens transparently; a server can also use a static bearer token. A server needing auth shows a Sign-in required pill with a Connect / Re-authenticate button, and its tools come online once you’ve authorized — no restart.

Also available to launched agents

The servers you connect here aren’t only for in-app chat — Lattis also fans them out to any Claude Code, Codex, or opencode session you launch in a project, so you configure MCP once instead of per-agent. This replaces relying on Claude Code’s own claude.ai-account-scoped Connections, which follow whichever account you’re manually logged into on this machine — not necessarily the account a Lattis project is actually configured with — and are shared across every Claude Code session on the machine (a bare terminal, VS Code, every Lattis project) regardless of which project you’re in. Turn the fan-out off entirely in your configuration:

"agent": {
  "mcp_fanout": false
}

By default, a launched agent sees every server you’ve connected. To scope a project to a specific subset instead — for example, two different Jira instances across two clients, each project talking only to its own — pick the servers from that project’s settings screen, the same way you pin an account to a project. An unscoped project inherits every connected server, as before; changing a project’s selection reaches an already-launched session on its next tool refresh, without needing a restart.

Allow (or block) MCP servers an agent picks up on its own

Lattis’s fan-out is additive by default: a launched Claude Code session still also loads whatever it would anyway on its own — project .mcp.json files, servers in your user-level ~/.claude.json, plugin-provided servers, and claude.ai’s own account-scoped Connections. If you’d rather an agent see only what you’ve explicitly connected through Lattis, turn off Allow agents to also use MCP servers they pick up on their own in Settings → MCP. A project can override this either way from its own settings screen — useful if you want it off everywhere except one project that still needs its own local .mcp.json, or on everywhere except one project you want fully locked down to Lattis’s list.

This is currently Claude Code only — Codex and opencode have no confirmed equivalent way to exclude their own local config yet, so the switch doesn’t affect them.

Running code

Lattis can also let the model run small pieces of code to compute an answer or glue tool calls together — the code execution tool. It’s sandboxed: the code can call the allow-listed tools above, but it has no file access, no network, and no system access of its own, and it’s bounded in time and memory.

Code execution is on by default and labelled experimental. You can narrow it to specific models, or turn it off entirely, in your configuration:

"agent": {
  "code_exec_enabled": true,
  "code_exec_models": ["claude-opus-4-8"]
}

Leave code_exec_models empty to allow all models, or list models to restrict it to them. Set code_exec_enabled to false to disable it.

Approvals: nothing risky runs without you

Reading is free, but anything that changes your repo or machine — creating a worktree, running a build, launching an agent — stops and asks first. When the model wants to do one of these, Lattis shows an approve/deny prompt naming the action and summarizing it in plain language. Nothing happens until you approve.

• Approve and the action runs, and stays approved for the rest of that conversation, so you’re not re-asked every turn.
• Deny and it doesn’t run.
• A new conversation starts fresh — approvals don’t carry over, by design.

Every decision is recorded, so there’s always a trail of what ran and what you allowed.

Next

• Skills — reusable instructions that build on these tools.
• Conversations — where you see tools in action.