DSPM MCP Server

This project implements a production-ready Go-based server that conforms to the Model-in-the-Middle Context Protocol (MCP). It is designed to be a flexible and extensible platform for exposing APIs as tools to a large language model (LLM). The server can dynamically load tools from OpenAPI v2 and v3 specifications, providing a powerful and configurable bridge between an LLM and your existing APIs.

Architecture

The server is built with a clean and robust architecture that emphasizes security, reliability, and observability.

• Dual-Server Setup: The application runs two concurrent HTTP servers:

  • The main MCP Server on the external port, which handles all tool-related requests from the LLM.
  • A separate Metrics Server on an internal port, which exposes Prometheus metrics (/metrics) and Kubernetes health probes (/health, /ready).

• Middleware Chain: Incoming requests to the MCP server are processed through a well-ordered middleware chain that provides a layered approach to security and reliability:

  1. Panic Recovery: The outermost middleware catches any panics that occur during request processing, preventing the server from crashing and ensuring high availability.
  2. Rate Limiting: An IP-based rate limiter provides a crucial first line of defense against traffic spikes and denial-of-service attacks.
  3. Authentication: Authentication is handled at the gateway level (e.g., Gloo), which simplifies the application's security model. The ApiKeyMiddleware is responsible for extracting the authenticated user's credentials from the request headers.

• Dependency Injection: The server follows modern Go practices by using dependency injection. The main application configuration is passed explicitly to the components that need it, which makes the code more modular, easier to test, and avoids reliance on global state.

• Dynamic, Type-Safe Tool Generation: For each API operation, a SchemaBuilder dynamically constructs a valid JSON Schema that precisely defines the tool's input parameters. This schema correctly includes nested objects, arrays, data types, descriptions, and which fields are required. The generated schema is passed to the InputSchema field when registering the tool with mcp.AddTool. This provides the LLM with a structured, unambiguous definition of how to call each tool.

Project Structure

The codebase is organized into the following directories, promoting a clean separation of concerns:

• /app: Contains the core application logic.
  • /common: Common API handlers for the metrics server (health, readiness, etc.).
  • /http: The main HTTP server implementation, including the server struct and request handling logic.
  • /middleware: A collection of standard HTTP middleware (panic recovery, rate limiting, and API key handling).
  • /model: Defines the core data structures used throughout the application.
  • /tools: Contains the logic for both static and dynamic tools.
    • /common: Shared data structures for the tool registry.
    • /dynamic: The powerful dynamic tool loading engine, including the SchemaBuilder.
    • /static: Statically defined tools, such as listApis.
• /config: Handles configuration management using the Viper library.
• /charts: Contains the Helm chart for deploying the application to Kubernetes.
• /main.go: The main entry point for the application.

Key Features & Best Practices

This server implements a number of best practices for building production-grade services in Go:

• Flexible and Backward-Compatible Spec Loading: The server can load OpenAPI specifications from multiple sources, including remote HTTP(S) URLs and local file paths. It automatically detects the version and can convert OpenAPI v2 (Swagger) specs to v3 in memory, ensuring broad compatibility without complicating the core logic.

• Configurable Tool Exposure: You have precise control over which AP

... View full README on GitHub