legwork-mcp

Overview Schema Source Related Servers Discussions Admin

install_tool

Idempotent

Install a GitHub repository as a local MCP tool with sandboxed build and self-tests, then request only needed read-only folder or network access. Approve generated install commands before they run.

Instructions

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. For a repo not in the Legwork cache, a model writes the install command, and the build stops to show it before any of it runs: approve it by calling install_tool again with install_command. A repo already installed with the same grants is reused, not rebuilt. Replies with the new tools' names and how to call them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo": "<repo>"
    },
    "name": "install_tool"
  }
}

Input Schema

Name	Required	Description
`repo`	Yes	owner/repo (or its GitHub URL), e.g. 'jsvine/pdfplumber'
`commit`	No	optional: a full 40-character commit SHA or a tag (e.g. v1.2.0) to build exactly that, instead of the default branch as it is now
`preview`	No	true: install nothing; say which commit would be built and how it would be installed, so the user can approve that exact commit
`allow_net`	No	whether the tool may use the internet while it runs (installs always can). Omitted: keeps an earlier grant, or no
`allow_read`	No	folders the tool may read, read-only, e.g. ['~/Downloads']. Omitted: keeps what an earlier install of this repo was granted, or none
`install_command`	No	only when a build is waiting for approval: the exact install command it showed, to run it once the user approves; "" declines it. Anything else runs nothing

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.7.16Oct 29, 2026

addedInput schema / properties / install_command

Added value: +{
+  "description": "only when a build is waiting for approval: the exact install command it showed, to run it once the user approves; \"\" declines it. Anything else runs nothing",
+  "type": "string"
+}

Changed3 schema fields changedv0.1.1Oct 18, 2026

changedInput schema / properties / allow_net / description

Previous value: -"whether the tool may use the network"New value: +"whether the tool may use the internet while it runs (installs always can). Omitted: keeps an earlier grant, or no"

changedInput schema / properties / allow_read / description

Previous value: -"folders the tool may read"New value: +"folders the tool may read, read-only, e.g. ['~/Downloads']. Omitted: keeps what an earlier install of this repo was granted, or none"

changedInput schema / properties / repo / description

Previous value: -"owner/repo from find_tools"New value: +"owner/repo (or its GitHub URL), e.g. 'jsvine/pdfplumber'"

First observedv0.1.0Oct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Substantially exceeds the annotations: it discloses the security scan for hidden payloads, sandbox build and self-test, that grants are read-only folders/network bounded by the limits the user started Legwork with, the 45 second wait with build-still-running messaging, cache reuse for identical repo+grants, and the human-approval gate for model-written install commands before anything runs. These are exactly the behavioral traits an agent needs and none are derivable from readOnlyHint/openWorldHint/idempotentHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and outcome, and nearly every sentence carries distinct operational information (scan, wait limit, cache reuse, approval, return shape). It is dense at roughly five sentences and the grant clause is slightly repetitive with the schema, but there is no filler to cut.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description states what comes back ('the new tools' names and how to call them'). Combined with the timeout/polling path, cache behavior, approval flow, and grant bounds, an agent has everything needed to call this correctly on the first try or continue after a long build.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description still adds meaning beyond the schema for the approval loop ('approve it by calling install_tool again with install_command') and for grant semantics ('ask only for what the task needs', grants bounded by Legwork's start limits). preview and commit are left entirely to the schema, but the highest-risk parameter (install_command) is well explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Install a GitHub repo ... as a tool on the user's computer') plus the concrete scope of what installation entails (source scan, sandbox build, self-test). It names the sibling used to pick the repo (find_tools) and the sibling that follows a slow build (install_status), so it is clearly distinguishable from the other four tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear workflow guidance: pick the repo with find_tools, ask only for the grants the task needs, call again with install_command to approve an awaiting build, and use install_status when the 45 second wait expires. Lacks an explicit 'do not use this when...' exclusion (e.g. repo already installed, or a plain library rather than a tool), but the alternatives are all named in context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server