Consolidates the five open dependabot PRs into a single change so they
can be reviewed and merged together. Each bump was reproduced against
current `main` (`go get` + `go mod tidy` for Go modules; the exact SHA
pins applied for the actions group), rather than merging the individual
branches, to avoid stale `go.sum` conflicts.
## Root module (`go.mod`)
| Dependency | From | To | Supersedes |
|---|---|---|---|
| `google.golang.org/grpc` | 1.82.0 | 1.82.1 | #1479 |
| `github.com/prometheus/client_golang` | 1.23.2 | 1.24.1 | #1475 |
| `github.com/danielgtaylor/huma/v2` | 2.38.0 | 2.39.0 | #1474 |
## Deploy module (`deploy/go.mod`)
| Dependency | From | To | Supersedes |
|---|---|---|---|
| `github.com/pulumi/pulumi-kubernetes/sdk/v4` | 4.32.0 | 4.33.0 | #1449
|
## GitHub Actions (#1476)
- `actions/setup-go` SHA bumped across `ci.yml`, `release.yml`,
`deploy-production.yml`, `deploy-staging.yml`
- `actions/download-artifact` v4 → v8.0.1 in
`close-invalid-publish-prs.yml`
`go mod tidy` re-resolved transitive dependencies in both modules
accordingly.
## Verification
- `go build ./...` passes (root + deploy)
- `go vet ./...` passes
- `govulncheck ./...` reports no `golang.org/x/text` finding (the
GO-2026-5970 fix from #1481 is preserved; tidy pulled x/text to v0.40.0)
## Follow-up
Once this merges, the five superseded PRs (#1479, #1475, #1474, #1449,
#1476) can be closed.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
## What
Stage 2 of the auto-close automation (`close-invalid-publish-prs.yml`)
re-derived the PR author association with:
```bash
gh pr view "$PR_NUMBER" --json authorAssociation --jq '.authorAssociation'
```
But `gh pr view --json` has **no** `authorAssociation` field. `gh` exits
non-zero with `Unknown JSON field: "authorAssociation"`, and because the
step runs under `set -euo pipefail`, the whole job aborts **before** it
comments, labels, or closes. Flagged PRs therefore stayed open.
## Why it went unnoticed
- **Stage 1 (detect) was fine** — it reads `author_association` from the
event payload (`github.event.pull_request.author_association`), which is
valid.
- Only the **stage-2 re-derivation** was broken.
- Every prior stage-2 run showed "success" because those PRs weren't
flagged: with no artifact, stage 2 exits early at the artifact check and
never reaches the broken line.
- **[PR
#1438](https://github.com/modelcontextprotocol/registry/pull/1438) was
the first genuine publish-attempt PR** since the automation landed
(#1393), so it was the first to exercise the bug — [run
`29178568034`](https://github.com/modelcontextprotocol/registry/actions/runs/29178568034)
failed on exactly this line.
## Fix
Fetch `author_association` from the REST pulls endpoint, which does
expose it (verified: returns `FIRST_TIME_CONTRIBUTOR` for #1438):
```bash
gh api "repos/$GH_REPO/pulls/$PR_NUMBER" --jq '.author_association'
```
Both `$GH_REPO` and `$PR_NUMBER` are already-sanitized env vars, so no
new injection surface.
## Follow-up
Stage 2 is idempotent (guarded by the `invalid` label), so once merged a
maintainer can re-run it — or simply re-open/re-close — to clean up
#1438.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
## Summary
We keep getting PRs (e.g. #1385, #1368, #1367, #1363, #1354) that try to
"publish" an MCP server by adding files under `servers/` or editing
`data/seed.json`. That isn't how publishing works — servers are
published with the `mcp-publisher` CLI against the live registry API.
This adds automation that detects those PRs, comments with a pointer to
the publishing quickstart, labels them `invalid`, and closes them.
## How it works (two stages, no `pull_request_target`)
`pull_request_target` is intentionally avoided. Instead:
- **Stage 1 — `detect-invalid-publish-prs.yml`** runs on `pull_request`
(opened/reopened) with a **read-only** token. It only reads the changed
file paths and, if the PR *exclusively* touches `servers/**` and/or
`data/seed.json` (and the author isn't a MEMBER/OWNER/COLLABORATOR),
records just the PR number as a short-lived artifact. It can't comment
or close anything.
- **Stage 2 — `close-invalid-publish-prs.yml`** runs via `workflow_run`
in the trusted base-repo context (write token). It picks up the flagged
PR number, **independently re-validates** the PR from the API (still
open, external author, files still match, not already labeled), then
comments, labels `invalid`, and closes.
### Trust boundary
The only thing crossing from the untrusted stage to the privileged stage
is the **PR number**, sanitized to digits only. Stage 2 never trusts
stage 1's verdict — it re-derives every decision. Neither stage ever
checks out or runs PR code.
### Safety against false positives
- Fires only when a PR touches *exclusively* `servers/**` and/or
`data/seed.json` — a real code PR that also happens to touch seed data
is left alone.
- Skips `MEMBER`/`OWNER`/`COLLABORATOR` authors, so maintainers editing
dev seed data aren't auto-closed.
- Idempotent: skips PRs already labeled `invalid` (e.g. if a maintainer
reopens one).
## Notes
- Like any `pull_request`/`workflow_run` automation, this only takes
effect **once merged to `main`** — it is not retroactive and won't run
on this PR. The currently-open offending PRs should be closed manually.
- Pinned action SHAs match the repo's existing convention
(`upload-artifact` reuses the SHA already in `ci.yml`).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
