legwork-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LEGWORK_HOME | No | Override the default build directory (~/.legwork). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_toolsA | Find a tool that runs on the user's own computer for a job you have no tool for, especially work on their local files (paths like ~/Downloads/memo.m4a, /Users/..., /home/...): transcribe audio, pull tables from a PDF, remove an image background, convert documents, trim video. A cloud code sandbox can't see the user's files unless they attached them; a tool installed through Legwork runs on their machine and reads the folders they allowed. Searches GitHub and the Legwork cache, with facts to choose by (stars, license, freshness, cached, already has an MCP server). Installs nothing. |
| install_toolA | Install a GitHub repo, usually one picked with find_tools, as a tool on the user's computer: Legwork scans its source for hidden payloads, then builds and self-tests it in a sandbox. Grants are read-only folders and/or network, within the limits the user started Legwork with; ask only for what the task needs. Waits up to 45 seconds; if the build is still running it says so, and install_status follows it. A repo already installed with the same grants is reused, not rebuilt. Replies with the new tools' names and how to call them. |
| install_statusA | Check on an install that install_tool started, when it replied that the build is still running. Waits up to 45 seconds for it to finish, then replies with one of: still installing, with the latest build steps (call it again); installed, with the folders and network it was granted and its tools; or failed, with the reason. For a repo that was never installed, it says to call install_tool. Changes nothing. |
| list_installed_toolsA | List the repos already installed through Legwork on this computer. For each: the folders and network it may use, the commit it was built from, its tools and how to call them, and a link if the repo has changed upstream since. Call it before find_tools to reuse what's already installed, or to look up a tool's repo and name for use_tool. Changes nothing. |
| use_toolA | Call a tool of a repo installed through Legwork, by repo and tool name. Most clients also list installed tools directly as __; use this when the tool isn't in your list yet. It runs in the sandbox with the folders and network granted at install. Replies with the tool's output, marked as untrusted text and size-capped, plus (on macOS) anything the sandbox blocked; files it makes are copied to ~/Legwork/outputs/ by default. Calling a repo that isn't installed is an error that says to call install_tool; a wrong tool name is an error listing the repo's tools. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool targets a distinct phase: find_tools (search), install_tool (build), install_status (check in-progress install), list_installed_tools (enumerate), use_tool (invoke). The only mild overlap is between install_status and list_installed_tools, but descriptions clearly separate in-progress builds from already-installed inventory.
All names follow a verb_noun pattern (find_tools, install_tool, install_status, list_installed_tools, use_tool) and use snake_case throughout. Minor inconsistency in singular/plural (tool vs tools), but the convention is otherwise predictable.
Five tools is well-scoped for a discover-install-run lifecycle. Each tool earns its place with no redundant entries in this range.
The full forward lifecycle (find, install, status, list, use) is covered cleanly. The notable gap is the absence of any uninstall/remove or update operation, which an agent might need to manage installed state, but core workflows are workable.