Recommended agent profiles

Code reviewer

Goal: inspect repository content without modifying it.

allow_tools = ["filesystem/*"]

[mcp_servers.filesystem]
type = "stdio"
command = "tuls"
args = ["filesystem", ".", "--allow", "filesystem.read"]

Web researcher

Goal: public-web access without filesystem or shell access.

allow_tools = ["fetch/*"]

[mcp_servers.fetch]
type = "stdio"
command = "tuls"
args = ["fetch", "--allow", "network.fetch"]

Implementer

Goal: read and edit repository files without arbitrary process execution.

allow_tools = ["filesystem/*"]

[mcp_servers.filesystem]
type = "stdio"
command = "tuls"
args = [
  "filesystem",
  ".",
  "--allow",
  "filesystem.read",
  "--allow",
  "filesystem.write",
]

Test runner

Goal: run commands in addition to reading repository content.

allow_tools = [
  "filesystem/*",
  "shell/*",
]

[mcp_servers.filesystem]
type = "stdio"
command = "tuls"
args = ["filesystem", ".", "--allow", "filesystem.read"]

[mcp_servers.shell]
type = "stdio"
command = "tuls"
args = ["shell", ".", "--allow", "process.execute"]

Most privileged profile

This profile is substantially more privileged because shell is arbitrary local process execution under the OS account. Prefer a real OS/container sandbox when exposing it to an autonomous model.

Research + implementation split

For larger workflows, prefer multiple narrow agents instead of one all-powerful agent:

parent
├── researcher      -> fetch only
├── reviewer        -> filesystem.read only
└── implementer     -> filesystem.read + filesystem.write

This reduces tool confusion and limits the blast radius of a bad tool choice.

Related

• Least-privilege example — the full layered setup.
• Security model — what each layer guarantees.