DOCS · TOOLS & INTEGRATIONS
The tools beneath the surfaces.
You talk to a surface — chat, terminal, browser. Beneath them is the tool layer: the concrete moves an agent can make. SynthOS ships 48 built-in tools across the terminal, the web, your files, and asset creation. You can connect your own apps and command-line tools, and agents pick them up instantly. And because SynthOS speaks the Model Context Protocol, it can use tools that follow that open standard too. This page documents that layer: what ships, how to extend it, and how an agent decides which tool to reach for.
OUT OF THE BOX
The 48 built-in tools.
A tool is the smallest unit of action — one concrete move an agent can make. SynthOS ships with 48 of them, grouped by the surface they act on. You never call a tool by name; the system reaches for the right one to reach the outcome you described.
The built-in set is not a marketplace of plugins you install — it is the standard kit every agent has from the first run, on every plan. It spans four broad areas: the terminal and the command-line tools it drives, the web it browses and acts on, the files it reads and edits, and the assets it creates. These are the moves the chat, terminal, and browser surfaces are built on.
Run a command on your Mac, read its output and exit code, write and run a script, manage a working directory. The full command-line, driven on your behalf — every command shown with its result.
Open a page, read it, follow a link, fill a form, click, extract what matters, and gather across several sources. The browser as something an agent can operate, not just a window you open.
Read a file, search across your vault, create a note, edit a document, move and organise. Work lands as Obsidian-compatible markdown on your disk, in files you own.
Produce a deliverable — a written document, a structured dataset, an image, audio. The output of the work, not just a description of it.
One more class of tool cuts across all four: approval. When a move is risky or hard to undo, the agent’s tool for that step is “ask you first” — it pauses and surfaces the decision rather than acting on its own. Guardrails are part of the tool layer, not an upsell layered on top.
# 48 is the count of built-in tools that ship today, not a ceiling. # the number you connect yourself (cli tools, your apps, mcp tools) # is on top of these — and the built-in set grows over time. the # honest claim is: 48 out of the box, plus whatever you bring.
YOUR TOOLCHAIN
Connecting your own apps and command-line tools.
SynthOS runs on your Mac, so it runs the tools your Mac already has. Anything on your PATH is available the moment it’s installed — there is no separate registry to populate, and agents pick it up instantly.
Install a new command-line tool the way you normally would — a package manager, a download, a script — and the next command an agent runs can use it. Because the terminal is your real shell, a freshly installed binary is on the path without any configuration step on the SynthOS side. The same is true of tools you’ve had for years: they’re already there. There is no “import” or “sync” to wait on.
Tools that need a key or a login use your credentials, stored locally, exactly as they would in a shell you opened yourself. A GitHub CLI authenticated with your token, a cloud command-line signed into your account, a database client with your connection string — an agent invokes each one directly on your machine, under your existing permissions. SynthOS does not proxy your toolchain through a service or add a markup.
Apps you already use fit the same way. If an app exposes a command-line interface or a local script, it’s reachable the instant it’s installed. If an app or service speaks the Model Context Protocol, you connect it as an MCP tool — covered next — and it joins the same pool the agent picks from. Either way, the rule holds: install or connect once, and it’s available to the next run without ceremony.
An illustration of the path, not a live run: install a CLI, and the next agent can reach it.
Read Terminal & AgentsAN OPEN STANDARD
MCP compatibility — the Model Context Protocol.
MCP is an open standard for how an AI agent and a tool talk to each other. SynthOS is MCP-compatible: it can use tools that speak the protocol, so a growing ecosystem of integrations works without a bespoke adapter for each one.
The Model Context Protocol defines a common way for a tool to describe what it can do and for an agent to call it — a shared language between the model and the things it operates. Before a standard like this existed, every integration was a one-off: a custom connector written for one app, in one product. MCP replaces that with a single contract, so a tool written once can be used by any client that speaks the protocol.
For SynthOS, being MCP-compatible means two things. First, you can connect an MCP tool — a server that exposes a capability over the protocol — and it joins the same pool of moves an agent can choose from, alongside the built-in tools and your command-line tools. Second, work done over MCP is treated like any other tool call: it’s shown, it leaves a receipt, and risky steps still pause for your approval. The standard does not buy a tool an exemption from the guardrails.
Why a standard matters. An ecosystem of MCP-compatible tools means you don’t wait for one vendor to build one connector. A tool that follows the protocol is usable the day it ships, by anything that speaks MCP — including SynthOS.
It cuts both ways. SynthOS can use MCP tools, and — through the Forge — it can publish one: turn your own vault into an MCP endpoint other agents can call. The same protocol that lets you consume tools lets you become one.
The guardrails travel with it. An MCP tool is still a tool. Its calls are shown, receipted, and held for approval when they’re risky — the same as a terminal command or a browser action.
SELECTION
How agents choose which tool to use.
You describe an outcome; you don’t name a tool. The agent maps the outcome to the moves available to it and picks the one that fits — then shows you the call it made.
It reads the outcome
You ask for a result — “check the latest release notes and summarise what changed.” The agent works from the outcome, not a recipe. Nothing in the ask names a tool, and you don’t have to know which exist.
It surveys the moves available
The agent considers the full pool of tools it can reach — the 48 built-in, the command-line tools on your PATH, and any MCP tools you’ve connected — and what each one is good for. The pool is the same on every surface.
It picks the fitting move
It chooses the tool that gets closest to the outcome — open a page rather than guess, run a command rather than describe one, edit the file rather than hand back instructions. If a risky move is the right one, it asks before making it.
It shows the call it made
Every tool call is on the record: which tool, with what input, and what it returned. If the result isn’t what the outcome needs, the agent reads it and reaches for the next move — and that, too, is shown.
# the agent chooses; you don’t configure a routing table. tool # choice is part of the model’s reasoning, not a fixed mapping # you maintain. what you get in return is the receipt: every call is # visible, so the choice is auditable after the fact.
THE CAPABILITY MAP
Capabilities overview.
Read another way, the tools group into capabilities — the kinds of work SynthOS can actually do. Each is built from the same tool layer and carries the same guardrails.
Run real command-line tools on your Mac — git, npm, ffmpeg, a Python script, whatever the job calls for — with the command and its result shown in full.
Browse and act: read pages, follow links, gather across sources, fill forms, click through a flow — each step on the record, with approvals before anything risky.
Read and edit files, search your vault, create and organise notes — as Obsidian-compatible markdown on your disk, auto-linked into a living graph you own.
Create deliverables — documents, datasets, images, audio — as the finished output of a job, filed into your vault rather than left as a suggestion.
Speak to it and hear it back. Voice is a way in and out of the same surfaces — you can dictate an ask and listen to the result instead of reading it.
These capabilities aren’t separate products bolted together — they’re views of one tool layer. A single ask can cross all of them: browse for a fact, run a command to act on it, edit a file with the result, and produce a finished asset. You watch each move land on its surface.
See all capabilitiesTHE BRIDGE
From consuming tools to publishing them.
Everything above is about the tools an agent uses. There is a second direction: making a tool of your own. The Forge turns the knowledge in your vault into something other agents can call.
Forge your vault into a product. The same Model Context Protocol that lets SynthOS consume MCP tools lets it publish one. The Forge takes a private vault and stands it up as a live MCP endpoint — a scoped, token-gated, revocable tool that any MCP-compatible agent can call — or as a one-line CLI you run locally. The vault you’ve been filling becomes a capability other people (and other agents) can use, on your terms.
This is the natural other half of this page. Tools come in through the built-in set, your command-line tools, and the MCP tools you connect. A tool can also go out: your vault, published. Consuming and publishing are the same protocol seen from two sides — which is why an MCP-compatible app can both reach for tools and become one.
You start by using tools. With the Forge, your vault becomes one.
Read about the ForgeKEEP READING
One tool layer, two directions.
The tools are how the work gets done in SynthOS — the AI operating system for a company of one. Use the built-in set, bring your own, and, when you’re ready, publish your vault as a tool of your own.
48 built-in tools · Connect your own · MCP-compatible · Local-first on your Mac.