An agent lists a repository's build pins through an MCP builds tool, as GET /api/v1/repos/:owner/:name/builds does #9106

An agent can now list a repository's build pins through a new read-only builds MCP tool. It takes { repo } and answers { items, next_cursor: null }, the same rows GET /api/v1/repos/:owner/:name/builds gives.

The gate, bun x tsc --noEmit, and mcp-builds, mcp-tools and mcp-size all pass. I did not run the full suite; the forge runs that on push.

• Access: the tool reads through repoArg, the same repository read check the MCP uses elsewhere. A repository the caller cannot read answers not_found and names no pin. It has writes: false, and its doc line names the API route it mirrors.
• Bound: it calls listBuildPins unchanged, so it stays bounded by PIN_LIMIT.
• Listing: /llms.txt builds its tool list live from each tool's doc, so builds shows up there without a separate edit. index.ts was regenerated with bun scripts/mcp-tools.ts.
• Docs: docs/features/build-pins.md has a new MCP: line.
• Test: test/mcp-builds.test.ts pins a build with pinBuild, then expects the MCP result to equal the API response exactly. It also checks that a stranger gets not_found on a private repository, while the owner sees the pin. I did not run it with the tool removed.
• Not done: no pin, note or delete actions; those stay person-only. I added a new tool file, as the issue asked, rather than an action on an existing tool. mcp-size passes, and I did not raise any ceiling.
• Push order: my first push had a type error in the new test. The second commit fixed it, and the pull is clean now.

To try it, call the MCP tool builds with { "repo": "owner/name" }.

Closes #9091

An agent can now list a repository's build pins through a new read-only builds MCP tool. It takes { repo } and answers { items, next_cursor: null }, the same rows GET /api/v1/repos/:owner/:name/builds gives.

The gate, bun x tsc --noEmit, and mcp-builds, mcp-tools and mcp-size all pass. I did not run the full suite; the forge runs that on push.

• Access: the tool reads through repoArg, the same repository read check the MCP uses elsewhere. A repository the caller cannot read answers not_found and names no pin. It has writes: false, and its doc line names the API route it mirrors.
• Bound: it calls listBuildPins unchanged, so it stays bounded by PIN_LIMIT.
• Listing: /llms.txt builds its tool list live from each tool's doc, so builds shows up there without a separate edit. index.ts was regenerated with bun scripts/mcp-tools.ts.
• Docs: docs/features/build-pins.md has a new MCP: line.
• Test: test/mcp-builds.test.ts pins a build with pinBuild, then expects the MCP result to equal the API response exactly. It also checks that a stranger gets not_found on a private repository, while the owner sees the pin. I did not run it with the tool removed.
• Not done: no pin, note or delete actions; those stay person-only. I added a new tool file, as the issue asked, rather than an action on an existing tool. mcp-size passes, and I did not raise any ceiling.
• Push order: my first push had a type error in the new test. The second commit fixed it, and the pull is clean now.

To try it, call the MCP tool builds with { "repo": "owner/name" }.

I pushed a new commit to the pull, and bun scripts/gate.ts now passes here. I did not wait for the forge's check on the new push.

The check failed on two gate rules, both about commit messages. They want a "Try:" line and a "Why now:" line. I couldn't amend the earlier commits, since force pushes are refused. So I added an empty commit that carries both lines:

• Why now: build pins are on main (#9062) but only a person can reach them; an agent has no MCP way to read them.
• Try: call the MCP tool builds with {"repo":"owner/name"} on the preview. It answers {items,next_cursor:null}, the same rows GET /api/v1/repos/owner/name/builds gives.

The code is unchanged since the last push, so the earlier test and type-check results still stand.

The failing check is fixed and pushed. test/mcp.test.ts keeps a hard-coded list of the tool names that tools/list returns. It didn't include the new builds tool, so it failed on the extra name. I added builds to that list. The test was out of date, not the tool.

test/mcp.test.ts now passes in full (48 tests) and the type check is clean. I didn't re-run the full suite here; the forge's check does that on this push. I did not re-run the gate this time. The new commit message carries the Why now: and Try: lines that the earlier gate rules wanted.