modelcontextprotocol/inspector
Watch
1
0
Fork
You've already forked inspector
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

chore: merge v2/main for the v2.1.0 milestone release

Browse source 
Resolves the eight conflicts from the first v2/main -> main milestone
merge on a branch cut from main, so v2/main's ancestry stays clean --
resolving them on the PR head would have back-merged main into v2/main,
which is exactly what #1868 was closed to avoid.

All eight took v2/main's side, each verifiably the newer content:

- README.md          stale Mcp-Param-* callout; v2/main's is corrected
                     by #1847 (the Inspector builds the headers itself)
- SECURITY.md        add/add (#1843 on main, #1867 on v2/main); differ
                     by one line, the CONTRIBUTORS.md -> CONTRIBUTING.md
                     rename from #1884
- clients/web/package.json   vitest ^4.1.0 -> ^4.1.10, the #1899 fix
- the five package-lock.json files, then regenerated from a clean
  install rather than hand-merged

main's release-workflow commits (#1831 least-privilege token, #1834
dist-tag derivation, #1836 OIDC trusted publishing) auto-merged and are
preserved -- .github/workflows/main.yml is the only file where the
merged tree differs from v2/main.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU
This commit is contained in:
cliffhall 2026-08-01 23:04:13 -04:00
commit 6233d8bb22
7 changed files with 10992 additions and 8295 deletions
Download patch file Download diff file Expand all files Collapse all files

163
.github/ISSUE_TEMPLATE/1-bug_report.yml vendored Normal file
View file

@ -0,0 +1,163 @@
name: Bug report
description: Report something broken in the Inspector (web, CLI, or TUI)
labels: ["bug"]
body:
- type: markdown
attributes:
value: |
Thanks for reporting a bug — **issues are how work reaches the Inspector.**
This repository accepts **issues, not pull requests**: design and
implementation are done by the maintainers through a prompt-driven
workflow ([`CONTRIBUTING.md`](https://github.com/modelcontextprotocol/inspector/blob/main/CONTRIBUTING.md)).
So if you have already prototyped a fix locally, **the prompt you used
plus screenshots is worth more to us than a diff** — there is a field
for it at the bottom of this form.
> 🔒 **Do not report security vulnerabilities here.** Use the
> [private advisory process](https://github.com/modelcontextprotocol/inspector/security/advisories/new)
> instead — see [`SECURITY.md`](https://github.com/modelcontextprotocol/inspector/blob/main/SECURITY.md).
- type: dropdown
id: version-line
attributes:
label: Which version line?
description: >
v2 is the current Inspector. v1 is deprecated and takes **security
fixes only**, so a v1 bug report gets a different answer. When in
doubt, it's v2.
options:
- v2 — current (`@modelcontextprotocol/inspector@latest`)
- v1 — deprecated (`@v1-latest`, security fixes only)
validations:
required: true
- type: dropdown
id: client
attributes:
label: Which client?
description: The Inspector ships three clients from one package.
options:
- Web
- CLI
- TUI
- All / shared core
validations:
required: true
- type: input
id: inspector-version
attributes:
label: Inspector version
description: The version you actually ran, not "latest".
placeholder: "2.0.0"
validations:
required: true
- type: input
id: node-version
attributes:
label: Node version
description: >
Output of `node --version`. The current v2 line requires Node >=
22.19.0; the deprecated v1 line has its own, older floor.
placeholder: "v22.19.0"
validations:
required: true
- type: input
id: os
attributes:
label: Operating system (and browser, for the web client)
placeholder: "macOS 15.5, Chrome 140"
validations:
required: false
- type: dropdown
id: transport
attributes:
label: Transport
description: How the Inspector was connected to the MCP server under inspection.
options:
- stdio
- Streamable HTTP
- SSE (legacy)
- Not applicable / never connected
validations:
required: true
- type: textarea
id: mcp-server
attributes:
label: MCP server under inspection
description: >
Which server, and how it is configured — the command or URL, the
protocol era you connected with (auto / legacy / modern), and whether
OAuth is involved. Redact tokens and secrets.
placeholder: |
Server: @modelcontextprotocol/server-everything (npx)
Protocol era: modern
OAuth: no
validations:
required: true
- type: textarea
id: repro
attributes:
label: Steps to reproduce
description: Numbered steps, starting from a fresh launch of the Inspector.
placeholder: |
1. Run `npx @modelcontextprotocol/inspector`
2. Add the server above and connect
3. Open the Tools tab and call `echo`
validations:
required: true
- type: textarea
id: expected
attributes:
label: Expected behavior
description: What you expected to happen.
validations:
required: true
- type: textarea
id: actual
attributes:
label: Actual behavior
description: What happened instead.
validations:
required: true
- type: textarea
id: logs
attributes:
label: Logs, errors, or screenshots
description: >
Console output, the Inspector's Protocol or Network tab, or a
screenshot. Redact tokens and secrets first. Screenshots can be pasted
directly into this field.
validations:
required: false
- type: textarea
id: prompt
attributes:
label: Already prototyped a fix?
description: >
Please don't attach a diff or open a pull request — share the **exact
prompt(s)** you used to produce the change, plus what you verified and
any before/after screenshots. We reproduce it through our own workflow
so it lands with the right conventions, tests, and coverage.
validations:
required: false
- type: checkboxes
id: acknowledgements
attributes:
label: Before you submit
options:
- label: I searched existing issues and this is not a duplicate.
required: true
- label: This is not a security vulnerability report (those go through the private advisory process).
required: true

88
.github/ISSUE_TEMPLATE/2-feature_request.yml vendored Normal file
View file

@ -0,0 +1,88 @@
name: Feature request
description: Suggest an improvement to the Inspector
# `v2` is safe to declare statically here: v1 takes security fixes only and
# cannot receive a feature, so a feature request is v2 by construction. The bug
# form can't do this — its version line is a reporter's answer, and `labels:`
# is static.
labels: ["enhancement", "v2"]
body:
- type: markdown
attributes:
value: |
Thanks for suggesting an improvement.
**Maintainers do the implementation here** — this repository accepts
**issues, not pull requests**
([`CONTRIBUTING.md`](https://github.com/modelcontextprotocol/inspector/blob/main/CONTRIBUTING.md)).
That makes a sharply-stated **problem** the most valuable thing you can
give us: it is what we design against, and it survives after a specific
solution turns out not to fit.
So please describe the problem first, and treat the solution section as
one possible answer rather than the request itself.
> **This form targets v2.** The v1 line is deprecated and takes
> **security fixes only** — it does not take new features.
- type: dropdown
id: client
attributes:
label: Which client?
options:
- Web
- CLI
- TUI
- All / shared core
- Not sure
validations:
required: true
- type: textarea
id: problem
attributes:
label: The problem
description: >
What are you trying to do, and what makes it hard or impossible today?
Describe the situation, not the feature — including how often you hit
it and what you do instead right now.
validations:
required: true
- type: textarea
id: solution
attributes:
label: Solution you have in mind (optional)
description: >
If you have a concrete idea, describe it here. It's fine to leave this
blank — the problem above is the part we need.
validations:
required: false
- type: textarea
id: alternatives
attributes:
label: Alternatives or workarounds you have tried
validations:
required: false
- type: textarea
id: prompt
attributes:
label: Already built it locally?
description: >
Please don't attach a diff or open a pull request — share the **exact
prompt(s)** you used, plus screenshots of the result. We reproduce the
work through our own workflow so it lands with the right conventions,
tests, and coverage.
validations:
required: false
- type: checkboxes
id: acknowledgements
attributes:
label: Before you submit
options:
- label: I searched existing issues and this is not a duplicate.
required: true
- label: This is a request for the Inspector itself, not for the MCP specification or an SDK.
required: true

57
.github/ISSUE_TEMPLATE/config.yml vendored Normal file
View file

@ -0,0 +1,57 @@
# Issue chooser configuration.
#
# Blank issues are disabled so every report lands in a form. The bug form
# requires the facts triage needs first (client, version line, transport); the
# feature form requires the client and a problem statement, and is v2-only.
#
# Security reports are deliberately a *contact link* rather than a template:
# a template would still open a public issue, which is exactly what a
# vulnerability report must not do. These links leave GitHub's issue flow and
# go straight to the private advisory form. See SECURITY.md.
blank_issues_enabled: false
contact_links:
- name: 🔒 Security vulnerability (v1 or v2) — report privately
url: https://github.com/modelcontextprotocol/inspector/security/advisories/new
about: >
Never report a vulnerability in a public issue. Private vulnerability
reporting is enabled on this repository — this link opens the advisory
form, which is the fastest route to a maintainer. v1 is deprecated and
takes security fixes only, so this is the channel for a v1 security
issue.
- name: 📜 Security policy (supported versions, what to include)
url: https://github.com/modelcontextprotocol/inspector/blob/main/SECURITY.md
about: >
Which versions are supported, how reports are handled, and what to
include in one.
- name: 🤝 Contribution policy — why there is no "New pull request"
url: https://github.com/modelcontextprotocol/inspector/blob/main/CONTRIBUTING.md
about: >
This repository accepts issues, not pull requests — maintainers do the
implementation. If you already built a change locally, open an issue and
share the prompt you used rather than a diff.
- name: 📖 MCP documentation
url: https://modelcontextprotocol.io
about: >
Guides and reference for the Model Context Protocol itself. Start here
for "how does MCP work" questions.
- name: 📐 MCP specification — protocol questions and proposals
url: https://github.com/modelcontextprotocol/modelcontextprotocol/issues
about: >
If the behavior you're reporting is defined by the protocol rather than
by this tool, file it against the specification repository instead.
- name: 🧰 MCP TypeScript SDK
url: https://github.com/modelcontextprotocol/typescript-sdk/issues
about: >
The Inspector is built on the TypeScript SDK. If the bug reproduces
against the SDK directly (outside the Inspector), file it there.
- name: 💬 MCP Contributor Discord (#inspector-dev)
url: https://discord.gg/6CSzBmMkjX
about: >
Questions, usage help, and day-to-day Inspector development discussion.
Also where to say hello if you'd like to work on the Inspector with us.

105
.github/copilot-instructions.md vendored Normal file
View file

@ -0,0 +1,105 @@
# Copilot review instructions — MCP Inspector
> **`AGENTS.md` is the source of truth.** This file is a review-focused distillation of it, kept in sync by hand — see "Keep documentation files up to date" in `AGENTS.md`. Where the two disagree, `AGENTS.md` wins, and the drift is a bug worth flagging in review.
The Inspector ships as one package with three clients (**Web**, **CLI**, **TUI**) over a shared `core/`, consumed via the `@inspector/core` build-time alias. v2 is **not** an npm workspace: the root and each `clients/*` keep their own `package.json` and `node_modules`.
## TypeScript
- **Never use `any`.** Not in types, not in casts, not in generics.
- **Never suppress errors to satisfy the linter or compiler** — no disabling `no-unused-vars` / `no-explicit-any` in config, and no `// @ts-nocheck` or `// @ts-ignore` (`@typescript-eslint/ban-ts-comment` rejects these across every surface).
- **Avoid double casts (`as unknown as T`).** They erase all type safety and usually mean the real type is being worked around. Prefer a type guard, a narrower single cast, or fixing the underlying type. If genuinely unavoidable (a documented gap in a third-party type, or bridging structurally-identical shapes TS can't relate), it **must** carry an inline comment justifying why it's safe and why nothing better exists. An unjustified `as unknown as` is not acceptable in review.
- Prefer inference, type guards, and precise annotations over assertions.
- An `_` prefix is the intentionally-unused marker (`argsIgnorePattern` / `varsIgnorePattern` / `caughtErrorsIgnorePattern`).
## React and UI (web client)
The web client is built from **presentational ("dumb") components** — they take data and callbacks as props and hold display logic only. No data fetching or client state inside them; state comes from the `@inspector/core` hooks wired near the top of the tree. A component that reaches for a store or fetches directly is a review finding.
Styling is **Mantine-first**, in this strict order of preference: component props → theme variants → CSS classes (last resort).
- **Never use inline styles.**
- **Never use raw color literals** — no hex (`#ddd`), no `rgba()`. Use the `--inspector-*` CSS custom properties from `App.css :root` (e.g. `c: 'var(--inspector-text-primary)'`). If no token fits, add one to `:root` first.
- **Avoid `div` and bare HTML for layout.** Use Mantine `Box`, `Group`, `Stack`, `Flex`, `Paper`.
- **Never add a CSS class when the styles can be component props or a theme variant.** Flat CSS properties (margin, padding, background, border, color, font-size) belong in the theme (`src/theme/<Component>.ts`, via `Component.extend()`). `App.css` may contain **only** what the theme cannot express: `@keyframes`, pseudo-selectors (`:hover`, `:focus`), cross-component hover relationships, nested child selectors for third-party HTML output, and styles for native elements (`img`, `iframe`).
- When a theme variant needs a class for nested/pseudo selectors, assign it via `classNames` in the theme extension — never a manual `className` in JSX for theme-styled components.
### The `.withProps()` rule
**Declare a named subcomponent constant via `.withProps()` whenever an inline Mantine element carries two or more _static_ props.** This applies to single-use elements too — "it's only used once" is not an exemption.
- **Static** = a literal configuring **styling, layout, or behavior**: `size="sm"`, `c="dimmed"`, `fw={500}`, `gap="xs"`, `justify="space-between"`, `variant="light"`, `withBorder`, `readOnly`, `striped`.
- **Not counted:** dynamic props (`value`, `on*`, `children`, `key`, `ref`, anything whose value is a variable) — pass these at the call site; and per-instance **content/accessibility** literals (`label`, `description`, `placeholder`, `title`, `aria-label`, `role`) — these never by themselves trigger extraction.
```tsx
const CardContent = Group.withProps({
flex: 1,
align: "flex-start",
justify: "space-between",
wrap: "nowrap",
});
```
**Legitimate exceptions** (each stays inline, with a one-line comment saying why):
- **`Box`** — does not support `.withProps()`. Use `Group`/`Stack`/`Flex`/`Text`/`Paper`/`UnstyledButton`/`Image` instead, chosen by purpose. A `Box` that genuinely needs a non-flex primitive (`component="iframe"`, `display="grid"`) stays inline.
- **`Accordion`** — a compound, `multiple`-discriminated generic; `.withProps()` loses its JSX call signature and fails to type.
- **Headless, non-`factory()` components** such as `Transition` — no Styles API, so no `.withProps` static at all.
- **`data-*` attributes** — not part of a component's typed props, so excess-property-checked out of a `withProps` literal. Pass at the call site.
- **Anything that isn't a Mantine factory component** — a `react-icons` glyph, another library's component, or a first-party plain `export function`.
### State and effects
- **Never reset or re-sync local state from a prop inside a `useEffect`.** `useEffect(() => setX(prop), [prop])` paints the stale value first and renders twice; it is an error under `react-hooks/set-state-in-effect`.
- Use **`useValueChange(value, onChange)`** (`src/hooks/useValueChange.ts`) — React's documented "adjusting state during render" pattern. It does not fire on the first render; seed the state with `useState`. The comparison is `Object.is`, so pass a **referentially stable** value — a primitive key (id/name/URI) or a memoized one, never a fresh object literal.
- The `onChange` runs **during render**, so it must be pure — `setState` and nothing else. No fetches, DOM writes, logging, ref mutation, or parent callbacks; a render can be replayed or abandoned.
- Effects remain correct for real external-system synchronization (DOM measurement, rAF, subscriptions, timers).
### Theme files vs. element components
Both exist and do different jobs. Theme files (`src/theme/<Component>.ts`) customize a Mantine primitive **app-wide**. Element components (`src/components/elements/`) add **domain semantics** on top of primitives.
- Element components import from `@mantine/core`, **not** from `src/theme/` — the theme layer is applied transparently by the provider.
- **Never push domain-specific variant logic into theme files** (annotation types, transport types, …). Domain variants belong to the element component that owns those semantics.
## Where code goes (web client)
**`utils` = functions that compute; `lib` = things that instantiate, adapt, or touch the environment.** If it does I/O or wraps a subsystem it's `lib`; if it's a pure transform it's `utils`.
- `src/utils/` — pure, side-effect-free. Also: pure shared domain types and their constructors; diagnostic `console.warn`/`error` does **not** count as a side effect; type-only imports from `@inspector/core`, and re-exporting pure functions/constants from core, are both fine.
- `src/lib/` — infrastructure, integration, stateful adapters: composes subsystems, wraps the core **runtime**, touches DOM / `window` / `sessionStorage`, or produces side effects.
- Cross-directory imports go **one way: `lib → utils`**, never the reverse.
- `src/types/` is only for ambient `.d.ts` module stubs — not a home for new domain types.
- ⚠️ The coverage `include` is a **whitelist** naming `components` / `hooks` / `theme` / `lib` / `utils` / `server` (plus the `core/*` runtime). A module placed outside those directories silently falls out of the ≥90% gate. Flag new top-level files or new grab-bag directories.
## Tests and the coverage gate
- **All new or modified code needs tests.** The per-file gate is **≥ 90% on all four dimensions** — lines, statements, functions, **and branches** — enforced in CI for `clients/{web,cli,tui,launcher}` and the gated `core/` runtime.
- **Never lower the gate** to accommodate an unreachable branch. Annotate at the source with a justified `/* v8 ignore … -- <reason> */`. Acceptable reasons: happy-dom-inherent paths (Mantine portal mounts, `useMediaQuery` fallbacks, `typeof window` SSR guards), React StrictMode effect-replay blocks, and provably-dead defensive guards. Anything else is a missing test.
- **Suppress expected error output** from the console in tests that exercise error paths.
### Test placement
- **Web:** side-by-side by default — `<Name>.test.tsx` next to the source. A web-owned test under `src/test/` instead of beside its source is a bug. `src/test/` is only for what can't be co-located: tests of the repo-root `core/` package (`src/test/core/…`, mirroring core's layout), the `integration` project (`src/test/integration/…` — placement _is_ the manifest), and shared test infrastructure.
- **CLI / TUI / launcher:** **all** tests live in a top-level `__tests__/` directory. A co-located `src/**/*.test.*` lands in no tsconfig project and fails `verify:typecheck-coverage`.
### Rendering components in tests
- **Always render through `renderWithMantine`** from `src/test/renderWithMantine.tsx`. Never hand-roll a bare `MantineProvider` — that reintroduces a real failure class where a `Transition`/`Modal` timer fires after happy-dom tears down `window` and fails the entire run.
- For a forced color scheme, pass the option — `renderWithMantine(ui, { colorScheme: "dark" })` — rather than a hand-rolled `defaultColorScheme` provider.
- Only when asserting _mid-flight_ transition state, use `renderWithMantineTransitions`, passing `settleMs` derived from the component's real animation duration. Do **not** combine it with `vi.useFakeTimers()`, and use the `unmount()` it returns if the test unmounts the tree itself.
## Gates and PR hygiene
- `npm run format` before committing; **`npm run ci` before pushing** (`validate` → `coverage` → `verify:build-gate` → `smoke` → Storybook). `npm run validate` is the fast inner-loop check and is **not** a substitute — it runs `test`, not `test:coverage`, so it does zero coverage gating.
- **Every PR references an issue**, first body line `Closes #<ISSUE_NUMBER>`.
- **Every PR carries exactly one version label**, `v1` or `v2`, matching its base branch.
- Update the relevant `README.md` / `AGENTS.md` when a change adds, removes, renames, or repurposes a file or folder, changes the structure or tech stack, or introduces a command, dependency, or architectural pattern.
## What to prioritize in review
1. Correctness and security — this backend spawns local processes and proxies outbound requests, so anything touching auth, origin validation, host binding, or the proxy's SSRF controls deserves close reading.
2. Type-safety violations (`any`, suppressions, unjustified double casts).
3. Missing or thin tests against the ≥90% four-dimension gate, and modules placed outside the gated directories.
4. Mantine convention violations — inline styles, raw colors, unnecessary CSS classes, missing `.withProps()` extraction.
5. Docs that contradict the change.

93
.github/dependabot.yml vendored Normal file
View file

@ -0,0 +1,93 @@
version: 2
# Version updates target `v2/main`, the develop branch where all v2 work lands,
# not the default branch — `main` is release-only, holding the latest released
# v2 and receiving milestone merges from `v2/main`. (The deprecated v1 line
# lives on `v1/main` and takes security fixes only.)
#
# Two things to know about this file:
# 1. Dependabot reads it from the DEFAULT branch (`main`). Changes here are
# inert until the next milestone merge carries them there.
# 2. `target-branch` scopes VERSION updates. Dependabot SECURITY updates are
# enabled in repo settings, not here, and are raised against the default
# branch — they kept working while this file was missing entirely
# (see #1833, #1840). Per GitHub's Dependabot options reference, an entry
# whose `target-branch` names a non-default branch is NOT applied to
# security updates, so the schedule/labels/groups below shape version
# updates only. Re-confirm security PRs still appear after this lands.
#
# v2 is not an npm workspace: the root and each client under `clients/*` carry
# their own package.json + lockfile, so each needs its own entry.
updates:
- package-ecosystem: "github-actions"
directory: "/"
target-branch: "v2/main"
schedule:
interval: "monthly"
labels:
- "v2"
groups:
github-actions:
patterns:
- "*"
- package-ecosystem: "npm"
directory: "/"
target-branch: "v2/main"
schedule:
interval: "monthly"
labels:
- "v2"
groups:
root-dependencies:
patterns:
- "*"
- package-ecosystem: "npm"
directory: "/clients/web"
target-branch: "v2/main"
schedule:
interval: "monthly"
labels:
- "v2"
groups:
web-dependencies:
patterns:
- "*"
- package-ecosystem: "npm"
directory: "/clients/cli"
target-branch: "v2/main"
schedule:
interval: "monthly"
labels:
- "v2"
groups:
cli-dependencies:
patterns:
- "*"
- package-ecosystem: "npm"
directory: "/clients/tui"
target-branch: "v2/main"
schedule:
interval: "monthly"
labels:
- "v2"
groups:
tui-dependencies:
patterns:
- "*"
- package-ecosystem: "npm"
directory: "/clients/launcher"
target-branch: "v2/main"
schedule:
interval: "monthly"
labels:
- "v2"
groups:
launcher-dependencies:
patterns:
- "*"

7
.github/pull_request_template.md vendored
View file

@ -11,19 +11,20 @@
If you've found a bug or want a feature:
→ Open an issue instead, labeled for the version you're targeting
(`v1` for `v1/main`, `v2` for `main`).
(`v1` for `v1/main`, `v2` for `v2/main`).
If you've already built the change locally:
→ Open an issue and share the PROMPT(S) you used to generate it, not a
diff. We'll reproduce it through our own workflow.
Full policy: https://github.com/modelcontextprotocol/inspector/blob/main/CONTRIBUTORS.md
Full policy: ../CONTRIBUTING.md (relative to this template — the file lives
at the repository root, on whatever branch you're reading).
Maintainers: delete this template body and describe your change normally.
-->
> **Heads up:** this repository accepts **issues, not pull requests** from
> external contributors. Please read [`CONTRIBUTORS.md`](../blob/main/CONTRIBUTORS.md)
> external contributors. Please read [`CONTRIBUTING.md`](../CONTRIBUTING.md)
> before continuing. If you're an external contributor, open an issue (and
> share the prompt you used, if you've already built the change) rather than
> this PR.

93
.github/workflows/claude.yml vendored Normal file
View file

@ -0,0 +1,93 @@
name: Claude Code
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
issues:
types: [opened, assigned]
pull_request_review:
types: [submitted]
jobs:
claude:
if: |
(
(github.event_name == 'issue_comment' &&
contains(github.event.comment.body, '@claude') &&
contains(fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'), github.event.comment.author_association)) ||
(github.event_name == 'pull_request_review_comment' &&
contains(github.event.comment.body, '@claude') &&
contains(fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'), github.event.comment.author_association)) ||
(github.event_name == 'pull_request_review' &&
contains(github.event.review.body, '@claude') &&
contains(fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'), github.event.review.author_association)) ||
(github.event_name == 'issues' &&
(contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')) &&
contains(fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'), github.event.issue.author_association))
)
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: read
issues: read
id-token: write
actions: read
steps:
- name: Get PR details
if: |
(github.event_name == 'issue_comment' && github.event.issue.pull_request) ||
github.event_name == 'pull_request_review_comment' ||
github.event_name == 'pull_request_review'
id: pr
uses: actions/github-script@v8
with:
script: |
let prNumber;
if (context.eventName === 'issue_comment') {
prNumber = context.issue.number;
} else {
prNumber = context.payload.pull_request.number;
}
const pr = await github.rest.pulls.get({
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: prNumber
});
core.setOutput('sha', pr.data.head.sha);
core.setOutput('repo', pr.data.head.repo.full_name);
- name: Checkout PR branch
if: steps.pr.outcome == 'success'
uses: actions/checkout@v6
with:
ref: ${{ steps.pr.outputs.sha }}
repository: ${{ steps.pr.outputs.repo }}
fetch-depth: 0
- name: Checkout repository
if: steps.pr.outcome != 'success'
uses: actions/checkout@v6
with:
fetch-depth: 0
- name: Run Claude Code
id: claude
uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
# Allow Claude to read CI results on PRs
additional_permissions: |
actions: read
# Trigger when assigned to an issue
assignee_trigger: "claude"
claude_args: |
--mcp-config .mcp.json
--allowedTools "Bash,mcp__mcp-docs"
--append-system-prompt "If posting a comment to GitHub, give a concise summary of the comment at the top and put all the details in a <details> block. When working on MCP-related code or reviewing MCP-related changes, use the mcp-docs MCP server to look up the latest protocol documentation. For schema details, reference https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/schema which contains versioned schemas in JSON (schema.json) and TypeScript (schema.ts) formats."