Meta MCP Server for Tool Discovery

Overview

The Meta MCP Server for Tool Discovery is a lightweight registry and discovery service that implements the Model Context Protocol (MCP) to help language models and tools find and use external services, APIs, and plugins. It indexes tool metadata and manifests, exposes a simple HTTP API for discovery and registration, and serves as a central catalog that MCP-capable clients can query to locate capabilities, documentation, and runtime endpoints.

This server is useful when you want a single source of truth for tool metadata in an ecosystem of microservices, plugins, or third-party APIs. Instead of scattering manifests and OpenAPI files across repositories, the MCP server provides search, filtering, and standardized manifests so model-driven agents and developer tools can integrate faster and with less manual wiring.

Features

• Centralized registry for tool manifests and metadata
• HTTP API for registering, listing, and retrieving tools
• Search and filter by name, tag, capability, or protocol
• Support for common manifest formats (MCP, OpenAPI, plugin manifests)
• Lightweight persistence (in-memory by default, optional external store)
• Health and metrics endpoints for monitoring
• Configurable authentication and API keys
• Docker-ready for simple deployment

Installation / Configuration

Clone the repository and run the server locally or with Docker. The examples below show common ways to get started.

Clone and run (local / Node-like example)

git clone https://github.com/wojtyniak/mcp-mcp.git
cd mcp-mcp
# Install dependencies (if the project uses npm/yarn)
npm install
npm run start

Run with Docker

# Build image
docker build -t mcp-server .

# Run with default settings
docker run -p 8080:8080 mcp-server

# Or run with environment overrides
docker run -p 8080:8080 \
  -e MCP_PORT=8080 \
  -e MCP_STORE=redis \
  -e REDIS_URL=redis://redis:6379 \
  mcp-server

Environment variables (example)

MCP_PORT=8080              # HTTP port
MCP_STORE=in-memory        # 'in-memory' | 'redis' | 'postgres'
REDIS_URL=redis://localhost:6379
API_KEY=changeme           # Optional API key for writes/registrations
LOG_LEVEL=info

Configuration file (YAML) — optional static seed of tools

tools:
  - id: "weather-api"
    name: "Weather API"
    description: "Provides current weather & forecasts"
    endpoints:
      - url: "https://api.example.com/weather"
        type: openapi
    tags: ["weather","forecast","api"]
  - id: "calendar-plugin"
    name: "Calendar Plugin"
    description: "Plugin for managing events"
    endpoints:
      - url: "https://plugin.example.com/.well-known/ai-plugin.json"
        type: plugin

Available Resources

Common HTTP endpoints exposed by the server (paths are illustrative):

Example: register a tool via curl

curl -X POST http://localhost:8080/tools \
  -H "Authorization: Bearer changeme" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "example-tool",
    "name": "Example Tool",
    "description": "An example service",
    "endpoints":[{"url":"https://example.com/openapi.json","type":"openapi"}],
    "tags":["example","demo"]
  }'

Use Cases

• LLM tool discovery: An agent asking “what tools can I use for calendar management?” can query the MCP server to find plugin manifests, OpenAPI specs, and endpoints that expose calendar capabilities.
• Developer portals: Aggregate service manifests across teams into one searchable catalog so new engineers can discover APIs, status pages, and docs quickly.
• Runtime plugin loading: Dynamically fetch plugin manifests at runtime for sandboxed execution, enabling models to invoke external capabilities without bundling manifests into the model.
• Integration testing: Use a local MCP server to seed stable testable tool manifests for reproducible integration tests that require predictable tool discovery.

Getting Started Tips

• Seed the server with static YAML in development to avoid relying on external registrations.
• Protect write endpoints with an API key or auth provider in production to avoid tampering with tool manifests.
• Use a persistent store (Redis/Postgres) for production so the registry survives restarts; in-memory is suitable for local testing.
• Monitor /metrics and /health in orchestration platforms (Kubernetes, Docker Compose) for automatic restarts and alerts.

The Meta MCP server acts as a pragmatic launching point for integrating MCP-aware clients with a growing set of tools and plugins. Its simple API and manifest-first approach make it straightforward to adopt in development workflows and production registries.