modelcontextprotocol/registry
Watch
1
0
Fork
You've already forked registry
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
registry/docs/server-json
History
Repository files (latest commit first)
Filename Latest commit message Latest commit date
adam jones 6431f23107
 feat: add admin edit endpoint for server moderation (#315) 
## Summary

Implements `PUT /v0/servers/{id}` admin edit endpoint to address part of
issue #182, providing an API-based solution for server moderation
without requiring direct database access.

- **New endpoint**: `PUT /v0/servers/{id}` for editing existing servers
- **Security**: Uses existing JWT auth with `PermissionActionEdit`
permissions
- **Anti-undelete protection**: Added `ServerStatusDeleted` status that
cannot be reverted
- **Full implementation**: Database, service, API, and comprehensive
test coverage

## Key Use Cases

- Mark malicious servers as `deleted` for takedown
- Update server metadata for moderation actions

Related to: https://github.com/modelcontextprotocol/registry/issues/182
(but that is not _done_ yet because we need admins to be able to login
(probably with #283), and need to add docs on how to do the takedown,
and probably guidelines on what we will/won't takedown)
2025-08-27 21:28:04 +01:00
..
examples.md feat: Add support for MCP Bundles (MCPB) in registry (#295) 2025-08-27 04:44:53 +01:00
README.md Add $schema to server.json specification to enable versioning, IDE autocomplete (#308) 2025-08-27 01:30:25 +01:00
registry-schema.json feat: Add support for MCP Bundles (MCPB) in registry (#295) 2025-08-27 04:44:53 +01:00
repository_references.md Add $schema to server.json specification to enable versioning, IDE autocomplete (#308) 2025-08-27 01:30:25 +01:00
server.schema.json feat: add admin edit endpoint for server moderation (#315) 2025-08-27 21:28:04 +01:00

README.md

server.json file

There are a variety of use cases where a static representation of an MCP server is necessary:

  • Discoverability on a centralized registry (i.e. our official Registry work)
  • Discoverability on a decentralized .well-known endpoint
  • As a response to an initialization call, so the client knows information about the MCP server to which it is connecting
  • As an input into crafting a DXT file
  • Packaged in with the source code of an MCP server, so as to have a structured way to identify a server given just its source code

All of these scenarios (and more) would benefit from an agreed-upon, standardized format that makes it easy to port around and maintain a consistent experience for consumers and developers working with the data. At the end of the day, it's all the same data (or a subset of it). MCP server maintainers should have to manage one copy of this file, and all these use cases can serve that file (or a programmatic derivative/subset of it).

Please note: this is different from the file commonly referred to as mcp.json, which is an MCP client's configuration file for running a specific set of MCP servers. See this issue.

References:

  • server.schema.json - The official JSON schema specification for this representation
  • examples.md - Example manifestations of the JSON schema
  • registry-schema.json - A more constrained version of server.schema.json that the official registry supports

Validation Tools

Two validation tools are provided in the repository's tools/ directory:

  • validate-schemas - Validates that server.schema.json and registry-schema.json are valid JSON Schema documents
  • validate-examples - Validates that all JSON examples in examples.md conform to both schemas

Usage

From the repository root:

Validate JSON Schemas

./tools/validate-schemas.sh

Validate Examples

./tools/validate-examples.sh