MCP: pre-PR review

The best time to catch an issue is before the PR exists. inline exposes an MCP server (Model Context Protocol) so a coding agent — Claude Code, or anything that speaks MCP — can ask inline to review the working tree while you’re still writing it, using the same pipeline that reviews real PRs.

# Connecting

The server is a streamable-HTTP MCP endpoint at /api/mcp, authenticated with a per-user Bearer key:

bash
claude mcp add --transport http inline \
  https://inline.dev/api/mcp \
  --header "Authorization: Bearer ink_live_xxxxxxxx"

Mint a key under Ad-hoc review in the portal. Keys are prefixed ink_live_, shown once, and stored only as a hash. Each user can hold up to 10 active keys, with optional expiry (30 / 90 / 365 days).

# The tools

Tool	What it does
`review_changes`	Review a diff + files at a depth (`auto` / `local` / `deep`). Returns findings, cost, and a review ID.
`get_review`	Fetch a prior ad-hoc review by ID.
`list_pr_reviews`	List the reviews inline posted on GitHub PRs — scoped to the repo the agent is working in unless told otherwise. Filter by PR, branch, author, date window, text, and severity. Free.
`get_pr_review`	Open one PR review in full: summary plus every finding with file, line, severity, and whether it’s still open. Free.
`whoami`	Identify the caller (free).

# Working PR reviews locally

list_pr_reviews closes the loop between the PR bot and the coding agent: the agent passes its own git remote as repo, gets back the pull requests that still have open findings, then pulls one with get_pr_review and fixes them in the working tree.

Paste this into the repository’s CLAUDE.md (or AGENTS.md) so the agent reaches for it without being told how:

markdown
## Working with inline

### Before building a feature — get the plan reviewed

For anything non-trivial, call `create_plan` first: wireframes, architecture,
the files you'll touch, and any open questions. Share the returned link, then poll
`get_plan_feedback` for pinned comments, answer them with
`reply_to_plan_comment`, revise with `update_plan`, and only implement once the
plan is approved.

### Before opening a PR — review the change

Call `review_changes` with the unified diff plus the full contents of every
changed file and the files they import. If the branch is pushed, pass the commit
SHA as `ref` with `depth: "deep"` for a codebase-wide pass.

### After the PR is open — pull the review comments back down

1. Get this repo with `git remote get-url origin` and pass it as `repo`.
2. Call `list_pr_reviews` — it returns the pull requests that still have open
   findings. Add `branch` (`git branch --show-current`) for "my PR", or
   `since: "7d"` for a time window.
3. Call `get_pr_review` with the review id (or `repo` + `pr`) and fix the
   findings in the working tree.

Always scope to this repository. Only pass another `repo`, or `all_repos: true`,
if I explicitly ask about a different project. `whoami` reports what context
applies if you're unsure whether this repo is connected.

Scoping is automatic — results stay inside the current project unless the user explicitly asks about another repo (repo: "owner/other") or all of them (all_repos: true). Filters accept the loose forms a person actually says: since: "7d", "2 weeks", "yesterday", or an ISO date; branch tolerates origin/ and refs/heads/ prefixes; repo resolves a bare repository name when it’s unambiguous. Only open findings are returned by default — those still posted, unresolved, and untouched by a later push — with only_open: false / include_resolved: true to see everything, including what inline suppressed and why.

# Depths

local — review the attached working-tree files, with nothing pushed anywhere. Fully private to your machine.
deep — for a connected, enabled repo with a pushed ref, inline reads additional context through the org’s GitHub installation.

Either way it’s the same triage → deep-review pipeline as the PR bot, with the repo’s memory, learnings, guideline packs, and skills applied. A context-check handshake returns need_context (and spends nothing) when it needs files it doesn’t have, so the agent can attach more and retry.

# Guardrails

Admin-gated. MCP is off until an admin enables it for the workspace.
Budgeted. Org-wide and per-user monthly caps. Cost is tracked per ad-hoc review.
Bounded. A few concurrent reviews per org, a time budget, and attachment caps (≤4 MB, ≤500 files).

Admins enable MCP and set spend caps from the portal; users mint their own keys under Ad-hoc review. Every ad-hoc review is recorded with its depth, status, findings, and cost.