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 include every tool definition in every request, Lattis lets the model search for a tool when it needs one, then calls it. This can reduce the amount of tool metadata sent with each request, although searches and tool results still consume time and tokens. 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 connect compatible Model Context Protocol servers, such as an issue tracker, documentation search, or internal API, and expose their tools 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 also loads whatever it would pick up anyway — project .mcp.json files, servers in your user-level ~/.claude.json, plugin-provided servers, and claude.ai’s own account-scoped Connections.

Except when those belong to a different account. The CLI carries its own machine-global login, and its Connections follow that account — not the one your Lattis project is configured with. When both sides connect the same tool (say a Gmail connector on each), the ambient copy wins silently and the agent answers from the wrong mailbox. So when Lattis can see that the CLI is signed into a different organization than the account a session routes to, it excludes the agent’s own servers for that session.

The comparison is by organization, not email, because one email can hold both a Max seat and an Enterprise seat — only the organization tells them apart. When either side can’t be identified — an API-key or logged-out CLI, or an account connected before Lattis started recording this — Lattis falls back to a simpler rule: a project that pins its own accounts is excluded (it can’t vouch for config it can’t attribute), and an unpinned project is left alone. Re-authenticating an account records its organization.

This is subtractive: Lattis removes the ambient copy rather than substituting the right one. It cannot serve another account’s claude.ai Connections — there’s no way to enumerate or proxy them — so a suppressed session loses that tool unless the same tool is connected in Lattis. If you need the agent to have it, connect it here.

To change any of this, use Allow agents to also use MCP servers they pick up on their own in Settings → MCP, or set it per project from that project’s settings screen. An explicit per-project choice always wins — over the mismatch rule, over account pinning, and over the app-wide default.

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.

Claude Code’s Skills are a related, still-open gap. Personal skills in ~/.claude/skills/ and skills synced from a claude.ai account (into ~/.claude/skills/synced/) are read machine-wide by every Claude Code process, and Anthropic ships no source-level opt-out for them today — --strict-mcp-config covers MCP servers only, disableBundledSkills covers Claude Code’s own bundled skills only, and skillOverrides turns off skills one known name at a time rather than a whole source. So a launched session still sees whichever skills that machine’s Claude Code login has, regardless of the account a Lattis project is pinned to. (Checked against Anthropic’s Claude Code docs, August 2026.)

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 for selected local actions

Reading does not require approval. Actions such as creating a worktree, running a build, or launching an agent stop and ask first. Other effects, including actions performed by connected MCP servers, depend on the tool and its own permissions.

• 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.

Decisions are recorded so you can review which actions ran and which you allowed.

Next

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