Mirasim Build Fund$100 – $10,000in free credits for builders — nothing to repay.500 seatsApply
← The Mirasim GuideChapter 10

Skills, MCP and tools

Package your own way of working as a skill, connect the tools your stack already uses, and let agents drive a browser.

10 min read, 5 sections, in Extend & orchestrate

Skills: your knowledge, reusable#

A skill is a named, reusable packet of instructions — how to run your tests, how your deploy works, how you like a migration written — that an agent loads when the task calls for it. Skills are how hard-won local knowledge stops living only in your head and your prompt history.

In the composer, `/` lists what is available to this session: your skills alongside the agent's built-in commands. Skills install at global scope (available everywhere) or workspace scope, where they live under `<workspace>/.mirasim` beside your project — so they diff, review and version like any other code.

Managing skills
mirasim ui-cli --port 4970 skill list                       # workspace + global
mirasim ui-cli --port 4970 skill install --source https://github.com/o/r --scope global
mirasim ui-cli --port 4970 skill create --name run-our-tests --scope workspace
mirasim ui-cli --port 4970 skill update --name run-our-tests
mirasim ui-cli --port 4970 skill remove --name run-our-tests
  1. Write it for a capable stranger

    Assume the reader knows software but not your project. The command, the order, the pitfalls, and how to tell success from failure — nothing more.

  2. Keep one skill to one job

    “Run the test suite” and “cut a release” are two skills. Small skills compose; a monolith gets loaded when half of it does not apply.

  3. Let a session draft it, then edit it yourself

    After an agent does something well — a tricky deploy, a clean migration — ask it to write up what it just did as a skill. The edit afterwards is where your judgment enters.

MCP servers#

Tools reach agents through the Model Context Protocol. Add a server once — as a local command or a URL, with its own environment — and its tools become available alongside the built-ins. Servers resolve from global or workspace scope, and Mirasim shows both the ones it manages and the ones an agent brought itself.

Add, toggle and health-check a server
mirasim ui-cli --port 4970 mcp list
mirasim ui-cli --port 4970 mcp add --name gh \
  --command npx --args "-y,@some/mcp-server" --scope global
mirasim ui-cli --port 4970 mcp toggle --name gh --enabled false
mirasim ui-cli --port 4970 mcp health --name gh     # live handshake probe

Connectors#

Connectors are a curated catalog on top of MCP: install one, hand it its secrets or run it remotely, and enable it per agent so a tool is not forced on every session. Installation is a real lifecycle — validate it against the live service, re-run its OAuth grant when a token expires, and deregister it cleanly, revoking and tombstoning rather than leaving a dead entry behind.

Connector lifecycle
mirasim ui-cli --port 4970 connectors list
mirasim ui-cli --port 4970 connectors install SOME_ID --mode remote --secret KEY=value
mirasim ui-cli --port 4970 connectors enable SOME_ID --agent claude
mirasim ui-cli --port 4970 connectors validate SOME_ID    # records tool count / error
mirasim ui-cli --port 4970 connectors auth SOME_ID        # (re)start OAuth, prints the URL
mirasim ui-cli --port 4970 connectors search "issue tracker"   # the official registry

Beyond the catalog, connector search queries the official MCP registry, so the long tail is reachable without leaving the app.

Extensions, where tools get connected
The Mirasim Extensions settings screen for connecting external tools, with the workbench entry points behind it.

ExtensionsThe curated catalog plus a search into the official MCP registry. Install, hand over secrets, and enable per agent — a tool is never forced on every session. — this control is not on the captured screen.

The buttons in this panel work — click them to look around.

The CLI tools already on your machine#

Agents work best in a real environment. Mirasim inventories the common developer CLIs on your PATH — git, gh, docker and the rest — and shows whether each is authenticated, so "the agent couldn't push" resolves to "gh was never signed in" rather than a guess.

What's installed, and what's signed in
mirasim ui-cli --port 4970 cli-tools    # dev CLIs on PATH + auth state
mirasim ui-cli --port 4970 clis         # agent CLIs: version / latest / update available

Browser and screen automation#

Browser automation is off by default — an agent gets no browser tool at all until you turn it on. When you do, it always drives a browser running in Mirasim's own profile directory, separate from your everyday browsing, with its own saved logins for the sites a task needs. Your personal browser is deliberately left alone.

For simple things you want done in your own browser on macOS — open a link, take a screenshot, tell a running app to do something — use open, osascript and screencapture directly. That is the recommended route, and it needs no toggle.

Handing browser work to an agent that only does browsers

Driving a browser click by click eats a coding agent's context: every page it looks at arrives as another wall of text it has to carry for the rest of the session. So there is a second route. Pi GUI is a separate agent whose whole job is working a browser, and a coding agent can hand a job over to it instead of doing it itself.

The handover is a tool call — gui_task. State the outcome you want, not the steps: Pi GUI plans its own route, works the pages, and hands back what it found. It runs inside an ordinary Mirasim session, so you can watch it go and stop it. The call waits for the task to settle, up to fifteen minutes.

Every result ends with a session key. Pass it back on the next call and the follow-up continues in the same browser, with the same tabs and the same logins still open — which is what makes a follow-up like now open the second result work at all.

  • Worth delegating: reading across several pages, filling a form, walking a sign-up or checkout flow, pulling data out of a table.
  • Not worth delegating: one look, one click. Do that with the browser tools directly — handing it over costs more than it saves.

Setting MIRASIM_BROWSER_CDP_URL points automation at a Chrome that already exists somewhere else — a container, a remote box. Mirasim then neither launches nor manages a browser locally, and you sign in to whatever that Chrome needs on that machine.

Screen automation is a separate toggle, and on macOS both depend on real system permissions: Screen Recording to read screen content for screenshots and UI analysis, and Full Disk Access to reach protected folders like Desktop and Downloads. The Permissions page walks each one, tells you which app to grant (the app that launched Mirasim), and re-checks on demand — because macOS has no prompt at all for some of them.

Something wrong or missing on this page? Tell us