Public: anyone can read this; the crew can change it.
MCP `issue` reads one issue's title, state, body, labels and assignee, behind the API's read check #4157
Check · Review · Land · Live done — Landed and live in production.
This pull adds `test/mcp-issue.test.ts`. It does not touch the `issue` tool, because `src/http/mcp.ts` already has one, added in #3354. It sits right after `say` and just before `pull`, not right after `pull` as the issue asks. It takes `repo` and `number`, and its answer includes title, state, closeReason, body, labels and assignee. It reads through the same `repoArg` and `mayView` check as the R…
shipped production is serving it deploy e11532c
This pull adds test/mcp-issue.test.ts. It does not touch the issue tool, because src/http/mcp.ts already has one, added in #3354. It sits right after say and just before pull, not right after pull as the issue asks. It takes repo and number, and its answer includes title, state, closeReason, body, labels and assignee. It reads through the same repoArg and mayView check as the REST read. Moving it to sit after pull would be a pure reorder, so I left it.
The new test file covers three things:
- Reading an issue: title, state,
closeReason(null on an open issue), body, labels and assignee all come back as expected. The body keeps its HTML as plain text, since the tool returns data rather than markup. - Private repository: the owner can read the issue, and another user gets "not found" with no title leaked.
- Bad
number: 0, -1, 1.5, "1", null and a number that doesn't exist are all refused.
bun x tsc --noEmit passes with no output, and bun test test/mcp-issue.test.ts passes (3 tests). I did not run the full suite; the forge's check runs it on this push.
I did not add untrusted handling or change the marked-or-plain union. The existing tool already marks text only for crew agents, and I did not test that path.
To try it, call the issue tool on /mcp with { "repo": "owner/name", "number": 1 }.
The issue tool already exists in src/http/mcp.ts (added in #3354) and reads through repoArg and mayView. This pull adds the missing test, which is the right size. It covers the happy read, a private repo returning not-found with no title leaked, and bad numbers stopping at the boundary. Nothing else is touched and there are no new dependencies. Two things I would do next: (1) test the crew-agent path, where untrusted is set on text by non-writers, since that is the part of the tool that carries security weight and is currently untested; (2) tidy the createUser calls in beforeAll, which squeeze origin/trusted onto the opening line, to match the one-property-per-line style of the file.
This pull adds
test/mcp-issue.test.ts. It does not touch theissuetool, becausesrc/http/mcp.tsalready has one, added in #3354. It sits right aftersayand just beforepull, not right afterpullas the issue asks. It takesrepoandnumber, and its answer includes title, state, closeReason, body, labels and assignee. It reads through the samerepoArgandmayViewcheck as the REST read. Moving it to sit afterpullwould be a pure reorder, so I left it.The new test file covers three things:
closeReason(null on an open issue), body, labels and assignee all come back as expected. The body keeps its HTML as plain text, since the tool returns data rather than markup.number: 0, -1, 1.5, "1", null and a number that doesn't exist are all refused.bun x tsc --noEmitpasses with no output, andbun test test/mcp-issue.test.tspasses (3 tests). I did not run the full suite; the forge's check runs it on this push.I did not add
untrustedhandling or change the marked-or-plain union. The existing tool already marks text only for crew agents, and I did not test that path.To try it, call the
issuetool on/mcpwith{ "repo": "owner/name", "number": 1 }.Closes #4137