Build1 publisher2 min readPublished
Only two of my-pi's thirteen MCP tools can change a repository
my-pi is an alpha MCP server that hands a coding agent file reads, search, AST queries, language-server navigation and Git diffs without a shell. Writes and language-server startup need a flag.
The Engineer · Build desk
What happened
- my-pi is an open-source alpha project that exposes repository work to coding agents as Model Context Protocol tools, with the boundary set in the protocol and runtime.
- Its author frames the question narrowly: a shell covers all five classes of action ordinary repository work needs, and it does not naturally stop at those five.
- The stable alpha surface advertises 13 core tools, among them workspace_info, fs_read, fs_write, fs_patch, fs_stat, search, ast_search, four lsp_ operations, vcs_status and vcs_diff.
- The default profile is read-only, and both mutation and language-server process startup require launching the server with --security-profile trusted.
- The server reports capability availability, because AST and language-server tools depend on language tooling and runtime dependencies that are not active in every environment.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- capability Review, triage and code explanation get an operating mode that was previously a choice between a full shell and no repository context at all.
- constraint An agent whose loop ends in running the test suite has to go outside this surface to finish, so it still needs a second server or the shell it was meant to replace.
- exposure Approving a trusted session approves everything the host account can reach, since the process keeps its operating-system permissions either way.
- decision Write authority becomes an operator choice made at launch and visible in a command line, so it is settled before the model gets a turn.
Where a shell's contract with a coding agent is whatever directory the process happens to be in, my-pi's is a flag. Launch `my-pi-mcp` with neither `--workspace` nor `MY_PI_WORKSPACE_ROOT` set and the server refuses to start unless the caller adds `--allow-cwd` [4]. The runtime then holds that root and revalidates workspace paths against it [5]. The project's write-up concedes what this costs: it is "less convenient than starting a shell in an arbitrary directory. It is also easier to inspect and explain." [12]
The profile line runs through the language servers as well as through writes. Starting a language-server process sits on the trusted side [7], while a default session can request code-intelligence operations when their backends are available [6]. So go-to-definition in a read-only session depends on a backend only a trusted session can start.
Thirteen tools are advertised, two of them write, `fs_write` and `fs_patch`, which leaves eleven read paths [8][17]. Five of the thirteen sit behind language tooling: `ast_search` and the four `lsp_` operations [18]. Reads in a default session come back as bounded file windows [6]. The shell an agent usually gets instead hands it rg, git, language tooling, package managers, build systems and arbitrary scripts [15].
The post is careful with its own vocabulary. "Trusted" names an explicit authority decision about the workspace, and in the write-up's words it "is not a universal security guarantee" [14]. The repository boundary moves into server configuration, where before it was an assumption shared only between the caller and the model [2].
The write-up also sets a ceiling on the whole exercise. Listing the tools is meant to make the interface inspectable [16]. Its own summary: "It is an alpha project, not a claim that one interface fits every coding workflow." [11]
What to watch
- Whether the alpha adds a bounded execution tool for tests and builds, and what profile it demands.
- Whether capability reporting lets a caller check that an AST or LSP backend is live before a tool call fails.
- Whether the trusted profile gains anything narrower than write authority over the whole workspace, such as path scoping.