blog ·
Getting coding agents to use tools well: terminal, browser, MCP and permissions
Tools turn a coding agent from a chat partner into a worker. How well it uses them depends on what you expose, what you let it do without asking, and how you check the outcome. Practical guidance first, then how Muster Agent handles it.
The principle
Give tools that match the job, and check the evidence they leave.
A coding agent without tools can only guess. With a terminal it can run your tests, with a browser it can look at your app, and with connectors to other systems it can read an issue or query a database. Each tool also widens what can go wrong, so the aim is not “more tools” but the right few, with clear limits and visible results.
Three habits cover most of it: expose only what the task needs, decide in advance which actions need your approval, and prefer tools whose output you can read afterwards.
The terminal
Let it run things, and teach it which commands matter.
The terminal is the most useful tool you can give an agent, because it closes the loop: edit, run the tests, read the failure, fix. The agent is only as good as the commands it knows about, so tell it the three that matter: how to build, how to run the tests, how to start the app. If your test suite is slow, give it the command for a single file or a single test so it does not run everything on each iteration.
- Prefer fast, focused checks. A one-second unit test teaches the agent more per minute than a ten-minute suite.
- Watch for destructive commands. Anything that deletes, force-pushes, drops a table or touches production should never run unattended. Decide this through permissions, not through hoping the agent is careful.
- Keep long-running processes separate. A dev server should live in its own terminal tab, not block the agent’s command.
The browser
For anything a user sees, look at it.
Code that passes tests can still render wrongly. For interface work, ask the agent to open the page, look at the result and check the console for errors. A screenshot it can read, or a console message it can quote, is far better evidence than a statement that the change “should work”. Give it the URL and the path to exercise, and tell it what correct looks like.
Treat the browser as a read-heavy tool by default. Previewing and inspecting are safe. Submitting forms against real accounts, or clicking through flows that send email or move money, deserve an explicit decision from you.
MCP servers
Connect systems deliberately.
The Model Context Protocol lets an agent call tools exposed by other systems: an issue tracker, a documentation index, a database, a design tool. Each server you add enlarges what the agent can read and change, and adds descriptions to its context that cost attention. A small, well-chosen set works better than a long list.
- Start read-only. Connect a server in a mode that can fetch information before you let it write.
- Scope credentials. Give an MCP server the narrowest token that does the job, not your personal admin key.
- Remove what you do not use. Unused tools still sit in context and can be called by mistake.
Permissions
Choose how much it may do before it asks.
The permission model is the lever that lets you trust a tool-using agent. The useful question is not “is the agent safe” but “what is the worst thing it can do in this mode, and can I live with that?” A read-only mode is right for exploring an unfamiliar repository. A mode that can edit within the project folder suits normal work. Unrestricted access is for situations you have already contained, such as a disposable environment.
Combine permissions with isolation rather than relying on either alone. A narrow permission mode in a throwaway worktree is safer than broad permissions on your main checkout.
How Muster Agent handles it
Tools next to the conversation, with limits you can see.
Muster Agent is an open-source desktop app that works with several coding agents. Its tool surface is designed around the principles above.
- A real terminal. Shells sit under the chat, one tab per shell, so the dev server and the test run can run side by side. Scrollback is capped at 5,000 lines and each command’s output is kept within a bounded buffer. Your own terminals are separate from the agent’s own shell, and the app says so.
- A built-in browser. It previews your app, reads its console and lets you pick elements to hand to the agent.
- Skills, plugins and MCP servers. They have their own tabs in settings, and local skills can be switched on or off by scope.
- Three permission modes per chat. Read-only, workspace and full access. For engines that run as command-line tools, the mode is translated into the tool’s own flags. Linked files outside the folder cannot be read without full access, and secrets are removed from the environment of the commands the agent runs and from stored commands and diffs.
- Where the chat runs. A menu chooses this computer, a sandbox or a new worktree, so isolation is a choice you make per chat.
In a project organisation, an agent’s page can also hold tool rules that allow, ask or deny by command, file or connector, which is a way to write your approval policy down once rather than answer the same question repeatedly. For the containment side in more depth, see sandboxed coding agents.
A starting configuration
For a new repository: read-only first, to let the agent explore and propose a plan. Then workspace mode in a worktree for the actual change, with the terminal available and the browser for visual checks. Add MCP servers one at a time as you find a real need. Review the diff before you keep anything.