A standards-compliant MCP Registry API server for ToolHive
The ToolHive Registry API (thv-registry-api) implements the official Model Context Protocol (MCP) Registry API specification. It provides a standardized REST API for discovering and accessing MCP servers from multiple backend sources.
Features
Standards-compliant: Implements the official MCP Registry API specification
Multiple backends: Supports Kubernetes ConfigMaps and file-based registry data
Container-ready: Designed for deployment in Kubernetes clusters
Flexible deployment: Works standalone or as part of ToolHive infrastructure
Production-ready: Built-in health checks, graceful shutdown, and basic observability
The server starts on port 8080 by default. Use --address :PORT to customize.
API Endpoints
The server implements the standard MCP Registry API:
GET /api/v0/servers - List all available MCP servers
GET /api/v0/servers/{name} - Get details for a specific server
GET /api/v0/deployed - List deployed server instances (Kubernetes only)
GET /api/v0/deployed/{name} - Get deployed instances of a specific server
See the MCP Registry API specification for full API details.
Note: The current implementation is not strictly compliant with the standard. The deviations will be fixed in the next iterations.
Configuration
Command-line Flags
The thv-registry-api serve command supports the following flags:
Flag
Description
Required
Default
--address
Server listen address
No
:8080
--from-configmap
ConfigMap name containing registry data
Yes*
-
--from-file
Path to registry.json file
Yes*
-
--registry-name
Registry identifier
Yes
-
*One of --from-configmap or --from-file must be specified (mutually exclusive)
Backend Options
ConfigMap Backend
Fetches registry data from a Kubernetes ConfigMap. Requires:
Kubernetes API access (in-cluster or via kubeconfig)
ConfigMap with a registry.json key containing MCP registry data
Appropriate RBAC permissions to read ConfigMaps
File Backend
Reads registry data from a local file. Useful for:
Mounting ConfigMaps as volumes in Kubernetes
Local development and testing
Static registry deployments
Development
Build Commands
# Build the binary
task registry-build
# Run linting
task lint
# Fix linting issues automatically
task lint-fix
# Run tests
task registry-test
# Generate mocks
task gen
# Build container image
task registry-build-image
Project Structure
cmd/thv-registry-api/
├── api/v1/ # REST API handlers and routes
├── app/ # CLI commands and application setup
├── internal/service/ # Business logic and data providers
│ ├── file_provider.go # File-based registry backend
│ ├── k8s_provider.go # Kubernetes ConfigMap backend
│ ├── provider.go # Provider interfaces
│ └── service.go # Core service implementation
└── main.go # Application entry point
Architecture
The server follows a clean architecture pattern:
API Layer (api/v1): HTTP handlers implementing the MCP Registry API
Service Layer (internal/service): Business logic for registry operations
Provider Layer: Pluggable backends for registry data sources
FileRegistryDataProvider: Reads from local files
K8sRegistryDataProvider: Fetches from Kubernetes ConfigMaps
K8sDeploymentProvider: Queries deployed MCP server instances
Testing
The project uses table-driven tests with mocks generated via go.uber.org/mock:
# Generate mocks before testing
task gen
# Run all tests
task registry-test
Deployment
Kubernetes
The Registry API is designed to run as a sidecar container alongside the ToolHive Operator's MCPRegistry controller. Example deployment: