docs(registry): rename Lookups tag, annotate source/member/discovered_from, /operator auth-aware note

[EmmaLouise2018]

Refs #3538.

Three docs-IA cleanups for the Registry API. Two commits — source-side intentional changes, then mechanical OpenAPI regen — split for review hygiene so reviewers don't skim past the real changes in 500 lines of YAML.

Tag rename: Lookups & Authorization → Authorization Lookups

The & in the tag name forced Mintlify to slugify the URL as lookups-%26-authorization, making /operator-lookup and the other 7 endpoints under that tag effectively unsearchable and unshareable. 8 sites in server/src/routes/registry-api.ts.

Visible URL change: https://docs.adcontextprotocol.org/docs/registry/api-reference/lookups-%26-authorization/operator-lookup → https://docs.adcontextprotocol.org/docs/registry/api-reference/authorization-lookups/operator-lookup.

source / member / discovered_from descriptions

server/src/schemas/registry.ts — adds .openapi({ description }) on three fields that previously rendered as bare attributes:

• source — explains registered (AAO-attested, opt-in) vs discovered (crawled from a publisher's adagents.json, no opt-in) and that they are different trust levels.
• member — explains it is null for discovered agents even when the publisher_domain is owned by a member (decision(registry): how should discovered agents surface member-publisher endorsement (#3538 Problem 6) #3547 — separate decision issue).
• discovered_from — explains it is mutually exclusive with member.

/api/registry/operator auth-aware description

The endpoint description now spells out that the response shape changes by caller:

• Anonymous → public agents only
• AAO API-tier callers → adds members_only agents
• Profile owners → adds private agents

This is the primary mechanism by which AAO membership unlocks deeper registry visibility — previously documented nowhere except the source.

Commits

b3993d8c0  docs(registry): rename Lookups tag, annotate source/member/discovered_from, /operator auth-aware note
7b9056b10  chore(registry): regenerate static/openapi/registry.yaml

The first commit is 38 lines across 3 source files (changeset, registry-api.ts, registry.ts) — that's the intentional change.

The second commit is the mechanical npm run build:openapi regen — 503 lines of static/openapi/registry.yaml. It also picks up pre-existing drift from earlier PRs that didn't run the regen (verified-badge fields, declared_specialisms, check_interval_hours, VerifiedBadge schema). Pure mechanical catch-up; no behavior change beyond what the source commit already contains.

Reviewers should focus on commit 1. Commit 2 is hygiene.

Test plan

• npx tsc --noEmit -p server/tsconfig.json — clean.
• npx vitest run server/tests/unit/openapi-coverage.test.ts — 3/3 pass.
• npm run build:openapi regenerates cleanly with stub WORKOS env vars.
• Pre-commit hooks green.

Stack ordering

Recommended merge order from #3538: 3540 → 3542 → 3543 → 3541. #3542 lands second so #3543 can use the new authorization-lookups URL slug directly without a follow-up TODO.

Independent of #3540 (different lines in registry-api.ts) and #3541 (no file overlap). The OpenAPI regen captures drift that may conflict with other in-flight PRs touching the registry API — first-merger may need a re-regen.

Out of scope

• docs(registry): /publisher auth-aware response note (parity with /operator) #3546 — /publisher auth-aware parity check (does the same caller-tier visibility logic apply to /publisher?).
• ?source= query param + UI segmentation on /registry (Problem 3 P1 in Registry: follow-ups from #3495 — stale types, registered/discovered conflation, docs IA gaps, non-member path #3538).
• Surfacing member-publisher endorsement on discovered agents (decision(registry): how should discovered agents surface member-publisher endorsement (#3538 Problem 6) #3547 — Problem 6 decision).