registry/docs/server-registry-api
Repository files (latest commit first)
Filename Latest commit message Latest commit date
adam jones 218b0b422d
Implement flattened _meta format for server extensions (#331)
## Summary

This PR implements the flattened `_meta` format for server extensions as
discussed in #284, replacing the confusing wrapper format with a clean
single-file approach.

**Before (wrapper format):**
```json
{
  "server": { "name": "my-server", "description": "..." },
  "x-publisher": { "build_info": "..." },
  "x-io.modelcontextprotocol.registry": { "id": "...", "published_at": "..." }
}
```

**After (flattened format):**
```json
{
  "name": "my-server",
  "description": "...",
  "_meta": {
    "publisher": { "build_info": "..." },
    "io.modelcontextprotocol.registry": { "id": "...", "published_at": "..." }
  }
}
```

## Key Changes

- **Flattened Format**: Single `ServerJSON` file with structured `_meta`
field
- **Better DX**: Publishers maintain one file instead of separate
server.json + extensions.json
- **MCP Compliance**: Uses standard `_meta` mechanism instead of `x-*`
prefixes
- **Simplified Database**: PostgreSQL now uses simple `id, value` table
structure
- **Type Safety**: Structured `ServerMeta` with known extension fields

## Database Migration

Added migration `003_simplify_to_key_value.sql` that drops the complex
relational structure and creates a simple key-value table. This
significantly simplifies database management.

## Testing

- All core tests passing (validators, service layer)
- Schema validation working for all 10 examples
- Seed data successfully migrated (396 entries)
- Publishing functionality verified

Fixes #284
2025-09-01 19:27:23 +01:00
..
openapi.yaml Implement flattened _meta format for server extensions (#331) 2025-09-01 19:27:23 +01:00
README.md api: Use Huma to generate swagger docs and parse JSON automatically (#262) 2025-08-13 16:57:55 +01:00

Registry API

There are a variety of use cases where an MCP Server Registry API is useful to the MCP ecosystem. At least the following:

  • Implementation of a centralized, publicly available catalog of all publicly accessible MCP server implementations
  • Implementation of a private catalog of MCP server implementations exclusively accessible by a specific group of people (e.g. a single enterprise)

These scenarios would benefit from a standard "MCP server registry API" specification that they could potentially compose, as well as share resources (like SDK implementations).

The centralized, publicly available catalog ("Official MCP Registry") needs additional constraints that need not apply to the broader "MCP server registry API"

References:

  • openapi.yaml - A reusable API specification (MCP Server Registry API) that anyone building any sort of "MCP server registry" should consider adopting / aligning with.
  • https://registry.modelcontextprotocol.io/openapi.yaml - The specification backing the Official MCP Registry; a derivative of the MCP Server Registry API specification.