@kryptosai/mcp-observatory 0.22.0 → 0.24.0

package/docs/metrics-dashboard.md

@@ -0,0 +1,105 @@
+# Local Metrics Dashboard
+
+MCP Observatory includes a private laptop dashboard for collecting telemetry, GitHub activity, and npm download data going forward.
+
+The dashboard is intentionally local. It stores raw telemetry in a SQLite database on your laptop, then renders a sanitized static HTML view that is safe to screenshot or skim without exposing raw emails, hostnames, private URLs, tokens, or private command bodies.
+
+The layout follows an App Store Connect-style breakdown:
+
+- Overview
+- Acquisition
+- Downloads
+- Usage
+- Reliability
+
+Daily rows are shown newest to oldest so the most recent project activity is always at the top.
+
+## Refresh
+
+```bash
+npm run metrics:refresh
+npm run metrics:serve
+```
+
+Outputs are written to:
+
+- `.mcp-observatory-metrics/observatory.sqlite`
+- `.mcp-observatory-metrics/dashboard/index.html`
+- `.mcp-observatory-metrics/dashboard/latest.json`
+- `.mcp-observatory-metrics/logs/`
+
+The local metrics directory is ignored by git and should not be published.
+
+## Data Sources
+
+The collector stores each source independently. If one source fails, the dashboard still builds from the last good SQLite data and records the failure in the Reliability section.
+
+| Source | Data |
+| --- | --- |
+| Telemetry | Existing Cloudflare D1 export flow via `scripts/export-telemetry-d1.ts` |
+| GitHub | clones, views, referrers, popular paths, repo snapshot, latest release, open issue/PR counts, workflow runs |
+| npm | public daily downloads for `@kryptosai/mcp-observatory` |
+
+GitHub traffic APIs have a limited visible window, so the collector stores snapshots locally going forward. npm daily buckets can lag; the dashboard labels npm data as complete public days rather than assuming current-day zero.
+
+## Credentials
+
+GitHub collection uses either:
+
+```bash
+gh auth login
+```
+
+or:
+
+```bash
+export GH_TOKEN=...
+```
+
+Telemetry collection uses the same Wrangler configuration as the existing telemetry export script. If the config is not auto-discovered, set:
+
+```bash
+export MCP_OBSERVATORY_TELEMETRY_WRANGLER_CONFIG=/path/to/wrangler.toml
+export MCP_OBSERVATORY_TELEMETRY_D1_DATABASE=mcp-observatory-telemetry
+```
+
+No npm token is required for public download counts.
+
+## Commands
+
+```bash
+npm run metrics:collect   # collect telemetry, GitHub, and npm into SQLite
+npm run metrics:build     # render HTML from the existing SQLite database
+npm run metrics:refresh   # collect + build
+npm run metrics:open      # open the static read-only dashboard
+npm run metrics:serve     # open the local dashboard with an Update Data button
+```
+
+The **Update Data** button is available in `metrics:serve` mode. A static `file://` dashboard cannot run local commands from the browser, so `metrics:open` shows the same data but disables the button.
+
+For tests or offline recovery, you can seed telemetry from an existing export:
+
+```bash
+npm run metrics:refresh -- --telemetry-input telemetry-exports/events-flat-full.json
+```
+
+## Optional Hourly Refresh
+
+Generate a small local refresh wrapper:
+
+```bash
+npx tsx scripts/metrics-dashboard.ts scheduler
+```
+
+The generated script lives under `.mcp-observatory-metrics/` and can be called by `launchd` or cron. It uses the same refresh command and writes logs to `.mcp-observatory-metrics/logs/refresh.log`.
+
+## Privacy
+
+Raw telemetry remains available in the local SQLite database for account intelligence and product analytics. The dashboard view uses sanitized aggregates by default:
+
+- company domains, not raw emails
+- aggregate source and command counts, not private command bodies
+- GitHub and npm public metrics
+- collection errors and freshness status
+
+Do not commit `.mcp-observatory-metrics/`, telemetry exports, private reports, or screenshots that reveal raw data.

package/docs/paid-pilot-offer.md

@@ -0,0 +1,74 @@
+# Paid Pilot Offer
+
+## Private MCP Readiness Review
+
+Offer:
+
+> Private MCP readiness review + CI rollout + drift/security report.
+
+This is a manual pilot, not a self-serve SaaS promise.
+
+## Who It Is For
+
+- teams running MCP servers in production or pre-production
+- security/platform teams reviewing agent tool dependencies
+- companies with private MCP repos
+- teams that need proof before agents depend on internal tools
+
+## What The Pilot Includes
+
+- MCP server inventory across selected repos, configs, or agent environments
+- reproducible test artifacts for each reviewed server
+- private readiness report covering startup, capabilities, schema quality, security findings, and drift risk
+- schema/tool drift baseline using MCP lock files
+- MCP Observatory CI rollout plan for selected servers
+- executive summary with “safe for agent dependency” verdicts
+- prioritized remediation notes and owner-ready next steps
+- optional certification language for servers that pass agreed checks
+
+## Starting Prices
+
+- Business Pilot: starts at `$999/month`
+- Enterprise Pilot: starts at `$3k/month`
+- Strategic Accounts: custom, `$250k+/year`
+
+Do not route major platforms, AI labs, or large enterprises to Team/Business pricing. Use a production/security pilot conversation and ask for the owner or procurement path.
+
+## Simple Outreach Copy
+
+Subject: Private MCP readiness review
+
+Hi,
+
+I build MCP Observatory, the CI and security gate for MCP servers before agents depend on them.
+
+I am opening a small number of private MCP readiness pilots for teams running MCP in production or pre-production. The pilot includes CI rollout, schema/security review, drift checks, and a private readiness report for your MCP servers.
+
+If MCP is becoming part of your agent infrastructure, I can help you answer:
+
+- which servers are safe enough for agents to depend on?
+- which tool surfaces changed recently?
+- where are the schema/security risks?
+- what should block a PR before production?
+
+Would it be useful to compare notes this week?
+
+William
+
+## Delivery Shape
+
+Start with static reports and CI setup. The first deliverable should look like an internal security/readiness packet, not a SaaS login.
+
+## Evidence Standard
+
+The public [Safety Methodology](./methodology.md) and [MCP Server Safety Index](./mcp-server-safety-index.md) are the template for private work:
+
+- command/config used
+- date and tool version
+- JSON artifact
+- Markdown or HTML report
+- failure class
+- verdict
+- reproduction notes
+
+Private pilots can include customer-specific details, but public/customer-facing summaries should use sanitized evidence unless the customer approves otherwise.

package/docs/project-case-study.md

@@ -4,9 +4,17 @@
 
 MCP Observatory is CI/security infrastructure for production MCP servers.
 
-## Problem
+## Project Narrative
 
-MCP servers are becoming dependencies for AI agents. Teams need to know whether those servers still start, expose usable tools, keep schemas stable, avoid obvious security footguns, and behave consistently as agents depend on them.
+MCP Observatory identifies an emerging risk in AI agent infrastructure and turns it into a practical OSS control: CI checks, security reports, drift detection, telemetry intelligence, and certification workflows for production MCP servers.
+
+The project is strongest as a signal because it connects product intuition with implementation depth. It starts from a real infrastructure shift, builds a working developer tool around that shift, instruments usage, and creates a credible path from open source adoption to production security workflows.
+
+## Problem Discovery
+
+MCP servers are becoming dependencies for AI agents. They expose tools, prompts, resources, and data access that agents can call directly. When those servers drift, fail to start, expose broad capabilities, or return ambiguous schemas, the failure can propagate into agent workflows.
+
+The control gap is simple: teams need a way to test MCP servers before agents depend on them. They also need artifacts that maintainers, platform engineers, and security reviewers can understand.
 
 ## Product
 
@@ -23,46 +31,61 @@ MCP Observatory provides:
 - static enterprise reports
 - telemetry intelligence for product and account-level learning
 
-## Architecture
+## System Design
 
-The project is a TypeScript/Node CLI with modular command handlers, MCP adapters, check runners, reporters, artifact schemas, and a GitHub Action wrapper. A Cloudflare Worker handles hosted artifact upload pilots, and a separate telemetry Worker stores private aggregate usage events in D1.
+The project is a TypeScript/Node CLI with modular command handlers, MCP adapters, check runners, reporters, artifact schemas, and a GitHub Action wrapper.
 
-## Technical Proof
+The system supports local-process and HTTP MCP targets, stores run artifacts, compares runs for regressions, generates reports for humans and CI systems, and can run as an MCP server itself. A Cloudflare Worker handles hosted artifact upload pilots. A separate telemetry Worker stores private aggregate usage events in D1 for product and account intelligence.
 
-As of June 19, 2026:
+## Security Model
 
-- 10k+ source lines in `src`
-- 40 test files
-- 321 passing tests
-- npm package published
-- GitHub Action available
-- MCP server mode available
-- telemetry export and company intelligence tooling available
+MCP Observatory treats MCP servers as agent-facing infrastructure. The goal is not to claim formal semantic safety. The goal is to make compatibility, drift, and obvious security risk visible before deployment.
 
-## Traction Snapshot
+Current controls include:
 
-Safe public and aggregate signals:
+- lightweight security checks for risky schema patterns
+- schema quality analysis for agent usability
+- SARIF output for security review workflows
+- support for security suppressions when broad tools are intentional
+- private-network rejection for hosted scans
+- privacy disclosure and telemetry opt-out controls
+- sanitized public reporting policy
 
-- 10,278 telemetry events
-- 7,211 telemetry sessions
-- 5,368 external sessions after separating internal activity
-- 582 GitHub clones and 175 unique cloners in the visible June 2026 traffic window
-- 104 npm downloads during June 11-17, 2026
+For deeper context, see the [MCP Server Security Field Guide](./mcp-security-field-guide.md).
 
-These are early signals. Public social proof is still limited and should be improved through the certification campaign.
+## Telemetry Intelligence
 
-## Security And Privacy Posture
+Telemetry is used privately to understand product usage and identify account-level signals without publishing raw personal data.
 
-The project includes:
+As of the latest local export on June 21, 2026:
 
-- telemetry opt-out controls
-- privacy disclosure
-- security policy
-- token-based hosted artifact upload
-- private-network rejection for hosted scans
-- sanitized public reporting policy
+- 11,481 telemetry events
+- 7,571 total sessions
+- 5,389 external sessions after separating internal activity
+- 2,446 external CI sessions
+- 148 attributed company/org sessions
+- 12 attributed company/org candidates
+- latest external activity: June 21, 2026
 
-Public claims should use aggregate metrics and accepted public integrations, not raw telemetry.
+Public claims use aggregate or sanitized data only. Raw emails, hostnames, private URLs, tokens, and response bodies are not published.
+
+## Distribution Strategy
+
+The distribution wedge is useful CI for other MCP repositories. The certification campaign opens small, helpful PRs that add MCP compatibility/security checks and leave maintainers with a public trust signal.
+
+Current public distribution proof includes:
+
+- latest release: `v0.23.0`
+- npm package: `@kryptosai/mcp-observatory`
+- GitHub Action: `KryptosAI/mcp-observatory/action@main`
+- npm downloads snapshot: 511 downloads for June 11-20, 2026
+- visible GitHub traffic window: 745 clones and 232 unique cloners
+- visible GitHub page-view window: 12 views and 9 unique visitors
+- public code-search references in MCP indexes, listing mirrors, and external experiment repos
+- official MCP reference PR open and green: [`modelcontextprotocol/servers#4392`](https://github.com/modelcontextprotocol/servers/pull/4392)
+- open certification PRs for Microsoft Playwright MCP, Upstash Context7, ExecuteAutomation Playwright MCP, AntV, BrowserMCP, UI5, Notion, and other MCP projects
+
+See [reference evaluations](./reference-evaluations.md) and [public proof](./proof.md).
 
 ## Commercial Path
 
@@ -83,24 +106,35 @@ Current pilot anchors:
 - Enterprise: starts at `$3k/month`
 - Strategic: `$250k+/year`
 
-## Job-Opportunity Value
+## Professional Signal
 
-This project demonstrates ability across:
+MCP Observatory demonstrates applied work across:
 
-- AI infrastructure
+- AI agent infrastructure
 - developer tooling
-- security tooling
-- MCP ecosystem work
+- secure tool invocation
+- software supply chain thinking
 - CI/CD integrations
 - telemetry and product analytics
-- commercialization and enterprise packaging
+- open source distribution
+- enterprise packaging
+
+It is designed to be evaluated through public work: code, docs, CI integrations, reference evaluations, proof surfaces, and real maintainer PRs.
+
+## Future Roadmap
+
+Near-term milestones:
 
-It is strongest as a portfolio asset when paired with public proof: accepted external PRs, badges in other repos, directory listings, and a short demo.
+1. Convert certification PRs into accepted public integrations.
+2. Publish recurring MCP safety reports.
+3. Add stronger policy/provenance language for production MCP adoption.
+4. Improve hosted artifact upload into a simple pilot workflow.
+5. Convert serious production users into paid pilots.
 
-## Next Milestones
+Longer-term opportunities:
 
-1. Publish latest package with `init-ci`.
-2. Open first certification PR wave.
-3. Capture accepted PRs as public proof.
-4. Publish recurring MCP safety reports.
-5. Convert serious users into paid pilots.
+- policy controls for agent tool use
+- provenance for MCP packages and configurations
+- schema locks and controlled drift review
+- runtime monitoring for production agent tool calls
+- fleet inventory across teams, repositories, and hosts

package/docs/proof.md

@@ -5,23 +5,34 @@ MCP Observatory is early, but it is already a working MCP testing/security stack
 ## Current Public Surface
 
 - npm package: `@kryptosai/mcp-observatory`
-- GitHub Action: `KryptosAI/mcp-observatory/action@main`
+- GitHub Action: `KryptosAI/mcp-observatory/action@v0.24.0`
+- Latest release: `v0.23.0`
 - CLI command count: scan, test, record, replay, verify, diff, watch, suggest, serve, lock, history, init-ci, ci-report, enterprise-report, score, badge, cloud
-- Test suite: 321 passing tests across 40 test files as of June 19, 2026
-- GitHub traffic snapshot: 582 clones and 175 unique cloners in the visible June 2026 traffic window
-- npm downloads snapshot: 104 downloads for June 11-17, 2026
+- Test suite: 334 passing tests across 43 test files as of June 20, 2026
+- GitHub traffic snapshot: 745 clones and 232 unique cloners in the visible June 2026 traffic window
+- GitHub page views snapshot: 12 views and 9 unique visitors in the visible June 2026 traffic window
+- npm downloads snapshot: 511 downloads for June 11-20, 2026
+- Security guide: [MCP Server Security Field Guide](./mcp-security-field-guide.md)
+- Safety methodology: [MCP Observatory Safety Methodology](./methodology.md)
+- Safety index: [MCP Server Safety Index](./mcp-server-safety-index.md)
+- Public examples: [Reference Evaluations](./reference-evaluations.md)
+- Lock-file CI primitive: [MCP Lock Files](./mcp-lock-files.md)
+- Public post drafts: [Launch Post Drafts](./public-post-drafts.md)
+- Pilot offer: [Private MCP Readiness Review](./paid-pilot-offer.md)
 
 ## Safe Aggregate Telemetry Snapshot
 
 Internal telemetry is used for product analytics and account-level outreach. Public reporting uses only aggregate or sanitized data.
 
-As of the latest local export on June 19, 2026:
+As of the latest local export on June 21, 2026:
 
-- 10,278 telemetry events
-- 7,211 unique sessions
-- 5,368 external sessions after separating internal/personal activity
-- 2,434 external CI sessions
-- 128 attributed company/org sessions
+- 11,481 telemetry events
+- 7,571 total sessions
+- 5,389 external sessions after separating internal/personal activity
+- 2,446 external CI sessions
+- 148 attributed company/org sessions
+- 12 attributed company/org candidates
+- latest external activity: June 21, 2026
 - top external commands: `serve`, `run`, `diff`, `test`, `scan`, `history`
 
 Raw emails, hostnames, private URLs, tokens, and response bodies are not published.
@@ -46,11 +57,30 @@ MCP Observatory can:
 
 The certification campaign is designed to create public proof through accepted maintainer PRs.
 
-Accepted third-party integrations will be tracked here:
+Open and accepted third-party integrations are tracked here:
 
 | Repo | PR | Check Added | Badge Added | Status |
 | --- | --- | --- | --- | --- |
-| _pending_ | | | | |
+| `modelcontextprotocol/servers` | [#4392](https://github.com/modelcontextprotocol/servers/pull/4392) | Yes | No | Open, mergeable, MCP Observatory check passing |
+| `microsoft/playwright-mcp` | [#1657](https://github.com/microsoft/playwright-mcp/pull/1657) | Yes | No | Closed, unmerged |
+| `upstash/context7` | [#2800](https://github.com/upstash/context7/pull/2800) | Yes | No | Closed, maintainer declined third-party CI |
+| `executeautomation/mcp-playwright` | [#225](https://github.com/executeautomation/mcp-playwright/pull/225) | Yes | No | Open |
+| `kazuph/mcp-taskmanager` | [#11](https://github.com/kazuph/mcp-taskmanager/pull/11) | Yes | No | Open |
+| `cyanheads/filesystem-mcp-server` | [#19](https://github.com/cyanheads/filesystem-mcp-server/pull/19) | Yes | No | Closed, unmerged |
+| `antvis/mcp-server-chart` | [#312](https://github.com/antvis/mcp-server-chart/pull/312) | Yes | No | Open |
+| `BrowserMCP/mcp` | [#189](https://github.com/BrowserMCP/mcp/pull/189) | Yes | No | Open |
+| `UI5/mcp-server` | [#348](https://github.com/UI5/mcp-server/pull/348) | Yes | No | Closed, maintainer declined third-party CI |
+| `makenotion/notion-mcp-server` | [#324](https://github.com/makenotion/notion-mcp-server/pull/324) | Yes | No | Closed after policy-style CI failure |
+
+## Public Discovery Snapshot
+
+GitHub code search shows public references outside the main repo. These are discovery/listing signals, not customer claims:
+
+- `punkpeye/awesome-mcp-devtools` lists MCP Observatory in an MCP developer-tools index.
+- `linny006/mcp-servers-live` mirrors a public MCP Observatory listing page.
+- `gabrielmoreira/awesome-ai-rabbit-holes` catalogs the GitHub project.
+- `fmfg03/supermcp` includes an `apps/mcp-observatory` package path.
+- `vellankikoti/mcp-observatory`, `LuKrlier/mcp-observatory`, and `shigeki7777/sasame-mcp-observatory` appear as separate public repos referencing or experimenting with the Observatory name/code surface.
 
 ## Commercial Proof
 

package/docs/public-post-drafts.md

@@ -0,0 +1,98 @@
+# Public Post Drafts
+
+Use these as launch posts, GitHub Discussion posts, LinkedIn posts, or short blog drafts. The framing is about MCP safety patterns, not “look at my tool.”
+
+## Flagship Post: I Tested Popular MCP Servers. The Failure Pattern Was Not What I Expected.
+
+MCP servers are becoming production dependencies for agents, but many of them still ship without the kind of CI gate we expect from normal software dependencies.
+
+The main pattern I saw while building the first MCP Server Safety Index was simple: the risky part is rarely that a server exists. The risky part is that agents may depend on a tool surface nobody is testing for startup reliability, schema quality, security posture, or drift.
+
+The industry does not need another vibes-based directory. It needs reproducible readiness evidence:
+
+- exact command/config
+- date and package version where available
+- JSON artifact
+- Markdown report
+- verdict
+- failure class
+- reproduction notes
+
+The checks that matter most:
+
+- does the server start cleanly in CI?
+- do tools, prompts, and resources respond as advertised?
+- are tool schemas precise enough for agents to call safely?
+- did a release add, remove, or broaden a tool?
+- are destructive tools clearly identifiable?
+
+My takeaway: MCP needs a package-lock moment. Commit the agent-facing contract, then make drift visible before agents depend on it.
+
+I am publishing the Safety Methodology and the first MCP Server Safety Index as a small evidence standard, not a leaderboard. If your team is putting MCP into private or production agent workflows, I am doing a small number of private MCP readiness reviews: inventory, CI rollout, schema/tool drift baseline, security findings, and safe-for-agent-dependency verdicts.
+
+## Supporting Angle: Browser MCP Servers Need A Different Security Bar
+
+Browser automation MCP servers are powerful because agents can navigate pages, click, type, inspect state, and sometimes execute scripts.
+
+That is exactly why they need explicit CI and security gates.
+
+For browser MCP servers, a useful review should separate:
+
+- harmless inventory checks
+- state-mutating browser actions
+- code execution or page-evaluation tools
+- network/navigation controls
+- tool schemas that are too broad for safe agent planning
+
+The goal is not to block browser MCP. The goal is to make the trust boundary visible before an agent gets browser-control powers.
+
+## Supporting Angle: Filesystem MCP Servers Should Always Test In A Sandbox
+
+Filesystem MCP servers are one of the clearest examples of why MCP CI needs context.
+
+A server can be useful and still dangerous if the test command points at the wrong directory, if read/write boundaries are unclear, or if a tool schema makes broad path access look harmless.
+
+The minimum safety pattern:
+
+- run CI against a temporary harmless directory
+- verify tools/resources respond as advertised
+- flag broad filesystem access
+- document which operations are read-only vs write-capable
+- treat changes to path schemas as contract drift
+
+Agents need tools. They do not need accidental access to everything.
+
+## Supporting Angle: Token-Backed SaaS MCP Servers Need Issue-First Certification
+
+Many SaaS, cloud, payments, database, and developer-platform MCP servers cannot be safely checked with a drive-by PR because meaningful startup requires tokens or live services.
+
+For those repos, the right move is usually not a workflow PR first. It is an issue or maintainer question:
+
+“What is the safest CI startup command for this server?”
+
+Once maintainers provide a token-safe target config, the useful checks are:
+
+- does startup fail cleanly without credentials?
+- are auth requirements documented?
+- are destructive tools obvious?
+- are schemas narrow enough for agent use?
+- can the repo publish a safe compatibility/security badge?
+
+Security adoption works better when it starts by respecting maintainer context.
+
+## Supporting Angle: MCP Drift Is An AI Supply Chain Problem
+
+When a package dependency changes, teams have lock files, diffs, review, and release notes.
+
+When an MCP server changes its tool surface, an agent dependency changed too.
+
+That means tool additions, tool removals, schema broadening, new write actions, and prompt/resource changes should be visible in pull requests.
+
+The useful primitive is an MCP lock file:
+
+```bash
+npx @kryptosai/mcp-observatory lock
+npx @kryptosai/mcp-observatory lock verify
+```
+
+The point is not bureaucracy. It is to make the agent-facing contract reviewable before production workflows quietly depend on something new.

package/docs/publish-readiness.md

@@ -22,20 +22,21 @@ Confirm:
 - HTTP target examples use env references instead of inline tokens.
 - Security findings appear in artifact evidence as structured `findings`.
 - Hosted upload is available through `mcp-observatory cloud upload <artifact>` when `MCP_OBSERVATORY_CLOUD_TOKEN` is set.
+- Hosted HTTP scans require `Authorization: Bearer <HOSTED_SCAN_TOKEN>` and are treated as an authenticated pilot surface.
 
 Known audit note:
 
-- `npm audit` may report `undici <=6.26.0` through the `npm@11.17.0` package bundled under `@semantic-release/npm`. `npm audit fix` updates the fixable `@actions/http-client` path, but the remaining `undici` copy is bundled inside npm release tooling and is not part of MCP Observatory runtime dependencies or the packed npm artifact. Recheck after npm publishes a newer package.
+- Release automation runs `semantic-release` ephemerally in GitHub Actions instead of installing it into the repository lockfile. This keeps release-only bundled dependencies out of the default-branch audit surface and out of the packed CLI artifact.
 
 ## Public Distribution
 
 - Merge the health/commercialization PR.
 - Update the GitHub repo homepage to the README or commercial page.
 - Publish npm only after the release gate is green.
-- Refresh MCP directory listings with: “MCP Observatory helps teams test, secure, and monitor MCP servers before agents depend on them.”
-- Include “free for local OSS use; paid for hosted reporting, private repo CI, security reports, production monitoring, certification, support, and fleet visibility.”
+- Refresh MCP directory listings with: “MCP Observatory is the CI and security gate for MCP servers before agents depend on them.”
+- Include “free for local OSS use; paid for hosted reporting, private repo CI, recurring security reports, certification, support, and fleet visibility.”
 - Link production users to `COMMERCIAL.md` and `william@banksey.com`.
-- Submit or refresh listings on Glama, PulseMCP, Smithery, and relevant awesome-MCP lists with the tags: security, developer tools, CI/CD, testing, observability, schema drift.
+- Submit or refresh listings on Glama, PulseMCP, Smithery, and relevant awesome-MCP lists with the tags: security, developer tools, CI/CD, testing, MCP security, schema drift.
 - Use the certification distribution loop to open helpful PRs against popular MCP server repos and convert accepted PRs into proof points.
 - Link public proof, the safety report, and directory listing copy from launch/outreach materials.
 
@@ -67,6 +68,7 @@ Worker:
 
 - `POST /api/v1/artifacts` stores a run artifact behind bearer-token auth.
 - `GET /api/v1/artifacts/:org` returns the org artifact index behind the same auth.
+- `POST /api/v1/scan` requires `Authorization: Bearer <HOSTED_SCAN_TOKEN>`.
 - Hosted scans reject localhost/private-network targets; use local CLI for internal MCP servers.
 
 ## What Not To Do Yet