Let Claude drive your menu bar.
Toolbox runs a local MCP server, so an agent can list your widgets and use them: add a task, append to a note, start a timer, check which repos you left dirty. Off by default, opt-in per widget, loopback only — and your local scripts are never on the menu.
Two tools, not a hundred.
About twenty widgets with a handful of actions each would be roughly a hundred tools. Handing a model a list that long is expensive in context and makes it worse at picking the right one. So the server publishes exactly two: one to discover — which widgets exist and what each can do, with the full argument schemas once the agent asks about a specific one — and one to execute.
The cost is one extra round trip. The benefit is that the tool list stays the same size whether you have five widgets installed or thirty, and the model gets a compact index instead of a wall of schemas.
When it goes to act, it takes the same path your click does. Actions mutate the same stores the interface writes to, so a task Claude adds persists to disk, shows up in your other windows and syncs like any other. Two rules keep retries safe: actions set an explicit target state rather than toggling — “complete this” always means done, so a repeated call cannot un-complete it — and when a reference is ambiguous, the action refuses and lists the candidates instead of picking one.
- Discovery tool: widgets, actions, and schemas on request
- Execution tool: one action plus its arguments
- The tool list does not grow as you install widgets
- Mutations go through the same store as the interface
- Explicit target state, so a retry is never destructive
Per widget, and never widened from the inside.
“The agent can use your widgets” is only reassuring if you can say which ones. There are two layers: what each widget’s author declares, and your own override on this machine.
The normal case, for actions that only read or write that widget’s own data — tasks, notes, checklists, a timer. Visible to the agent, and you can hide any of them.
Legitimate but worth a deliberate yes: things that reach the network or probe your filesystem. Hidden until you switch them on, and shown unticked with a note saying so.
For anything destructive. Hidden, and there is no toggle — not off by default, but unavailable. Your override is ignored for these, on purpose.
The agent cannot widen its own reach
No exposed tool can write the agent-visibility settings. Claude cannot switch on a widget you left off, un-hide one you hid, or reach a blocked one — the only path is the local interface: right-click a widget, or Settings → Agent. This is a rule the code keeps, not an intention.
Local scripts are excluded, full stop
The Actions widget can run scripts on your machine when you click a tile. That is withheld from the agent at two levels: script tiles are advertised to it as not runnable, and the run action refuses them anyway — even if you have enabled local scripts for yourself. It is not a setting you can turn on for the agent.
The catalog is signposted, not installed
Ask for a widget you do not have and the agent used to be told it does not exist. Now it is told where to find it — browsing the catalog is read-only. Installing is a separate, sensitive tool that says out loud it loads code and should be checked with you first, and the package still has to pass a signature and hash check in the native layer. Signposting is not installing.
Turning a widget off removes its tools
Agent visibility follows the widget. Disable it and its actions are un-published immediately, without restarting anything — and uninstalling an installable widget takes its tools with it. There is no stale entry left behind for a model to try.
The widgets with tools today.
Plus a core group for the container itself: spaces, tabs, reordering and moving widgets, and read-only browsing of the catalog.
Installable widgets can expose tools too — Git Status was the first, and several catalog widgets (crypto, stocks, weather, translator) declare their own. Install one and its tools appear without restarting the app.
One command, or one block of JSON.
Turn the server on in Settings → Agent. It generates a token and shows you both ways to connect, already filled in with it — a terminal command for Claude Code, and a config block for Claude Desktop, Cursor or VS Code. Copy whichever matches your client.
The transport is plain streamable HTTP over loopback, so there is nothing to install alongside it and no wrapper process to keep alive. Regenerate token cuts off every client that had the old one.
- Works with Claude Code, Claude Desktop, Cursor and VS Code
- Nothing extra to install — the server is the app
- Regenerating the token revokes old clients instantly
- Pairs well with LLM Quota if you are pacing a plan
claude mcp add --transport http toolbox \ http://127.0.0.1:41434/mcp \ --header "Authorization: Bearer <token>"
{
"mcpServers": {
"toolbox": {
"type": "http",
"url": "http://127.0.0.1:41434/mcp",
"headers": {
"Authorization": "Bearer <token>"
}
}
}
} A local port is still a port.
Opening a listener on your machine deserves more than “it’s only localhost”, so here is exactly what it does. The toggle is off by default and with it off the server never starts. When on, it binds only 127.0.0.1 — never your local network — and every single request must carry a bearer token, generated with 128 bits of randomness and compared in constant time.
On top of that there is a Host and Origin allowlist, which exists to stop DNS rebinding: a web page that resolves a domain it controls to your loopback address cannot reach the server, because requests arriving with a non-loopback Host are refused before authentication even runs. Request bodies are capped, and anything that is not the expected POST is rejected outright.
Where the token lives, honestly. It sits in plain text in a device-local config file — the same model the GitHub, npm and AWS command-line tools use. It guards a loopback port, and anyone who can read that file is already running code as you. That file is deliberately excluded from cloud sync, so enabling the server on one machine never enables it on another and the token does not travel.
- Off by default; server does not start when off
- Binds 127.0.0.1 only — no LAN exposure
- 128-bit bearer token, constant-time comparison
- Host/Origin allowlist against DNS rebinding, checked before auth
- Device-local: never synced, per-machine opt-in
Questions, answered.
What is MCP, in one paragraph?
The Model Context Protocol is a standard way for an AI client — Claude Code, Claude Desktop, Cursor, VS Code — to discover and call tools that live outside itself. A program exposes a set of tools with descriptions and argument schemas; the model reads that list and decides when to call one. Toolbox implements the server side of it, so your widgets become tools the model can use.
Is it on by default?
No. It is off until you turn it on in Settings → Agent, and with the toggle off the server does not even start listening. The setting is device-local, stored in a file that is deliberately excluded from iCloud sync: enabling it on one machine does not enable it anywhere else, and the token never leaves the machine it was generated on.
Can the agent run scripts on my machine?
No. The Actions widget can run local scripts when you click one, and that capability is specifically withheld from the agent: a script tile is listed to the agent as not runnable, and the run tool refuses it — regardless of whether you have enabled local scripts for yourself. It is not a setting you can flip on for the agent, because spawning arbitrary processes on behalf of a model is a footgun rather than a feature.
Can the agent install widgets by itself?
It can find them, not install them silently. Listing the catalog is read-only, and the install tool is marked sensitive: its own description says that installing loads code and that it should ask you first. Underneath, installation is gated the same way as a manual one — the package must pass a minisign signature check and a hash check in the native layer, so an unsigned or tampered widget is rejected no matter who asked for it.
Why does the agent only see two tools?
Because roughly twenty widgets with a handful of actions each is around a hundred tools, and dumping that into a model’s context makes it both expensive and worse at choosing. So the server publishes two: one to discover what exists — widgets and their actions, with full argument schemas when you ask about a specific widget — and one to execute. It costs one extra round trip and it means the tool list does not grow as you install more widgets.
Can the agent give itself more access?
No, and this is enforced rather than promised. No exposed tool can write the agent-visibility settings: an agent cannot switch on a widget you left off, un-hide one you hid, or touch a widget whose author blocked it from the agent entirely. The only way to change what the agent can see is the local interface — right-click a widget, or Settings → Agent.
Does an agent action behave differently from a click?
It goes through the same path. Actions mutate the same stores the interface does, so a task added by Claude persists, appears in your other windows and syncs exactly like one you typed. Two design rules make retries safe: actions set an explicit target state rather than toggling — “complete this” always means done, so a retry cannot un-complete something — and when a reference is ambiguous, the action refuses and lists the candidates instead of guessing.
Is it free?
Yes. Webstarted Toolbox is free and needs no account, and the MCP server is part of the app — nothing extra to buy or sign up for.
Get Webstarted Toolbox
Free to use. The MCP server is built in — enable it in Settings → Agent. macOS 12+ and Windows 10+.
One icon, many small tools
This is just one of the widgets in Webstarted Toolbox. Here are the rest: