| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
685e354b2f |
feat: add cargo (crates.io) as a package registry type (#1207)
> **Update — 2026-06-01 (commit 1f3be53)** > > - **All @P4ST4S review feedback addressed** — positive-path hermetic mock + live anchor against `rust-faf-mcp v0.3.1`; 5xx routed as transient; doc comment qualified. See the [close-out comment](https://github.com/modelcontextprotocol/registry/pull/1207#issuecomment-4589711057) for the per-item breakdown. > - **Runtime-model question RESOLVED** — `package-types.mdx` documents cargo and MCPB as both first-class Rust MCP distribution paths (cargo for source-distributed, MCPB for prebuilt-binary). The "Open question" section below was the original draft framing; the doc now ships the resolution. > - **Cargo-specific gotcha discovered and documented** — crates.io strips HTML comments during README rendering, unlike PyPI/NuGet. `package-types.mdx` now spells this out so cargo authors don't ship invisible mcp-name tokens (which is exactly what happened to `rust-faf-mcp v0.3.0`; fixed in v0.3.1). > - **Stale reference removed in this update** — the "Out of scope" line mentioning `docs/guides/publishing/publish-cargo.md` pointed at a path that doesn't exist. The canonical per-type doc is `docs/modelcontextprotocol-io/package-types.mdx`; the Cargo section has been added there directly. > - **Two real-world Rust MCP servers queued for day-one register**: `rust-faf-mcp v0.3.1` (live, end-to-end validated by the new live test) and `perfetto-mcp-rs` ([@0xZOne](https://github.com/0xZOne) in #1055). > - **Tests:** 19/19 cargo tests pass (16 existing + 2 hermetic + 1 live anchor). `make validate` clean. `golangci-lint` 0 issues. --- Adds support for `registryType: cargo` so Rust MCP servers published to crates.io can be registered through the documented validation flow rather than the MCPB binary-packaging workaround. Closes #1055. ## Motivation and Context #1055 noted that crates.io has ~1,800 MCP-related packages with no direct path into the registry — only the MCPB binary-packaging workaround. This PR adds first-class support for cargo as a package registry type: schema + API surface, validator, integration tests, and a documented example. The publishing guide (`docs/guides/publishing/publish-cargo.md`) follows on this branch once the runtime-model direction in **Additional context** is settled. ## How Has This Been Tested? - **`make validate`** — clean. Schema-vs-openapi sync verified; 17/17 examples in `generic-server-json.md` validate against the schema; `expectedServerJSONCount` bumped 16 → 17 to match the new Cargo example. - **`go test ./internal/validators/...`** — passes. 16 cargo validator sub-cases across 4 test functions, run against real crates.io (~2.5s wall): - Input validation rejection paths - Registry-baseURL rejection (4 variants: different host, trailing slash, http-not-https, subdomain typo) - Ownership validation against real crates (`serde`, `tokio`, `rand`) — all correctly rejected for missing `mcp-name` token - Server-name format variations (canonical `io.github.OWNER/REPO`, multi-hyphen, underscore, numeric suffix) - **Positive-path test** — gated on `rust-faf-mcp` v0.2.3+ being published with `mcp-name: io.github.Wolfe-Jam/rust-faf-mcp` in its README. Reserved as a TODO in `cargo_test.go`; uncomments to become the live anchor once that publish lands. - **Local `make test-unit`** — not run due to a Go toolchain version quirk on my workstation (project auto-downloads 1.26.0; my local `go` is 1.25.6, causing compile mismatch). CI will exercise the full PostgreSQL-backed suite. ## Breaking Changes None. This is an additive change — `cargo` joins the supported `registryType` enum alongside `npm`/`pypi`/`nuget`/`oci`/`mcpb`. Existing publishes continue to work unchanged. ## Types of changes - [x] New feature (non-breaking change which adds functionality) - [x] Documentation update (new Cargo example in `generic-server-json.md`) ## Checklist - [x] I have read the [MCP Documentation](https://modelcontextprotocol.io) - [x] My code follows the repository's style guidelines - [x] New and existing tests pass locally - [x] I have added appropriate error handling - [x] I have added or updated documentation as needed ## Additional context ### Validator design — two-call retrieval on the documented API `internal/validators/registries/cargo.go` mirrors the PyPI validator's README-token approach (substring-match `mcp-name: <serverName>`), with a two-call retrieval pattern to stay on the documented public crates.io API: 1. `GET /api/v1/crates/{name}/{version}/readme` returns 200 OK with a JSON pointer (`{"url": "https://static.crates.io/readmes/.../...html"}`) — crates.io hands us the URL rather than emitting a 302. 2. Follow the pointer to the rendered HTML; substring-match for the token. The two-call pattern stays on the documented public surface. The CDN URL layout is observed-stable, but treating it as the entry point would mean depending on an undocumented path. With two calls, crates.io controls where the README lives — if they move it, the metadata endpoint hands us the new URL. Missing crates and missing versions surface as **403** from the CDN (S3's default for missing keys), not 404. The validator treats any non-200 as "not found" and surfaces the actual status code in the error message. ### Open question — runtime model Cargo's runtime model is genuinely different from npm/PyPI/NuGet. `cargo install` is one-time (binary lands on PATH at `~/.cargo/bin`), not per-invocation like `npx`, `uvx`, or `dnx` (the new one in .NET 10 SDK Preview 6+). The new Cargo example in `generic-server-json.md` annotates this honestly and omits `runtimeHint`. If a different framing is preferred — e.g. recommending **MCPB** (prebuilt binary distribution via GitHub Releases) as the primary path for Rust MCP servers instead of cargo — happy to adjust the documentation accordingly. The schema + validator code in this PR is **additive** and doesn't force a recommendation either way; a Rust author who chooses cargo can use it, and one who prefers MCPB still can. ### Out of scope (deferred) - **`docs/guides/publishing/publish-cargo.md`** — follows on this branch once the runtime-model direction above is settled. - **Publisher CLI `Cargo.toml` autodetect** in `cmd/publisher/commands/init.go` — separate concern, separate PR. - **Positive-path validator test** — gated on `rust-faf-mcp` v0.2.3+ publishing as noted in *How Has This Been Tested?*. --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Radoslav Dimitrov <radoslav@stacklok.com> |
||
|
|
1201cbd82b |
security: fix open redirect and add small hardening (#1227)
## What this does Fixes an open redirect plus a handful of small, mostly-invisible hardening changes around it. ## What's in it - **The fix**: trailing-slash redirects no longer let `//evil.com/` redirect off-host. - **SSRF block** on the DNS/HTTP namespace verification — refuses to dial loopback, RFC1918, link-local, multicast, CGNAT, or IP-literal/single-label \"domains\". - **Slow-client guard**: `ReadTimeout` and `IdleTimeout` on the HTTP server (no `WriteTimeout` — would risk cutting off legitimate multi-package publishes). - **Defence-in-depth headers** on the UI (`/`) and 404 responses. - **5xx responses** stop leaking raw DB error text to clients (logged server-side instead). - **Search filter** stops treating `%` and `_` as wildcards. - **Validators**: PyPI/NuGet identifiers URL-escaped before fetching; MCPB no longer follows redirects. - **Misc**: `Version` field bounded to 255 chars; logs quote user input; `BlockedNamespaces` denylist now catches subdomain claimants. Each change is its own commit so they can be reviewed (or reverted) independently. ## Test plan - [ ] CI green - [ ] Synthetic publish in staging for each package type (npm, pypi, nuget, oci, mcpb) — confirms validator changes don't regress - [ ] Quick browser check of `/` after deploy to confirm UI still loads with the new CSP - [ ] `curl https://<host>//evil.com/` — confirm the open redirect is closed 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
|
b5f38fcc2a |
update schema url point to the actual location (#884)
<!-- Provide a brief summary of your changes --> ## Motivation and Context This PR ensures that the draft URL points to the actual draft schema improvement suggested in https://github.com/modelcontextprotocol/registry/issues/814 ## How Has This Been Tested? <!-- Have you tested this in a real application? Which scenarios were tested? --> ## Breaking Changes <!-- Will users need to update their code or configurations? --> ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply. --> - [ ] I have read the [MCP Documentation](https://modelcontextprotocol.io) - [ ] My code follows the repository's style guidelines - [ ] New and existing tests pass locally - [ ] I have added appropriate error handling - [ ] I have added or updated documentation as needed ## Additional context <!-- Add any other context, implementation notes, or design decisions --> |
Renamed from docs/reference/server-json/server.schema.json (Previous history)