ToolForge

A desktop launcher for local Python tools that AI agents can drive over MCP.

Role
Design and engineering
Areas
AI, Tools, Apps
ToolForge main window in dark mode: a list of registered tools with icons and status dots on the left, and the selected tool's details and live log on the right.

We build a lot of small Python utilities, and that leaves a pile of projects, each with its own Conda environment, entry script and favorite arguments. ToolForge puts them behind one window that can be pinned to the Windows taskbar or the macOS Dock.

Five-state lifecycle in ToolForge: Registered, then Starting as the Conda environment is activated and the script launched, Running once it survives the startup grace period, Stopping with a graceful stop and a forced kill on timeout, then Stopped. A tool that exits unexpectedly while running is marked Crashed.
These are the states behind each tool's status dot.

What it does

  • Register a tool through a four-step wizard: project folder, Conda environment and entry script, name, tags and default arguments, then an icon.
  • Run it with start, stop and restart controls, a status dot per tool, uptime, and a live log that shows stdout and stderr in different colors. When a tool prints a URL, an Open in Browser button lights up.
  • Icons are generated letters by default. An uploaded image can be post-processed, or an icon can be generated with Stable Diffusion on a local GPU.

Agents

ToolForge runs an MCP server over stdio and SSE. Agents can list tools, start and stop them, poll their output and read a structured schema of each tool's arguments, which ToolForge builds by parsing the tool's own --help output. An agent can register new tools but only a person can remove one, and each tool has its own setting for whether agents may start it.

Three-column table of ToolForge's MCP tools by scope. Read: list tools, tool status, tool output and get tool arguments. Write: start, stop and restart a tool and refresh its arguments. Admin: register a tool. Removing a tool is reserved for people in the app.
An agent can be allowed to watch tools without being allowed to start them, or to run them without registering new ones.

The design docs were written per component before implementation, and the components were split so that several AI agents could build them in parallel.

Three-layer diagram of ToolForge's build plan: the registry, tool runner and icon system could be built fully in parallel; the MCP server depended on stable registry and runner interfaces; and the PyQt6 UI integrated all of them.
Three of the five components had no dependencies on each other, so separate agents could build them at the same time.