gh-triage-mcp

A three-tool MCP server for GitHub issue triage. TypeScript. Stdio.

Most GitHub MCP servers wrap the REST API 1:1 and dump the JSON back into the model. That looks complete and costs you context. This one does the opposite: few tools, payloads shaped for the next call, a dry-run on the only write, retries on the client, and an offline eval that measures the difference.

Portfolio piece for agentic-engineering interviews. Not a product.

The problem

An agent triaging issues needs three things: a short list, one issue with enough context to decide, and a way to draft a comment without posting it by accident. It does not need node_id, reaction counts, or 47 overlapping tools.

HN already measured this: two MCP servers on the same todo API, same pass rate, 5× input tokens on the one that returned raw API objects and omitted the id the next write needed. (thread)

Related MCP server: mcp-gitpro

Tools

next.owner / next.repo / number are on every search hit so summarize_issue and draft_comment do not require a second lookup to learn which repo you are in.

Tradeoffs

• Three tools, not a GitHub SDK. Labeling, assigning, closing, and projects are out of scope. If you need those, use github/github-mcp-server and pay the tool-count tax.

• Excerpts, not full bodies. 480 characters. The eval treats that as a feature. A legal-discovery agent would hate it.

• suggested_action is a heuristic, not a model. Keyword-level. It exists so the payload is honest about what a deterministic layer can do; swap it for a classifier if you actually ship this.

• confirm=true is the only safety rail on writes. There is no human-in-the-loop protocol beyond "the client must pass the flag." Claude Desktop users who auto-approve tools can still shoot themselves.

• Search uses GitHub's issue search, which lags and rate-limits. Unauthenticated traffic dies fast; set GITHUB_TOKEN.

Eval (offline, in CI)

npm run eval runs 20 synthetic search hits through a naive raw dump and through shapeIssue. Latest committed report:

Naive dump is 2.92× the tokens and still cannot fill summarize_issue(repo, number) without parsing URLs. See evals/REPORT.md.

Pass means "the next tool call can be filled from the payload." It is not a claim about any vendor model. Re-run with npm run eval; CI fails if shaped pass rate drops or the token ratio collapses.

Streamlit demo

The TypeScript stdio server is the product. Streamlit is the click-through: naive REST dump vs shaped payload, dry-run draft_comment.

pip install -r requirements.txt
streamlit run app.py

Streamlit Cloud: app file app.py. No secrets. Does not call GitHub.

Install

git clone https://github.com/theashleygross/gh-triage-mcp.git
cd gh-triage-mcp
npm install
npm test
npm run eval
npm run build

Claude Desktop / Cursor (claude_desktop_config.json or MCP settings):

{
  "mcpServers": {
    "gh-triage": {
      "command": "node",
      "args": ["/absolute/path/to/gh-triage-mcp/dist/index.js"],
      "env": {
        "GITHUB_TOKEN": "ghp_..."
      }
    }
  }
}

Needs Node 20+. Token: public_repo is enough for public issues; repo for private. Comment posting always needs a token.

Tests

No network. Fake fetch. Covers shaping, 500-retry, 404-no-retry, timeouts, dry-run vs confirm on draft_comment.

npm test

What I would do differently

• Streamable HTTP transport so this can sit behind a hosted demo, not just stdio.

• A tiny fixture repo + cassette of real api.github.com traffic, so the eval is not only synthetic.

• Optional fields allow-list on search, copying the official GitHub MCP's lesson that even shaped payloads get large.

• Do not add tools until an eval shows a missed next-action that a new tool would fix.

License

MIT. Ashley Gross, 2026.