Big docs tidy up in preparation for launch (#364)
## Motivation and Context Docs currently don't have very clear organisation, and don't explain core flows. This fixes #89 (although we still might want to push these to `https://modelcontextprotocol.io/docs/`), based on the plan there. One minor change from that plan is that I merged tutorials and guides, because they ended up basically being duplicates which I thought would be annoying for us to keep in sync. Additionally in the Diátaxis framework, tutorials and guides are separated by whether they are focused on acquisition of skills (e.g. in a learning environment) or application of skills (e.g. in a work environment). I expect the registry to be something that will be used occasionally in a work environment, rather than a fundamental 'learnable' skill so I think it's reasonable not to have tutorials and fold these into guides. ## How Has This Been Tested? - Read through all these updated docs - Unit and integration tests (that previously used examples.md and use the schema) working - Ran `npx markdown-link-check .` to check all the links work ## Breaking Changes Links to old docs will break, but I don't think there are any. All internal links have been checked and updated. ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] 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) - [x] Documentation update
This commit is contained in:
adam jones
GitHub
parent
e9884c1d7b
commit
2e7108d366
37 changed files with 1200 additions and 376 deletions
36
README.md
36
README.md
|
|
@ -1,30 +1,14 @@
|
|||
# MCP Registry
|
||||
|
||||
The MCP registry provides MCP clients with a list of MCP servers, like an app store for MCP servers.
|
||||
|
||||
📖 **[Full documentation](./docs)**
|
||||
|
||||
## Development Status
|
||||
|
||||
> [!WARNING]
|
||||
> The registry is under [active development](#development-status). The registry API spec is unstable and the official MCP registry database may be wiped at any time.
|
||||
|
||||
📖 **[API Documentation](https://staging.registry.modelcontextprotocol.io/docs)** | 📚 **[Technical Docs](./docs)**
|
||||
|
||||
## What is the registry?
|
||||
|
||||
The registry will provide MCP clients with a list of MCP servers, like an app store for MCP servers. (In the future it might do more, like also hosting a list of clients).
|
||||
|
||||
There are two parts to the registry project:
|
||||
1. 🟦 **The MCP registry spec**: An [API specification](./docs/server-registry-api/) that allows anyone to implement a registry.
|
||||
2. 🟥 **The Official MCP registry**: A hosted registry following the MCP registry spec at [`registry.modelcontextprotocol.io`](https://registry.modelcontextprotocol.io). This serves as the **authoritative repository** for publicly-available MCP servers. Server creators publish once, and all consumers (MCP clients, aggregators, marketplaces) reference the same canonical data. This is owned by the MCP open-source community, backed by major trusted contributors to the MCP ecosystem such as Anthropic, GitHub, PulseMCP and Microsoft.
|
||||
|
||||
The registry is built around the [`server.json`](./docs/server-json/) format - a standardized way to describe MCP servers that works across discovery, initialization, and packaging scenarios.
|
||||
|
||||
In time, we expect the ecosystem to look a bit like this:
|
||||
|
||||
|
||||
|
||||
Note that MCP registries are _metaregistries_. They host metadata about packages, but not the package code or binaries. Instead, they reference other package registries (like NPM, PyPi or Docker) for this.
|
||||
|
||||
Additionally, we expect clients pull from _subregistries_. These subregistries add value to the registry ecosystem by providing curation, or extending it with additional metadata. The Official MCP registry expects a lot of API requests from ETL jobs from these subregistries.
|
||||
|
||||
## Development Status
|
||||
|
||||
**2025-09-04 update**: We're targeting a 'preview' go-live on 8th September. This may still be unstable and not provide durability guarantees, but is a step towards being more solidified. A general availability (GA) release will follow later.
|
||||
|
||||
Current key maintainers:
|
||||
|
|
@ -106,7 +90,7 @@ make publisher
|
|||
./cmd/publisher/bin/mcp-publisher --help
|
||||
```
|
||||
|
||||
See [the publisher README](./cmd/publisher/README.md) for more details.
|
||||
See [the publisher guide](./docs/guides/publishing/publish-server.md) for more details.
|
||||
|
||||
#### Other commands
|
||||
|
||||
|
|
@ -130,9 +114,7 @@ For Claude and other AI tools: Always prefer make targets over custom commands w
|
|||
│ └── publisher/ # Server publishing tool
|
||||
├── data/ # Seed data
|
||||
├── deploy/ # Deployment configuration (Pulumi)
|
||||
├── docs/ # Technical documentation
|
||||
│ ├── server-json/ # server.json specification & examples
|
||||
│ └── server-registry-api/ # API specification
|
||||
├── docs/ # Documentation
|
||||
├── internal/ # Private application code
|
||||
│ ├── api/ # HTTP handlers and routing
|
||||
│ ├── auth/ # Authentication (GitHub OAuth, JWT, namespace blocking)
|
||||
|
|
@ -165,4 +147,4 @@ The registry validates namespace ownership when publishing. E.g. to publish...:
|
|||
|
||||
## More documentation
|
||||
|
||||
See the [docs](./docs) folder for more details if your question has not been answered here!
|
||||
See the [documentation](./docs) for more details if your question has not been answered here!
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
CLI tool for publishing MCP servers to the registry.
|
||||
|
||||
> These docs are for contributors. See the [Publisher User Guide](../../docs/publisher/guide.md) for end-user documentation.
|
||||
> These docs are for contributors. See the [Publisher User Guide](../../docs/guides/publishing/publish-server.md) for end-user documentation.
|
||||
|
||||
## Quick Development Setup
|
||||
|
||||
|
|
|
|||
|
|
@ -1,18 +1,16 @@
|
|||
# Official Registry Documentation
|
||||
# MCP Registry Documentation
|
||||
|
||||
This extends [the main README](../README.md).
|
||||
The MCP registry provides MCP clients with a list of MCP servers, like an app store for MCP servers.
|
||||
|
||||
## Project Documentation
|
||||
## I want to...
|
||||
|
||||
- [`faq.md`](./faq.md) - Frequently asked questions about the MCP Registry
|
||||
- [`design_principles.md`](./design_principles.md) - Core constraints and principles guiding the registry design
|
||||
- [`roadmap.md`](./roadmap.md) - High-level roadmap for the MCP Registry development
|
||||
- [`MCP Developers Summit 2025 - Registry Talk Slides.pdf`](./MCP%20Developers%20Summit%202025%20-%20Registry%20Talk%20Slides.pdf) - Slides from a talk given at the MCP Developers Summit on May 23, 2025, with an up-to-date vision of how we are thinking about the official registry.
|
||||
- **📤 Publish my MCP server** → [Publishing Guide](guides/publishing/publish-server.md)
|
||||
- **📥 Consume registry data** → [API Usage Guide](guides/consuming/use-rest-api.md)
|
||||
- **🔌 Understand the registry's purpose** → [Ecosystem vision](explanations/ecosystem-vision.md)
|
||||
- **📋 Look up specific information** → [server.json spec](reference/server-json/generic-server-json.md) | [API spec](reference/api/generic-registry-api.md) | [CLI reference](reference/cli/commands.md)
|
||||
|
||||
## API & Technical Specifications
|
||||
## Documentation Index
|
||||
|
||||
- [`openapi.yaml`](./server-registry-api/openapi.yaml) - OpenAPI specification for the official registry API
|
||||
- [`api_examples.md`](./api_examples.md) - Examples of what data will actually look like coming from the official registry API
|
||||
- [`architecture.md`](./architecture.md) - Technical architecture, deployment strategies, and data flows
|
||||
- [`server.json` README](./server-json/README.md) - description of the `server.json` purpose and schema
|
||||
- [`new_package_registry.md`](./new_package_registry.md) - steps to add a new package registry for local server packages
|
||||
- 🛠️ [How-To Guides: Task-focused instructions](./guides/)
|
||||
- 💡 [Explanations: Understanding-oriented content](./explanations/)
|
||||
- 📖 [Reference: Technical specifications and lookup material](./reference/)
|
||||
|
|
|
|||
10
docs/explanations/README.md
Normal file
10
docs/explanations/README.md
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# Explanations
|
||||
|
||||
Understanding-oriented documentation that clarifies and illuminates the MCP Registry.
|
||||
|
||||
- [Design principles](design-principles.md)
|
||||
- [Ecosystem vision](ecosystem-vision.md)
|
||||
- [Roadmap](roadmap.md)
|
||||
- [Tech architecture](tech-architecture.md)
|
||||
- [Namespacing](namespacing.md)
|
||||
- [Versioning](versioning.md)
|
||||
39
docs/explanations/design-principles.md
Normal file
39
docs/explanations/design-principles.md
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
# MCP Registry Design Principles
|
||||
|
||||
These are the core constraints that guide the design of the MCP Registry. They are not exhaustive, but they are the most important principles that we will use to evaluate design decisions.
|
||||
|
||||
## 1. Single Source of Truth
|
||||
|
||||
The registry serves as the authoritative metadata repository for publicly-available MCP servers, both locally-run and remote, open source and closed source. Server creators publish once, and all consumers (MCP clients, aggregators, etc.) reference the same canonical data.
|
||||
|
||||
## 2. Minimal Operational Burden
|
||||
|
||||
- Design for low maintenance and operational overhead
|
||||
- Delegate complexity to existing services where possible (GitHub for auth, npm/PyPI/NuGet for packages)
|
||||
- Avoid features that require constant human intervention or moderation
|
||||
- Build for reasonable downtime tolerance (24h acceptable) by having consumers cache data for their end-users
|
||||
|
||||
## 3. Vendor Neutrality
|
||||
|
||||
- No preferential treatment for specific servers or organizations
|
||||
- No built-in ranking, curation, or quality judgments
|
||||
- Let consumers (MCP clients, aggregators) make their own curation decisions
|
||||
|
||||
## 4. Meets Industry Security Standards
|
||||
|
||||
- Leverage existing package registries (npm, PyPI, NuGet, Docker Hub, etc.) for source code distribution, obviating the need to reinvent source code security
|
||||
- Use mechanisms like DNS verification, OAuth to provide base layer of authentication and trust
|
||||
- Implement rate limiting, field validation, and blacklisting to prevent abuse
|
||||
|
||||
## 6. Reusable, Extensible Shapes; Not Infrastructure
|
||||
|
||||
- API shapes (OpenAPI, server.json) designed for reuse
|
||||
- Enable private/internal registries using same formats
|
||||
- Don't mandate infrastructure reuse - focus on interface compatibility
|
||||
|
||||
## 7. Progressive Enhancement
|
||||
|
||||
- Start with MVP that provides immediate value
|
||||
- Build foundation that supports future features
|
||||
- Don't over-engineer for hypothetical needs
|
||||
- Each milestone should be independently valuable
|
||||
13
docs/explanations/ecosystem-diagram.excalidraw.svg
Normal file
13
docs/explanations/ecosystem-diagram.excalidraw.svg
Normal file
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 2.7 MiB |
56
docs/explanations/ecosystem-vision.md
Normal file
56
docs/explanations/ecosystem-vision.md
Normal file
|
|
@ -0,0 +1,56 @@
|
|||
# Ecosystem Vision
|
||||
|
||||
How the MCP Registry fits into the broader ecosystem and our vision for the future.
|
||||
|
||||
## The Registry Ecosystem
|
||||
|
||||
The MCP registry provides MCP clients with a list of MCP servers, like an app store for MCP servers. (In the future it might do more, like also hosting a list of clients).
|
||||
|
||||
There are two parts to the registry project:
|
||||
|
||||
1. 🟦 **The MCP registry spec**: An [API specification](../reference/api/) that allows anyone to implement a registry.
|
||||
2. 🟥 **The Official MCP registry**: A hosted registry following the MCP registry spec at [`registry.modelcontextprotocol.io`](https://registry.modelcontextprotocol.io). This serves as the **authoritative repository** for publicly-available MCP servers. Server creators publish once, and all consumers (MCP clients, aggregators, marketplaces) reference the same canonical data. This is owned by the MCP open-source community, backed by major trusted contributors to the MCP ecosystem such as Anthropic, GitHub, PulseMCP and Microsoft.
|
||||
|
||||
The registry is built around the [`server.json`](../reference/server-json/) format - a standardized way to describe MCP servers that works across discovery, initialization, and packaging scenarios.
|
||||
|
||||
In time, we expect the ecosystem to look a bit like this:
|
||||
|
||||
|
||||
|
||||
Note that MCP registries are _metaregistries_. They host metadata about packages, but not the package code or binaries. Instead, they reference other package registries (like NPM, PyPi or Docker) for this.
|
||||
|
||||
Additionally, we expect clients pull from _subregistries_. These subregistries add value to the registry ecosystem by providing curation, or extending it with additional metadata. The Official MCP registry expects a lot of API requests from ETL jobs from these subregistries.
|
||||
|
||||
## Registry vs Package Registry
|
||||
|
||||
Key distinction: MCP Registries are **metaregistries**.
|
||||
|
||||
- **Package registries** (npm, PyPI, Docker Hub) host actual code/binaries
|
||||
- **The MCP Registry** hosts metadata pointing to those packages
|
||||
|
||||
```
|
||||
MCP Registry: "weather-server v1.2.0 is at npm:weather-mcp"
|
||||
NPM Registry: [actual weather-mcp package code]
|
||||
```
|
||||
|
||||
## Official vs Community Registries
|
||||
|
||||
**Official MCP Registry** (`registry.modelcontextprotocol.io`):
|
||||
- Canonical source for publicly-available servers
|
||||
- Community-owned, backed by trusted contributors
|
||||
- Focuses on discoverability and basic metadata
|
||||
|
||||
**Subregistries** (Smithery, PulseMCP, etc.):
|
||||
- Add value through curation, ratings, enhanced metadata
|
||||
- ETL from official registry + additional annotations
|
||||
- Serve specific communities or use cases
|
||||
|
||||
## How Servers Are Represented
|
||||
|
||||
Each server entry contains:
|
||||
- **Identity**: Unique name (`io.github.user/server-name`)
|
||||
- **Packages**: Where to download it (`npm`, `pypi`, `docker`, etc.)
|
||||
- **Runtime**: How to execute it (args, env vars)
|
||||
- **Metadata**: Description, capabilities, version
|
||||
|
||||
This is stored in a standardized `server.json` format that works across discovery, installation, and execution.
|
||||
45
docs/explanations/namespacing.md
Normal file
45
docs/explanations/namespacing.md
Normal file
|
|
@ -0,0 +1,45 @@
|
|||
# Namespacing and Security
|
||||
|
||||
Namespacing prevents name squatting, makes impersonation and typo squatting much harder, and provides attribution through domain-based identity.
|
||||
|
||||
For practical steps on how to authenticate for different namespaces, see the [publishing guide](../guides/publishing/publish-server.md#authenticate).
|
||||
|
||||
## Namespace Format
|
||||
|
||||
All server names follow reverse-DNS format. Examples:
|
||||
- `io.github.alice/weather-server` - GitHub user `alice`
|
||||
- `com.acme/internal-tool` - Company domain `acme.com`
|
||||
- `org.nonprofit.research/data-analyzer` - Subdomain `research.nonprofit.org`
|
||||
|
||||
## Security Model
|
||||
|
||||
### Ownership Verification
|
||||
|
||||
Publishing to a namespace requires proving you control the corresponding identity:
|
||||
|
||||
**GitHub namespaces** (`io.github.*`):
|
||||
- OAuth login to GitHub account/organization
|
||||
- OIDC tokens in GitHub Actions workflows
|
||||
|
||||
**Domain namespaces** (`com.company.*`):
|
||||
- DNS verification: TXT record at `_mcp-registry.company.com`
|
||||
- HTTP verification: File at `https://company.com/.well-known/mcp-registry-auth`
|
||||
|
||||
## Namespace Scoping
|
||||
|
||||
Different authentication methods grant different namespace access:
|
||||
|
||||
**GitHub OAuth/OIDC**:
|
||||
- `io.github.username/*` (for personal accounts)
|
||||
- `io.github.orgname/*` (for organizations)
|
||||
|
||||
**DNS verification**:
|
||||
- `com.domain/*` and `com.domain.*/*` (domain + all subdomains)
|
||||
|
||||
**HTTP verification**:
|
||||
- `com.domain/*` only (exact domain, no subdomains)
|
||||
|
||||
## Limitations
|
||||
|
||||
**Domain ownership changes**: If someone loses/sells a domain, they lose publishing rights. Similarly if someone gains a domain, they gain publishing rights.
|
||||
**Package validation**: Registry validates namespace ownership, but actual packages may still be malicious etc.
|
||||
42467
docs/explanations/registry-goals-presentation.pdf
Normal file
42467
docs/explanations/registry-goals-presentation.pdf
Normal file
File diff suppressed because one or more lines are too long
31
docs/explanations/roadmap.md
Normal file
31
docs/explanations/roadmap.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# MCP Registry Roadmap
|
||||
|
||||
This is a high-level roadmap for the MCP Registry. It is subject to change and not exhaustive, but it outlines the general thinking of the sequencing and scope of our work in this repository.
|
||||
|
||||
This roadmap may occasionally drift out of date. Please review [Issues](https://github.com/modelcontextprotocol/registry/issues) (and corresponding Labels) for the most current work in progress.
|
||||
|
||||
## Current Status
|
||||
|
||||
The initial version of the MCP Registry is actively being developed. The initial focus is on delivering a REST API to which server creators can publish, and aggregator/marketplace consumers can ETL.
|
||||
|
||||
## Phase 1: MVP/Go-Live (Current Focus)
|
||||
|
||||
See the [go-live blocker issues](https://github.com/modelcontextprotocol/registry/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22go-live%20blocker%22).
|
||||
|
||||
## Backlog (Future Work, may be moved to out of scope)
|
||||
|
||||
- [ ] UI implementation
|
||||
- [ ] Store and surface other data besides servers (e.g. [clients](https://modelcontextprotocol.io/clients), resources)
|
||||
- [ ] Download count tracking
|
||||
- [ ] Internationalization (i18n)
|
||||
|
||||
## Out of Scope (Not Planned)
|
||||
|
||||
- **Source code hosting**: The registry will never host actual server code
|
||||
- **Quality rankings**: No built-in server quality assessments or rankings
|
||||
- **Curation**: No editorial decisions about which servers are "better"
|
||||
- **Unified runtime**: Not solving how servers are executed
|
||||
- **Server hosting**: The registry does not provide hosting for servers
|
||||
- **Search engine**: The registry will not provide a commercial grade search engine for servers
|
||||
- **Server tags or categories**: Not supported, to reduce moderation burden
|
||||
- **Server rankings**: The registry will not rank servers by subjective measures of quality
|
||||
202
docs/explanations/tech-architecture.md
Normal file
202
docs/explanations/tech-architecture.md
Normal file
|
|
@ -0,0 +1,202 @@
|
|||
# MCP Registry Technical Architecture
|
||||
|
||||
This document describes the technical architecture of the MCP Registry, including system components, deployment strategies, and data flows.
|
||||
|
||||
## System Overview
|
||||
|
||||
The MCP Registry is designed as a lightweight metadata service that bridges MCP server creators with consumers (MCP clients and aggregators).
|
||||
|
||||
## Core Components
|
||||
|
||||
### REST API (Go)
|
||||
|
||||
The main application server implemented in Go, providing:
|
||||
- Public read endpoints for server discovery
|
||||
- Authenticated write endpoints for server publication
|
||||
- GitHub OAuth integration (extensible to other providers)
|
||||
- DNS verification system (optional for custom namespaces)
|
||||
|
||||
### Database (PostgreSQL)
|
||||
|
||||
Primary data store for:
|
||||
- Versioned server metadata (server.json contents)
|
||||
- User authentication state
|
||||
- DNS verification records
|
||||
|
||||
### CDN Layer
|
||||
|
||||
Critical for scalability:
|
||||
- Caches all public read endpoints
|
||||
- Reduces load on origin servers
|
||||
- Enables global distribution
|
||||
- Designed for daily consumer polling patterns
|
||||
|
||||
### CLI Tool
|
||||
|
||||
Developer interface for:
|
||||
- Server publication workflow
|
||||
- GitHub OAuth flow
|
||||
- DNS verification
|
||||
|
||||
## Deployment Architecture
|
||||
|
||||
### Kubernetes Deployment (Helm)
|
||||
|
||||
The registry is designed to run on Kubernetes using Helm charts:
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "Kubernetes Cluster"
|
||||
subgraph "Namespace: mcp-registry"
|
||||
subgraph "Registry Service"
|
||||
LB[Load Balancer<br/>:80]
|
||||
RS[Registry Service<br/>:8080]
|
||||
RP1[Registry Pod 1]
|
||||
RP2[Registry Pod 2]
|
||||
RP3[Registry Pod N]
|
||||
end
|
||||
|
||||
subgraph "Database Service"
|
||||
DBS[DB Service<br/>:27017]
|
||||
SS[StatefulSet]
|
||||
PV[Persistent Volume]
|
||||
end
|
||||
|
||||
subgraph "Secrets"
|
||||
GHS[GitHub OAuth Secret]
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
LB --> RS
|
||||
RS --> RP1
|
||||
RS --> RP2
|
||||
RS --> RP3
|
||||
RP1 --> DBS
|
||||
RP2 --> DBS
|
||||
RP3 --> DBS
|
||||
DBS --> SS
|
||||
SS --> PV
|
||||
RP1 -.-> GHS
|
||||
RP2 -.-> GHS
|
||||
RP3 -.-> GHS
|
||||
```
|
||||
|
||||
## Data Flow Patterns
|
||||
|
||||
### 1. Server Publication Flow
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Dev as Developer
|
||||
participant CLI as CLI Tool
|
||||
participant API as Registry API
|
||||
participant DB as Database
|
||||
participant GH as GitHub
|
||||
participant DNS as DNS Provider
|
||||
|
||||
Dev->>CLI: mcp publish server.json
|
||||
CLI->>CLI: Validate server.json
|
||||
CLI->>GH: OAuth flow
|
||||
GH-->>CLI: Access token
|
||||
CLI->>API: POST /servers
|
||||
API->>GH: Verify token
|
||||
API->>DNS: Verify domain (if applicable)
|
||||
API->>DB: Store metadata
|
||||
API-->>CLI: Success
|
||||
CLI-->>Dev: Published!
|
||||
```
|
||||
|
||||
### 2. Consumer Discovery Flow
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Client as MCP Client Host App
|
||||
participant INT as Intermediary<br/>(Marketplace/Aggregator)
|
||||
participant CDN as CDN Cache
|
||||
participant API as Registry API
|
||||
participant DB as Database
|
||||
|
||||
Note over INT,CDN: Daily ETL Process
|
||||
INT->>CDN: GET /servers
|
||||
alt Cache Hit
|
||||
CDN-->>INT: Cached response
|
||||
else Cache Miss
|
||||
CDN->>API: GET /servers
|
||||
API->>DB: Query servers
|
||||
DB-->>API: Server list
|
||||
API-->>CDN: Response + cache headers
|
||||
CDN-->>INT: Response
|
||||
end
|
||||
INT->>INT: Process & enhance data
|
||||
INT->>INT: Store in local cache
|
||||
|
||||
Note over Client,INT: Real-time Client Access
|
||||
Client->>INT: Request server list
|
||||
INT-->>Client: Curated/enhanced data
|
||||
```
|
||||
|
||||
### 3. DNS Verification Flow
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant User as User
|
||||
participant CLI as CLI Tool
|
||||
participant API as Registry API
|
||||
participant DNS as DNS Provider
|
||||
participant DB as Database
|
||||
|
||||
User->>CLI: mcp verify-domain example.com
|
||||
CLI->>API: POST /verify-domain
|
||||
API->>API: Generate verification token
|
||||
API->>DB: Store pending verification
|
||||
API-->>CLI: TXT record: mcp-verify=abc123
|
||||
CLI-->>User: Add TXT record to DNS
|
||||
User->>DNS: Configure TXT record
|
||||
User->>CLI: Confirm added
|
||||
CLI->>API: POST /verify-domain/check
|
||||
API->>DNS: Query TXT records
|
||||
DNS-->>API: TXT records
|
||||
API->>API: Validate token
|
||||
API->>DB: Store verification
|
||||
API-->>CLI: Domain verified
|
||||
CLI-->>User: Success!
|
||||
```
|
||||
|
||||
### 4. Admin OIDC Authentication Flow
|
||||
|
||||
For registry administration, users with @modelcontextprotocol.io Google Cloud Identity accounts can authenticate using OIDC:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Admin as Admin User
|
||||
participant CLI as Admin CLI
|
||||
participant GCP as Google Cloud Identity
|
||||
participant API as Registry API
|
||||
|
||||
Admin->>CLI: Request admin token
|
||||
CLI->>GCP: gcloud auth print-identity-token --audiences=mcp-registry
|
||||
GCP-->>CLI: ID Token (with hd: "modelcontextprotocol.io")
|
||||
CLI->>API: POST /v0/auth/oidc {"oidc_token": "eyJ..."}
|
||||
API->>GCP: Verify token signature (JWKS)
|
||||
API->>API: Validate claims (issuer, audience, hd)
|
||||
API->>API: Grant admin permissions (edit: *, publish: *)
|
||||
API-->>CLI: Registry JWT Token
|
||||
CLI->>API: POST /admin/* (with Registry JWT)
|
||||
API->>API: Validate JWT + permissions
|
||||
API-->>CLI: Admin operation success
|
||||
```
|
||||
|
||||
**Usage:**
|
||||
```bash
|
||||
# Get Google Cloud Identity token
|
||||
ID_TOKEN=$(gcloud auth print-identity-token)
|
||||
|
||||
# Exchange for Registry JWT token
|
||||
REGISTRY_TOKEN=$(curl -X POST /v0/auth/oidc \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"oidc_token": "'$ID_TOKEN'"}' | jq -r .registry_token)
|
||||
|
||||
# Use for admin operations
|
||||
curl -H "Authorization: Bearer $REGISTRY_TOKEN" /v0/...
|
||||
```
|
||||
233
docs/explanations/versioning.md
Normal file
233
docs/explanations/versioning.md
Normal file
|
|
@ -0,0 +1,233 @@
|
|||
# Server Versioning Guide
|
||||
|
||||
This document describes the versioning approach for MCP servers published to the registry.
|
||||
|
||||
## Overview
|
||||
|
||||
The MCP Registry supports flexible versioning while encouraging semantic versioning best practices. The registry attempts to parse versions as semantic versions for ordering and comparison, but falls back gracefully for non-semantic versions.
|
||||
|
||||
## Version Requirements
|
||||
|
||||
1. **Version String**: `version` MUST be a string up to 255 characters
|
||||
2. **Uniqueness**: Each version for a given server name must be unique
|
||||
3. **Immutability**: Once published, version metadata cannot be changed
|
||||
|
||||
## Best Practices
|
||||
|
||||
### 1. Use Semantic Versioning
|
||||
Server authors SHOULD use [semantic versions](https://semver.org/) following the `MAJOR.MINOR.PATCH` format:
|
||||
|
||||
```json
|
||||
{
|
||||
"version_detail": {
|
||||
"version": "1.2.3"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Align with Package Versions
|
||||
Server authors SHOULD use versions aligned with their underlying packages to reduce confusion:
|
||||
|
||||
```json
|
||||
{
|
||||
"version_detail": {
|
||||
"version": "1.2.3"
|
||||
},
|
||||
"packages": [{
|
||||
"registry_name": "npm",
|
||||
"name": "@myorg/my-server",
|
||||
"version": "1.2.3"
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Multiple Registry Versions
|
||||
If server authors expect to have multiple registry versions for the same package version, they SHOULD follow the semantic version spec using the prerelease label:
|
||||
|
||||
```json
|
||||
{
|
||||
"version_detail": {
|
||||
"version": "1.2.3-1"
|
||||
},
|
||||
"packages": [{
|
||||
"registry_name": "npm",
|
||||
"name": "@myorg/my-server",
|
||||
"version": "1.2.3"
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
**Note**: According to semantic versioning, `1.2.3-1` is considered lower than `1.2.3`, so if you expect to need a `1.2.3-1`, you should publish that before `1.2.3`.
|
||||
|
||||
## Version Ordering and "Latest" Determination
|
||||
|
||||
### For Semantic Versions
|
||||
The registry attempts to parse versions as semantic versions. If successful, it uses semantic version comparison rules to determine:
|
||||
- Version ordering in lists
|
||||
- Which version is marked as `is_latest`
|
||||
|
||||
### For Non-Semantic Versions
|
||||
If version parsing as semantic version fails:
|
||||
- The registry will always mark the version as latest (overriding any previous version)
|
||||
- Clients should fall back to using publish timestamp for ordering
|
||||
|
||||
**Important Note**: This behavior means that for servers with mixed semantic and non-semantic versions, the `is_latest` flag may not align with the total ordering. A non-semantic version published after semantic versions will be marked as latest, even if semantic versions are considered "higher" in the ordering.
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### Registry Behavior
|
||||
1. **Validation**: Versions are validated for uniqueness within a server name
|
||||
2. **Parsing**: The registry attempts to parse each version as semantic version
|
||||
3. **Comparison**: Uses semantic version rules when possible, falls back to timestamp
|
||||
4. **Latest Flag**: The `is_latest` field is set based on the comparison results
|
||||
|
||||
### Client Recommendations
|
||||
Registry clients SHOULD:
|
||||
1. Attempt to interpret versions as semantic versions when possible
|
||||
2. Use the following ordering rules:
|
||||
- If one version is marked as is_latest: it is later
|
||||
- If both versions are valid semver: use semver comparison
|
||||
- If neither are valid semver: use publish timestamp
|
||||
- If one is semver and one is not: semver version is considered higher
|
||||
|
||||
## Examples
|
||||
|
||||
### Valid Semantic Versions
|
||||
```javascript
|
||||
"1.0.0" // Basic semantic version
|
||||
"2.1.3-alpha" // Prerelease version
|
||||
"1.0.0-beta.1" // Prerelease with numeric suffix
|
||||
"3.0.0-rc.2" // Release candidate
|
||||
```
|
||||
|
||||
### Non-Semantic Versions (Allowed)
|
||||
```javascript
|
||||
"v1.0" // Version with prefix
|
||||
"2021.03.15" // Date-based versioning
|
||||
"snapshot" // Development snapshots
|
||||
"latest" // Custom versioning scheme
|
||||
```
|
||||
|
||||
### Alignment Examples
|
||||
```json
|
||||
{
|
||||
"version_detail": {
|
||||
"version": "1.2.3-1"
|
||||
},
|
||||
"packages": [{
|
||||
"registry_name": "npm",
|
||||
"name": "@myorg/k8s-server",
|
||||
"version": "1.2.3"
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
## Migration Path
|
||||
|
||||
Existing servers with non-semantic versions will continue to work without changes. However, to benefit from proper version ordering, server maintainers are encouraged to:
|
||||
|
||||
1. Adopt semantic versioning for new releases
|
||||
2. Consider the ordering implications when transitioning from non-semantic to semantic versions
|
||||
3. Use prerelease labels for registry-specific versioning needs
|
||||
|
||||
## Common Scenarios
|
||||
|
||||
### Standard Releases
|
||||
**Package and server versions aligned**:
|
||||
```json
|
||||
{
|
||||
"version_detail": {
|
||||
"version": "1.2.3"
|
||||
},
|
||||
"packages": [
|
||||
{
|
||||
"registry_type": "npm",
|
||||
"identifier": "@myorg/server",
|
||||
"version": "1.2.3"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Registry-Only Updates
|
||||
**Server metadata changes without package updates**:
|
||||
```json
|
||||
{
|
||||
"version_detail": {
|
||||
"version": "1.2.3-1"
|
||||
},
|
||||
"packages": [
|
||||
{
|
||||
"registry_type": "npm",
|
||||
"identifier": "@myorg/server",
|
||||
"version": "1.2.3"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Note: `1.2.3-1` is considered lower than `1.2.3` in semver ordering. Publish prerelease versions first.
|
||||
|
||||
### Remote Server Versioning
|
||||
**Remote servers without package dependencies**:
|
||||
```json
|
||||
{
|
||||
"version_detail": {
|
||||
"version": "2.1.0"
|
||||
},
|
||||
"remotes": [
|
||||
{
|
||||
"transport_type": "sse",
|
||||
"url": "https://api.myservice.com/mcp/v2.1"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Version strategy options:
|
||||
- **API versioning**: Match your service API version
|
||||
- **Semantic versioning**: Standard semver for feature changes
|
||||
- **Date-based**: `2024.03.15` for regular releases
|
||||
|
||||
### Multi-Package Versioning
|
||||
**Different package versions**:
|
||||
```json
|
||||
{
|
||||
"version_detail": {
|
||||
"version": "1.3.0"
|
||||
},
|
||||
"packages": [
|
||||
{
|
||||
"registry_type": "npm",
|
||||
"identifier": "@myorg/server",
|
||||
"version": "1.3.0"
|
||||
},
|
||||
{
|
||||
"registry_type": "oci",
|
||||
"identifier": "myorg/server",
|
||||
"version": "1.2.5"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Use server version to indicate the overall release.
|
||||
|
||||
## Decision Guide
|
||||
|
||||
**Which version strategy should I use?**
|
||||
|
||||
```
|
||||
Do you have underlying packages?
|
||||
├─ Yes: Align with package version
|
||||
│ ├─ Same package version → Use package version
|
||||
│ └─ Different package versions → Use highest + indicate relationship
|
||||
└─ No (remote server): Choose versioning scheme
|
||||
├─ API versioning → Match service API version
|
||||
├─ Feature-based → Use semantic versioning
|
||||
└─ Regular releases → Consider date-based versioning
|
||||
```
|
||||
|
||||
## Future Considerations
|
||||
|
||||
This versioning approach is designed to be compatible with potential future changes to the MCP specification's `Implementation.version` field. Any SHOULD requirements introduced here may be proposed as updates to the specification through the SEP (Specification Enhancement Proposal) process.
|
||||
21
docs/guides/README.md
Normal file
21
docs/guides/README.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
# How-To Guides
|
||||
|
||||
Problem-oriented guides for specific tasks with the MCP Registry.
|
||||
|
||||
## Publishing Servers
|
||||
|
||||
- [Publish a server](publishing/publish-server.md)
|
||||
- [GitHub Actions](publishing/github-actions.md)
|
||||
|
||||
## Consuming Registry Data
|
||||
|
||||
- [Use the REST API](consuming/use-rest-api.md)
|
||||
|
||||
## Contributing
|
||||
|
||||
- [Add package registry](contributing/add-package-registry.md)
|
||||
|
||||
## Administration
|
||||
|
||||
- [Admin operations](administration/admin-operations.md)
|
||||
- [Moderation guidelines](administration/moderation-guidelines.md)
|
||||
46
docs/guides/administration/admin-operations.md
Normal file
46
docs/guides/administration/admin-operations.md
Normal file
|
|
@ -0,0 +1,46 @@
|
|||
# Admin Operations
|
||||
|
||||
This is a brief guide for admins and moderators managing content on the registry. All actions should be taken in line with the [moderation guidelines](moderation-guidelines.md).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Admin account with @modelcontextprotocol.io email
|
||||
- If you are a maintainer and would like an account, ask in the Discord
|
||||
- `gcloud` CLI installed and configured
|
||||
- `curl` and `jq` installed
|
||||
|
||||
## Authentication
|
||||
|
||||
```bash
|
||||
# Run this, then run the export command it outputs
|
||||
./tools/admin/auth.sh
|
||||
```
|
||||
|
||||
## Edit a Server
|
||||
|
||||
Step 1: Download Server
|
||||
|
||||
```bash
|
||||
export SERVER_ID="<server-uuid>"
|
||||
curl -s "https://registry.modelcontextprotocol.io/v0/servers/${SERVER_ID}" > server.json
|
||||
```
|
||||
|
||||
Step 2: Open `server.json` and make changes. You cannot change the server name.
|
||||
|
||||
Step 3: Push Changes
|
||||
|
||||
```bash
|
||||
curl -X PUT "https://registry.modelcontextprotocol.io/v0/servers/${SERVER_ID}" \
|
||||
-H "Authorization: Bearer ${REGISTRY_TOKEN}" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d "{\"server\": $(cat server.json)}"
|
||||
```
|
||||
|
||||
## Takedown a Server
|
||||
|
||||
```bash
|
||||
export SERVER_ID="<server-uuid>"
|
||||
./tools/admin/takedown.sh
|
||||
```
|
||||
|
||||
This soft deletes the server. If you need to delete the content of a server (usually only where legally necessary), use the edit workflow above to scrub it all.
|
||||
60
docs/guides/administration/moderation-guidelines.md
Normal file
60
docs/guides/administration/moderation-guidelines.md
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
# Moderation Guidelines
|
||||
|
||||
Guidelines for server publishers on the Official MCP Registry.
|
||||
|
||||
## TL;DR
|
||||
|
||||
We're quite permissive! We only remove illegal content, malware, spam and completely broken servers.
|
||||
|
||||
We don't make guarantees about our moderation, and subregistries should take our data "as is", assuming minimal to no moderation.
|
||||
|
||||
## Scope
|
||||
|
||||
These guidelines apply to the **Official MCP Registry** at `registry.modelcontextprotocol.io`.
|
||||
|
||||
Subregistries may have their own moderation policies. If you have questions about content on a specific subregistry, please contact them directly.
|
||||
|
||||
## Disclaimer
|
||||
|
||||
We have limited active moderation capabilities, and this is a community supported projects. We largely rely on upstream package registries (like NPM, PyPi, and Docker) or downstream subregistries (like the GitHub MCP Registry) to do more in-depth moderation.
|
||||
|
||||
This means there may be content in the registry that should be removed under these guidelines, which we haven't yet removed. You should treat registry data accordingly.
|
||||
|
||||
## What We Remove
|
||||
|
||||
We'll remove servers that contain:
|
||||
|
||||
- Illegal content, which includes obscene content, copyright violations, and hacking tools
|
||||
- Malware, regardless of intentions
|
||||
- Spam, especially mass-created servers that disrupt the registry. Examples:
|
||||
- The same server being submitted multiple times under different names.
|
||||
- The server doesn't do anything but provide a fixed response with some marketing copy.
|
||||
- The server description is stuffed with marketing copy, and its implementation is unrelated to its name or description.
|
||||
- Non-functioning servers
|
||||
|
||||
## What We Don't Remove
|
||||
|
||||
Generally, we believe in keeping the registry open and pushing moderation to subregistries. We therefore **won't** remove servers that are:
|
||||
|
||||
- Low quality or buggy servers
|
||||
- Servers with security vulnerabilities
|
||||
- Do the same thing as other servers
|
||||
- Provide or contain adult content
|
||||
|
||||
## How Removal Works
|
||||
|
||||
When we remove a server:
|
||||
|
||||
- It's set to "deleted" status but remains accessible via the API
|
||||
- This allows subregistries to remove it from their indexes
|
||||
- In extreme cases, we may overwrite or erase details of a server, e.g. where the metadata itself is unlawful
|
||||
|
||||
## Appeals
|
||||
|
||||
Think we made a mistake? Open an issue on our [GitHub repository](https://github.com/modelcontextprotocol/registry) with:
|
||||
- The ID and name of your server
|
||||
- Why you believe it doesn't meet the criteria for removal above
|
||||
|
||||
## Changes to this policy
|
||||
|
||||
We're still learning how to best run the MCP registry! As such, we might end up changing this policy in the future.
|
||||
77
docs/guides/consuming/use-rest-api.md
Normal file
77
docs/guides/consuming/use-rest-api.md
Normal file
|
|
@ -0,0 +1,77 @@
|
|||
# Consuming Registry Data via REST API
|
||||
|
||||
Integration patterns and best practices for building applications that consume MCP registry data.
|
||||
|
||||
## Key details
|
||||
|
||||
**Base URL**: `https://registry.modelcontextprotocol.io`
|
||||
|
||||
**Authentication**: Not required for read-only access
|
||||
|
||||
- **`GET /v0/servers`** - List all servers with pagination
|
||||
- **`GET /v0/servers/{id}`** - Get full server details including packages and configuration
|
||||
|
||||
See the [interactive API documentation](https://registry.modelcontextprotocol.io/docs) for complete request/response schemas.
|
||||
|
||||
**Disclaimer**: The official registry provides no uptime or data durability guarantees. You should design your applications to handle service downtime via caching.
|
||||
|
||||
## Building a subregistry
|
||||
**Create enhanced registries** - ETL official registry data and add your own metadata like ratings, security scans, or compatibility info.
|
||||
|
||||
For now we recommend scraping the `GET /v0/servers` endpoint on some regular basis. In the future we might provide a filter for updated_at ([#291](https://github.com/modelcontextprotocol/registry/issues/291)) to get only recently changed servers.
|
||||
|
||||
Servers are generally immutable, except for the `status` field which can be updated to `deleted` (among other states). For these packages, we recommend you also update the status field to `deleted` or remove the package from your registry quickly. This is because this status generally indicates it has violated our permissive [moderation guidelines](../administration/moderation-guidelines.md), suggesting it is illegal, malware or spam.
|
||||
|
||||
### Filtering & Enhancement
|
||||
|
||||
The official registry has a [permissive moderation policy](../administration/moderation-guidelines.md), so you may want to implement your own filtering on top of registry data.
|
||||
|
||||
You can also add custom metadata to servers using the `_meta` field. For example, user ratings, download counts, or security scan results. If you do this, we recommend you put this under a key that is namespaced to your organization, for example:
|
||||
|
||||
```json
|
||||
{
|
||||
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-07-09/server.schema.json",
|
||||
"name": "io.github.yourname/weather-server",
|
||||
"description": "MCP server for weather data access",
|
||||
"status": "active",
|
||||
"version_detail": {
|
||||
"version": "1.0.0"
|
||||
},
|
||||
"packages": [
|
||||
{
|
||||
"registry_type": "npm",
|
||||
"identifier": "weather-mcp-server",
|
||||
"version": "1.0.0"
|
||||
}
|
||||
],
|
||||
"_meta": {
|
||||
"com.example.subregistry/custom": {
|
||||
"user_rating": 4.5,
|
||||
"download_count": 12345,
|
||||
"security_scan": {
|
||||
"last_scanned": "2024-06-01T12:00:00Z",
|
||||
"vulnerabilities_found": 0
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Providing an API
|
||||
|
||||
We recommend that your subregistry provides an API meeting the registry API specification, so it's easy for clients to switch between registries. See the [registry API documentation](../../reference/api/) for details.
|
||||
|
||||
## MCP Client Integration
|
||||
**Convert registry data to client configuration** - Fetch servers and transform package information into your MCP client's config format.
|
||||
|
||||
We highly recommend using a subregistry rather than fetching data from the official registry directly. You might want to make this configurable so that users of your client can choose their preferred registry, for example we expect that some enterprise users may have their own registry.
|
||||
|
||||
Your client should gracefully handle registries that meet the minimum spec, i.e. avoid hard dependencies on `_meta` fields.
|
||||
|
||||
### Filtering
|
||||
|
||||
You likely should filter out servers that are not `active` in the `status` field.
|
||||
|
||||
### Running servers
|
||||
|
||||
You can use the `packages` or `remotes` field to determine how to run a server. More details of these fields are in the [server.json documentation](../../reference/server-json/generic-server-json.md).
|
||||
56
docs/guides/contributing/add-package-registry.md
Normal file
56
docs/guides/contributing/add-package-registry.md
Normal file
|
|
@ -0,0 +1,56 @@
|
|||
# Adding a new package registry
|
||||
|
||||
The MCP Registry project is a **metaregistry**, meaning that it hosts metadata for MCP servers but does not host the code for the servers directly.
|
||||
|
||||
For local MCP servers, the MCP Registry has pointers in the `packages` node of the [`server.json`](../../reference/server-json/generic-server-json.md) schema that refer to packages in supported package managers.
|
||||
|
||||
The list of supported package managers for hosting MCP servers is defined by the `properties.packages[N].properties.registry_type` string enum in the [`server.json` schema](../../reference/server-json/server.schema.json). For example, this could be "npm" (for npmjs.com packages) or "pypi" (for PyPI packages).
|
||||
|
||||
For remote MCP servers, the package registry is not relevant. The MCP client consumes the server via a URL instead of by downloading and running a package. In other words, this document only applies to local MCP servers.
|
||||
|
||||
For the sake of illustration, this document will use npm (the Node.js package manager) as an example at each step.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
The package registry must meet the following requirements:
|
||||
|
||||
1. The package registry supports packaging and executing CLI apps. Local MCP servers use the [stdio transport](https://modelcontextprotocol.io/docs/concepts/transports#standard-input%2Foutput-stdio).
|
||||
- npm CLI tools typically express their CLI commands in the [`bin` property of the package.json](https://docs.npmjs.com/cli/v11/configuring-npm/package-json#bin)
|
||||
1. The package registry (or associated client tooling) has a widely accepted **single-shot** CLI command.
|
||||
- npm's `npx` tool executes CLI commands using a [documented execution heuristic](https://docs.npmjs.com/cli/v11/commands/npx#description)
|
||||
- For example, the MCP client can map the `server.json` metadata to an `npx` CLI execution, with args and environment variables populated via user input.
|
||||
1. The package registry supports anonymous package downloads. This allows the MCP client software to use the metadata found in the MCP registry to discover, download, and execute package-based local MCP servers with minimal user intervention.
|
||||
- `npx` by default connects to the public npmjs.com registry, allowing simple consumption of public npm packages.
|
||||
1. The package registry should support a validation mechanism to verify ownership of the server name. This prevents misattribution and ensures that only the actual package owner can reference their packages in server registrations. For example:
|
||||
- npm requires an `mcpName` field in `package.json` that matches the server name being registered
|
||||
- PyPI requires a `mcp-name:` line in the package README/description
|
||||
- Each registry type must implement a validation mechanism accessible via public API
|
||||
|
||||
## Steps
|
||||
|
||||
These steps may evolve as additional validations or details are discovered and mandated.
|
||||
|
||||
1. [Create a feature request issue](https://github.com/modelcontextprotocol/registry/issues/new?template=feature_request.md) on the MCP Registry repository to begin the discussion about adding the package registry.
|
||||
- Example for NuGet: https://github.com/modelcontextprotocol/registry/issues/126
|
||||
1. Open a PR with the following changes:
|
||||
- Update the [`server.json` schema](../../reference/server-json/server.schema.json)
|
||||
- Add your package registry name to the `registry_type` example array.
|
||||
- Add your package registry base url to the `registry_base_url` example array.
|
||||
- Add the single-shot CLI command name to the `runtime_hint` example value array.
|
||||
- Update the [`openapi.yaml`](../../reference/api/openapi.yaml)
|
||||
- Add your package registry name to the `registry_type` enum value array.
|
||||
- Add your package registry base url to the `registry_base_url` enum value array.
|
||||
- Add the single-shot CLI command name to the `runtime_hint` example value array.
|
||||
- Add a sample, minimal `server.json` to the [`server.json` examples](../../reference/server-json/generic-server-json.md).
|
||||
- Implement a registry validator:
|
||||
- Create a new validator file: `internal/validators/registries/yourregistry.go`, following the pattern of existing validators. Examples:
|
||||
- **npm**: Checks for an `mcpName` field in `package.json` that matches the server name
|
||||
- **PyPI**: Searches for `mcp-name: server-name` format in the package README content
|
||||
- **NuGet**: Looks for `mcp-name: server-name` format in the package README file
|
||||
- **Docker/OCI**: Validates a Docker image label `io.modelcontextprotocol.server.name` in the image manifest
|
||||
- Add corresponding unit tests: `internal/validators/registries/yourregistry_test.go`
|
||||
- Register your validator in `internal/validators/validators.go`
|
||||
- Update the publishing documentation:
|
||||
- Add a new publishing guide: `docs/guides/publishing/publish-[yourregistry].md`, following the pattern of existing publishing guides (e.g., `publish-npm.md`, `publish-pypi.md`)
|
||||
- Include instructions on how to prepare packages for your registry, including any specific validation requirements
|
||||
- Update `docs/guides/publishing/README.md` to reference your new publishing guide
|
||||
331
docs/guides/publishing/github-actions.md
Normal file
331
docs/guides/publishing/github-actions.md
Normal file
|
|
@ -0,0 +1,331 @@
|
|||
# Automate Publishing with GitHub Actions
|
||||
|
||||
Set up automated MCP server publishing using GitHub Actions.
|
||||
|
||||
## What You'll Learn
|
||||
|
||||
By the end of this tutorial, you'll have:
|
||||
- A GitHub Actions workflow that automatically publishes your server
|
||||
- Understanding of GitHub OIDC authentication
|
||||
- Knowledge of best practices for automated publishing
|
||||
- Working examples for Node.js, Python, and Docker projects
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Already published your server manually (complete [Publishing Tutorial](publish-server.md) first)
|
||||
- GitHub repository with your MCP server code
|
||||
- Basic understanding of CI/CD concepts
|
||||
- 20-30 minutes
|
||||
|
||||
## GitHub Actions Setup
|
||||
|
||||
### Step 1: Create Workflow File
|
||||
|
||||
Create `.github/workflows/publish-mcp.yml` in your repository:
|
||||
|
||||
```yaml
|
||||
name: Publish to MCP Registry
|
||||
|
||||
on:
|
||||
push:
|
||||
tags: ['v*'] # Triggers on version tags like v1.0.0
|
||||
|
||||
jobs:
|
||||
publish:
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
id-token: write # Required for OIDC authentication
|
||||
contents: read
|
||||
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Setup Node.js # Adjust for your language
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '20'
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Run tests
|
||||
run: npm test
|
||||
|
||||
- name: Build package
|
||||
run: npm run build
|
||||
|
||||
- name: Publish to npm
|
||||
run: npm publish
|
||||
env:
|
||||
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
|
||||
|
||||
- name: Install MCP Publisher
|
||||
run: |
|
||||
# Build publisher from source (requires Go)
|
||||
git clone https://github.com/modelcontextprotocol/registry publisher-repo
|
||||
cd publisher-repo
|
||||
make publisher
|
||||
cp cmd/publisher/bin/mcp-publisher ../mcp-publisher
|
||||
cd ..
|
||||
chmod +x mcp-publisher
|
||||
|
||||
- name: Login to MCP Registry
|
||||
run: ./mcp-publisher login github-oidc
|
||||
|
||||
- name: Publish to MCP Registry
|
||||
run: ./mcp-publisher publish
|
||||
```
|
||||
|
||||
### Step 2: Configure Secrets
|
||||
|
||||
For npm publishing, add your NPM token to repository secrets:
|
||||
|
||||
1. Go to repository Settings → Secrets and variables → Actions
|
||||
2. Add `NPM_TOKEN` with your npm access token
|
||||
|
||||
**Note:** GitHub OIDC authentication requires no additional secrets for MCP Registry publishing.
|
||||
|
||||
### Step 3: Tag and Release
|
||||
|
||||
Create a version tag to trigger the workflow:
|
||||
|
||||
```bash
|
||||
git tag v1.0.0
|
||||
git push origin v1.0.0
|
||||
```
|
||||
|
||||
The workflow will:
|
||||
1. Run tests
|
||||
2. Build your package
|
||||
3. Publish to npm
|
||||
4. Automatically authenticate with the MCP Registry
|
||||
5. Publish updated server.json
|
||||
|
||||
## Authentication Methods by CI Platform
|
||||
|
||||
### GitHub Actions - OIDC (Recommended)
|
||||
|
||||
```yaml
|
||||
- name: Login to MCP Registry
|
||||
run: mcp-publisher login github-oidc
|
||||
```
|
||||
|
||||
**Advantages:**
|
||||
- No secrets to manage
|
||||
- Automatically scoped to your repository
|
||||
- Most secure option
|
||||
|
||||
### GitHub Actions - Personal Access Token
|
||||
|
||||
```yaml
|
||||
- name: Login to MCP Registry
|
||||
run: mcp-publisher login github --token ${{ secrets.GITHUB_TOKEN }}
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.MCP_GITHUB_TOKEN }}
|
||||
```
|
||||
|
||||
Add `MCP_GITHUB_TOKEN` secret with a GitHub PAT that has repo access.
|
||||
|
||||
### DNS Authentication (Any CI)
|
||||
|
||||
For custom domain namespaces (`com.yourcompany/*`):
|
||||
|
||||
```yaml
|
||||
- name: Login to MCP Registry
|
||||
run: |
|
||||
echo "${{ secrets.MCP_PRIVATE_KEY }}" > key.pem
|
||||
mcp-publisher login dns --domain yourcompany.com --private-key-file key.pem
|
||||
```
|
||||
|
||||
Add your Ed25519 private key as `MCP_PRIVATE_KEY` secret.
|
||||
|
||||
## Language-Specific Examples
|
||||
|
||||
### Python Project
|
||||
|
||||
```yaml
|
||||
name: Publish Python MCP Server
|
||||
|
||||
on:
|
||||
push:
|
||||
tags: ['v*']
|
||||
|
||||
jobs:
|
||||
publish:
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
id-token: write
|
||||
contents: read
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Setup Python
|
||||
uses: actions/setup-python@v4
|
||||
with:
|
||||
python-version: '3.11'
|
||||
|
||||
- name: Install Poetry
|
||||
run: pipx install poetry
|
||||
|
||||
- name: Build package
|
||||
run: poetry build
|
||||
|
||||
- name: Publish to PyPI
|
||||
run: poetry publish
|
||||
env:
|
||||
POETRY_PYPI_TOKEN_PYPI: ${{ secrets.PYPI_TOKEN }}
|
||||
|
||||
- name: Install MCP Publisher
|
||||
run: |
|
||||
git clone https://github.com/modelcontextprotocol/registry publisher-repo
|
||||
cd publisher-repo && make publisher && cd ..
|
||||
cp publisher-repo/cmd/publisher/bin/mcp-publisher mcp-publisher
|
||||
|
||||
- name: Publish to MCP Registry
|
||||
run: |
|
||||
./mcp-publisher login github-oidc
|
||||
./mcp-publisher publish
|
||||
```
|
||||
|
||||
### Docker Project
|
||||
|
||||
```yaml
|
||||
name: Publish Docker MCP Server
|
||||
|
||||
on:
|
||||
push:
|
||||
tags: ['v*']
|
||||
|
||||
jobs:
|
||||
publish:
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
id-token: write
|
||||
contents: read
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Setup Docker Buildx
|
||||
uses: docker/setup-buildx-action@v3
|
||||
|
||||
- name: Login to Docker Hub
|
||||
uses: docker/login-action@v3
|
||||
with:
|
||||
username: ${{ secrets.DOCKER_USERNAME }}
|
||||
password: ${{ secrets.DOCKER_PASSWORD }}
|
||||
|
||||
- name: Extract version
|
||||
id: version
|
||||
run: echo "version=${GITHUB_REF#refs/tags/v}" >> $GITHUB_OUTPUT
|
||||
|
||||
- name: Build and push
|
||||
uses: docker/build-push-action@v5
|
||||
with:
|
||||
context: .
|
||||
push: true
|
||||
tags: yourname/your-server:${{ steps.version.outputs.version }}
|
||||
labels: |
|
||||
io.modelcontextprotocol.server.name=io.github.yourname/your-server
|
||||
|
||||
- name: Install MCP Publisher
|
||||
run: |
|
||||
git clone https://github.com/modelcontextprotocol/registry publisher-repo
|
||||
cd publisher-repo && make publisher && cd ..
|
||||
cp publisher-repo/cmd/publisher/bin/mcp-publisher mcp-publisher
|
||||
|
||||
- name: Publish to MCP Registry
|
||||
run: |
|
||||
./mcp-publisher login github-oidc
|
||||
./mcp-publisher publish
|
||||
```
|
||||
|
||||
|
||||
## Best Practices
|
||||
|
||||
### 1. Version Alignment
|
||||
|
||||
Keep your package version and server.json version in sync:
|
||||
|
||||
```yaml
|
||||
- name: Update server.json version
|
||||
run: |
|
||||
VERSION=${GITHUB_REF#refs/tags/v}
|
||||
jq --arg version "$VERSION" '.version_detail.version = $version' server.json > tmp.json
|
||||
mv tmp.json server.json
|
||||
```
|
||||
|
||||
### 2. Conditional Publishing
|
||||
|
||||
Only publish to registry after package publishing succeeds:
|
||||
|
||||
```yaml
|
||||
- name: Publish to npm
|
||||
run: npm publish
|
||||
id: npm-publish
|
||||
|
||||
- name: Publish to MCP Registry
|
||||
if: steps.npm-publish.outcome == 'success'
|
||||
run: ./mcp-publisher publish
|
||||
```
|
||||
|
||||
### 3. Test Before Publishing
|
||||
|
||||
Include validation in your workflow:
|
||||
|
||||
```yaml
|
||||
- name: Validate server.json
|
||||
run: |
|
||||
# Validate against schema
|
||||
curl -s https://static.modelcontextprotocol.io/schemas/2025-07-09/server.schema.json | \
|
||||
jq . > schema.json
|
||||
npx ajv-cli validate -s schema.json -d server.json
|
||||
|
||||
# Test with publisher
|
||||
./mcp-publisher init --validate-only
|
||||
```
|
||||
|
||||
### 4. Notification Setup
|
||||
|
||||
Get notified of publishing status:
|
||||
|
||||
```yaml
|
||||
- name: Notify on success
|
||||
if: success()
|
||||
run: |
|
||||
curl -X POST "${{ secrets.WEBHOOK_URL }}" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"text": "✅ MCP server ${{ github.repository }} published successfully"}'
|
||||
|
||||
- name: Notify on failure
|
||||
if: failure()
|
||||
run: |
|
||||
curl -X POST "${{ secrets.WEBHOOK_URL }}" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"text": "❌ MCP server ${{ github.repository }} publishing failed"}'
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**"Publisher binary not found"** - Ensure you download the correct binary for your CI platform (linux/mac/windows).
|
||||
|
||||
**"Authentication failed"** - For GitHub OIDC, verify `id-token: write` permission is set. For other methods, check secret configuration.
|
||||
|
||||
**"Package validation failed"** - Ensure your package was published successfully before MCP Registry publishing runs.
|
||||
|
||||
**"Version already exists"** - Each server.json version must be unique. Consider using build numbers: `1.0.0-build.123`.
|
||||
|
||||
## What You've Accomplished
|
||||
|
||||
You now have automated MCP server publishing that:
|
||||
- Triggers on version tags
|
||||
- Runs tests before publishing
|
||||
- Publishes to package registry first
|
||||
- Automatically publishes to MCP Registry
|
||||
- Handles authentication securely
|
||||
- Provides failure notifications
|
||||
|
||||
Your MCP server publishing is now fully automated - just tag a release and everything happens automatically!
|
||||
309
docs/guides/publishing/publish-server.md
Normal file
309
docs/guides/publishing/publish-server.md
Normal file
|
|
@ -0,0 +1,309 @@
|
|||
# Publish Your MCP Server
|
||||
|
||||
Complete guide to publishing an MCP server to the registry.
|
||||
|
||||
## What You'll Learn
|
||||
|
||||
By the end of this tutorial, you'll have:
|
||||
- Created a server.json file for your MCP server
|
||||
- Authenticated with the registry
|
||||
- Successfully published your server
|
||||
- Verified your server appears in the registry
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- An MCP server you've already built ([follow this guide if you don't have one already](https://modelcontextprotocol.io/quickstart/server))
|
||||
- Your server published to a package registry (npm, PyPI, Docker Hub, etc.)
|
||||
|
||||
## Step 1: Install the Publisher CLI
|
||||
|
||||
<!-- TODO: update once #358 solved -->
|
||||
|
||||
Download and build the MCP publisher tool:
|
||||
|
||||
```bash
|
||||
# Clone the registry repository (requires Go 1.24+)
|
||||
git clone https://github.com/modelcontextprotocol/registry
|
||||
cd registry
|
||||
make publisher
|
||||
|
||||
# The binary will be at cmd/publisher/bin/mcp-publisher
|
||||
export PATH=$PATH:$(pwd)/cmd/publisher/bin
|
||||
```
|
||||
|
||||
## Step 2: Initialize Your server.json
|
||||
|
||||
Navigate to your server's directory and create a template:
|
||||
|
||||
```bash
|
||||
cd /path/to/your/mcp-server
|
||||
mcp-publisher init
|
||||
```
|
||||
|
||||
This creates a `server.json` with auto-detected values. You'll see something like:
|
||||
|
||||
```json
|
||||
{
|
||||
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-07-09/server.schema.json",
|
||||
"name": "io.github.yourname/your-server",
|
||||
"description": "A description of your MCP server",
|
||||
"version_detail": {
|
||||
"version": "1.0.0"
|
||||
},
|
||||
"packages": [
|
||||
{
|
||||
"registry_type": "npm",
|
||||
"identifier": "your-package-name",
|
||||
"version": "1.0.0"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Step 3: Configure Your Server Details
|
||||
|
||||
Edit the generated `server.json`:
|
||||
|
||||
### Choose Your Namespace
|
||||
|
||||
The `name` field determines authentication requirements:
|
||||
|
||||
- **`io.github.yourname/*`** - Requires GitHub authentication
|
||||
- **`com.yourcompany/*`** - Requires DNS or HTTP domain verification
|
||||
|
||||
### Add Package Validation
|
||||
|
||||
Your package must include validation metadata to prove ownership.
|
||||
|
||||
|
||||
<details>
|
||||
<summary><strong>📦 NPM Packages</strong></summary>
|
||||
|
||||
### Requirements
|
||||
Add an `mcpName` field to your `package.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "your-npm-package",
|
||||
"version": "1.0.0",
|
||||
"mcpName": "io.github.username/server-name"
|
||||
}
|
||||
```
|
||||
|
||||
### How It Works
|
||||
- Registry fetches `https://registry.npmjs.org/your-npm-package`
|
||||
- Checks that `mcpName` field matches your server name
|
||||
- Fails if field is missing or doesn't match
|
||||
|
||||
### Example server.json
|
||||
```json
|
||||
{
|
||||
"name": "io.github.username/server-name",
|
||||
"packages": [
|
||||
{
|
||||
"registry_type": "npm",
|
||||
"identifier": "your-npm-package",
|
||||
"version": "1.0.0"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The official MCP registry currently only supports the NPM public registry (`https://registry.npmjs.org`).
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><strong>🐍 PyPI Packages</strong></summary>
|
||||
|
||||
### Requirements
|
||||
Include your server name in your package README file using this format:
|
||||
|
||||
**MCP name format**: `mcp-name: io.github.username/server-name`
|
||||
|
||||
Add it to your README.md file (which becomes the package description on PyPI).
|
||||
|
||||
### How It Works
|
||||
- Registry fetches `https://pypi.org/pypi/your-package/json`
|
||||
- Passes if `mcp-name: server-name` is in the README content
|
||||
|
||||
### Example server.json
|
||||
```json
|
||||
{
|
||||
"name": "io.github.username/server-name",
|
||||
"packages": [
|
||||
{
|
||||
"registry_type": "pypi",
|
||||
"identifier": "your-pypi-package",
|
||||
"version": "1.0.0"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The official MCP registry currently only supports the official PyPI registry (`https://pypi.org`).
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><strong>📋 NuGet Packages</strong></summary>
|
||||
|
||||
### Requirements
|
||||
Include your server name in your package's README using this format:
|
||||
|
||||
**MCP name format**: `mcp-name: io.github.username/server-name`
|
||||
|
||||
Add a README file to your NuGet package that includes the server name.
|
||||
|
||||
### How It Works
|
||||
- Registry fetches README from `https://api.nuget.org/v3-flatcontainer/{id}/{version}/readme`
|
||||
- Passes if `mcp-name: server-name` is found in the README content
|
||||
|
||||
### Example server.json
|
||||
```json
|
||||
{
|
||||
"name": "io.github.username/server-name",
|
||||
"packages": [
|
||||
{
|
||||
"registry_type": "nuget",
|
||||
"identifier": "Your.NuGet.Package",
|
||||
"version": "1.0.0"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The official MCP registry currently only supports the official NuGet registry (`https://api.nuget.org`).
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><strong>🐳 Docker/OCI Images</strong></summary>
|
||||
|
||||
### Requirements
|
||||
Add an annotation to your Docker image:
|
||||
|
||||
```dockerfile
|
||||
LABEL io.modelcontextprotocol.server.name="io.github.username/server-name"
|
||||
```
|
||||
|
||||
### How It Works
|
||||
- Registry authenticates with Docker Hub using public token
|
||||
- Fetches image manifest using Docker Registry v2 API
|
||||
- Checks that `io.modelcontextprotocol.server.name` annotation matches your server name
|
||||
- Fails if annotation is missing or doesn't match
|
||||
|
||||
### Example server.json
|
||||
```json
|
||||
{
|
||||
"name": "io.github.username/server-name",
|
||||
"packages": [
|
||||
{
|
||||
"registry_type": "oci",
|
||||
"identifier": "yourusername/your-mcp-server",
|
||||
"version": "1.0.0"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The identifier is `namespace/repository`, and version is the tag and optionally digest.
|
||||
|
||||
The official MCP registry currently only supports the official Docker registry (`https://docker.io`).
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><strong>📁 MCPB Packages</strong></summary>
|
||||
|
||||
### Requirements
|
||||
**MCP reference** - MCPB package URLs must contain "mcp" somewhere within them, to ensure the correct artifact has been uploaded. This may be with the `.mcpb` extension or in the name of your repository.
|
||||
|
||||
### Example server.json
|
||||
```json
|
||||
{
|
||||
"name": "io.github.username/server-name",
|
||||
"packages": [
|
||||
{
|
||||
"registry_type": "mcpb",
|
||||
"identifier": "https://github.com/you/your-repo/releases/download/v1.0.0/server.mcpb"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The official MCP registry currently only supports artifacts hosted on GitHub or GitLab releases.
|
||||
|
||||
</details>
|
||||
|
||||
## Step 4: Authenticate
|
||||
|
||||
Choose your authentication method based on your namespace:
|
||||
|
||||
### GitHub Authentication (for io.github.* namespaces)
|
||||
|
||||
```bash
|
||||
mcp-publisher login github
|
||||
```
|
||||
|
||||
This opens your browser for OAuth authentication.
|
||||
|
||||
### DNS Authentication (for custom domains)
|
||||
|
||||
```bash
|
||||
# Generate keypair
|
||||
openssl genpkey -algorithm Ed25519 -out key.pem
|
||||
|
||||
# Get public key for DNS record
|
||||
echo "_mcp-registry.yourcompany.com. IN TXT \"v=MCPv1; k=ed25519; p=$(openssl pkey -in key.pem -pubout -outform DER | tail -c 32 | base64)\""
|
||||
|
||||
# Add the TXT record to your DNS, then login
|
||||
mcp-publisher login dns --domain yourcompany.com --private-key $(openssl pkey -in key.pem -noout -text | grep -A3 "priv:" | tail -n +2 | tr -d ' :\n')
|
||||
```
|
||||
|
||||
## Step 5: Publish Your Server
|
||||
|
||||
With authentication complete, publish your server:
|
||||
|
||||
```bash
|
||||
mcp-publisher publish
|
||||
```
|
||||
|
||||
You'll see output like:
|
||||
```
|
||||
✓ Validating server.json
|
||||
✓ Checking package ownership
|
||||
✓ Publishing to registry
|
||||
✓ Server published successfully!
|
||||
|
||||
Your server is now available at:
|
||||
https://registry.modelcontextprotocol.io/servers/io.github.yourname/weather-server
|
||||
```
|
||||
|
||||
## Step 6: Verify Publication
|
||||
|
||||
Check that your server appears in the registry:
|
||||
|
||||
```bash
|
||||
curl https://registry.modelcontextprotocol.io/servers/io.github.yourname/weather-server
|
||||
```
|
||||
|
||||
You should see your server metadata returned as JSON.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**"Package validation failed"** - Ensure your package includes the required validation metadata (mcpName field, README mention, or Docker label).
|
||||
|
||||
**"Authentication failed"** - Verify you've correctly set up DNS records or are logged into the right GitHub account.
|
||||
|
||||
**"Namespace not authorized"** - Your authentication method doesn't match your chosen namespace format.
|
||||
|
||||
## Next Steps
|
||||
|
||||
- **Update your server**: Publish new versions with updated server.json files
|
||||
- **Set up CI/CD**: Automate publishing with [GitHub Actions](github-actions.md)
|
||||
- **Learn more**: Understand [server.json format](../../reference/server-json/generic-server-json.md) in depth
|
||||
|
||||
## What You've Accomplished
|
||||
|
||||
You've successfully published your first MCP server to the registry! Your server is now discoverable by MCP clients and can be installed by users worldwide.
|
||||
21
docs/reference/README.md
Normal file
21
docs/reference/README.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
# Reference Documentation
|
||||
|
||||
Technical specifications and quick lookups for the MCP Registry.
|
||||
|
||||
## API Reference
|
||||
|
||||
- [Generic Registry API](./api/generic-registry-api.md)
|
||||
- [Official Registry API](./api/official-registry-api.md)
|
||||
|
||||
## server.json Reference
|
||||
|
||||
- [Generic server.json Format](./server-json/generic-server-json.md)
|
||||
- [Official Registry Requirements](./server-json/official-registry-requirements.md)
|
||||
|
||||
## CLI Reference
|
||||
|
||||
- [Commands](./cli/commands.md)
|
||||
|
||||
## Quick Reference
|
||||
|
||||
- [FAQ](./faq.md)
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue