McpDemo

davidknaack/McpDemo

3.1

If you are the rightful owner of McpDemo and would like to certify it and/or have it hosted online, please leave a comment on the right or send an email to dayong@mcphub.com.

The Model Context Protocol (MCP) server is a TypeScript-based server that interfaces with a configuration management system, enabling AI agents and MCP-capable IDEs to access and manipulate configuration data.

Tools
6
Resources
0
Prompts
0

MCP Demo Configuration Platform

This repository contains a demo environment for showcasing how a Model Context Protocol (MCP) server can expose a configuration management system to AI agents. The solution is organised into three cooperating applications:

  • ConfigServer – ASP.NET Core Web API that simulates the configuration database with API-key authentication, SQLite persistence, environment/project scoping, and detailed change history.
  • ConfigMcpServer – TypeScript MCP server that wraps the configuration API, exposing tools and resources to MCP-capable IDEs or agents.
  • TodoDemoApi – ASP.NET Core Web API that consumes the configuration service via a custom configuration provider. The API demonstrates typed access to string, integer, float, and delimited list settings.

Tests for the configuration service live under tests/ConfigServer.Tests and exercise the core mutation and history flows.


Repository Layout

.
├── README.md
├── McpDemo.sln
├── src
│   ├── ConfigServer          # Configuration service (ASP.NET Core, EF Core, SQLite)
│   ├── ConfigMcpServer       # MCP server (TypeScript + @modelcontextprotocol/sdk)
│   └── TodoDemoApi           # Demo consumer API (ASP.NET Core)
└── tests
    └── ConfigServer.Tests    # xUnit tests for configuration service behaviours

Prerequisites

  • .NET SDK 9.0 or higher
  • Node.js 18 LTS (or newer) with npm
  • SQLite (bundled with .NET)
  • Optional: Docker Desktop if you plan to containerise the services

Before running the ASP.NET apps, trust the local development certificate if you have not already:

dotnet dev-certs https --trust

Building Everything

# restore and build .NET projects
dotnet build

# install MCP server dependencies and compile TypeScript
cd src/ConfigMcpServer
npm install
npm run build

Run automated tests for the configuration service with:

dotnet test

Running the Configuration Server (ConfigServer)

To run the server with HTTPS enabled (recommended, matches the URL examples below):

dotnet run --project src/ConfigServer --launch-profile https

Or run with HTTP only:

dotnet run --project src/ConfigServer --launch-profile http

Key characteristics:

  • SQLite database file (config.db / config.dev.db) created in the working directory with EF Core migrations.
  • Seed data for four environments (Dev, QA, MO, Production) and multiple settings across two projects.
  • API-key authentication via the X-Api-Key header. Default keys are defined in appsettings.json:
    • mcp-servermcp-demo-key
    • todo-demo-apptodo-demo-key
    • developerdev-test-key
  • Swagger UI available at /swagger once the service is running.
  • Health probe at /health (no authentication required).

Example requests (using curl):

# List environments
curl -H "X-Api-Key: dev-test-key" https://localhost:7226/api/environments

# Get settings for Dev/TodoService
curl -H "X-Api-Key: dev-test-key" https://localhost:7226/api/environments/Dev/projects/TodoService/settings

# Apply a batch update
curl -X PUT https://localhost:7226/api/environments/Dev/projects/TodoService/settings \
     -H "Content-Type: application/json" \
     -H "X-Api-Key: dev-test-key" \
     -d '{ "comment": "Demo change", "settings": [ { "name": "Todo:StaleMinutes", "value": "25" } ] }'

Running the Demo Consumer (TodoDemoApi)

The demo API bootstraps configuration from the server using a custom configuration provider. Default settings live in appsettings.json:

"ConfigServer": {
  "BaseAddress": "https://localhost:7226/",
  "Environment": "Dev",
  "Project": "TodoService",
  "ApiKey": "todo-demo-key",
  "AllowUntrustedCertificates": true
}

Start the API with HTTPS enabled (requires ConfigServer running with the https profile):

dotnet run --project src/TodoDemoApi --launch-profile https

Or run with HTTP only:

dotnet run --project src/TodoDemoApi --launch-profile http

Highlights:

  • Custom configuration provider fetches settings at startup and on-demand refresh (POST /api/configuration/refresh).
  • TodoSettingsProvider converts raw strings into typed values (string, int, double, delimited string array).
  • TodoController demonstrates configuration-aware behaviours (stale detection, tag defaults, open item limits).
  • Web UI available at the root URL (/) provides a browser-based interface for managing todos
  • Swagger UI available at /swagger; health check at /health.

Sample usage:

# Access the web UI in your browser
# HTTPS: https://localhost:7224
# HTTP: http://localhost:5179

# List todos (stale items flagged using config value)
curl -k https://localhost:7224/api/todos

# Inspect current configuration snapshot
curl -k https://localhost:7224/api/configuration

# Force reload from the configuration server
curl -k -X POST https://localhost:7224/api/configuration/refresh

Running the MCP Server (ConfigMcpServer)

The MCP server consumes the configuration API and exposes tools/resources via stdio transport.

  1. Install dependencies & build (if not already done):

    cd src/ConfigMcpServer
    npm install
    npm run build
    
  2. Export (or override) environment variables to control connectivity:

    export CONFIG_SERVER_BASE_URL=https://localhost:7226/
    export CONFIG_SERVER_API_KEY=mcp-demo-key
    export CONFIG_SERVER_DEFAULT_ENV=Dev
    export CONFIG_SERVER_DEFAULT_PROJECT=TodoService
    export CONFIG_SERVER_API_KEY_HEADER=X-Api-Key
    # When using self-signed certificates (like the dotnet dev cert):
    export NODE_TLS_REJECT_UNAUTHORIZED=0
    # optional: CONFIG_SERVER_TIMEOUT_MS (default 15000)
    
  3. Launch the MCP server (stdio transport):

    node dist/index.js
    

Registered tools include:

  • config.listEnvironments – enumerate environments with read-only flag.
  • config.setEnvironmentMode – toggle read-only/read-write mode.
  • config.listProjects – list available projects.
  • config.getSettings – retrieve settings for an environment/project.
  • config.updateSettings – batch update with comment requirement.
  • config.getHistory – view change history (optionally scoped to a setting).

The server also exposes a dynamic resource template (config://settings/{environment}/{project}) that streams settings for any environment/project pair.

You can wire this MCP server into MCP-aware tools such as the Claude desktop app, Cursor, or VS Code MCP support by referencing the stdio command and the environment variables above.


Database & Seeding Details

  • SQLite files live next to the executable (config.db for production, config.dev.db for Development environment).
  • ConfigurationDbContext seeds environments (Dev, QA, MO, Production), two projects (TodoService, ReportingService), and rich settings covering strings, integers, doubles, and delimited string lists.
  • Change tracking uses a ChangeSet plus per-setting SettingChange entries with comments and timestamps provided by the API caller.
  • Test coverage (ConfigServer.Tests) verifies update flows, read-only enforcement, and history retrieval.

Next Steps / Ideas

  • Add Dockerfiles (or docker-compose) to containerise the three applications.
  • Implement authentication back-ends beyond API keys (e.g., OAuth client credentials).
  • Extend MCP server with prompt templates or richer resources.
  • Introduce background refresh in TodoDemoApi (e.g., IHostedService) or integrate IOptionsMonitor.
  • Build UI tooling for manually approving configuration promotions between environments.

Troubleshooting

  • Certificate issues – set AllowUntrustedCertificates to true while developing locally, or trust the ASP.NET developer certificate via dotnet dev-certs https --trust.
  • API key failures – ensure requests supply the correct X-Api-Key value. The key name can be adjusted in configuration but must match on both services and the MCP server.
  • SQLite locking – when switching between services or running tests, stop any running API instances to release file handles.
  • MCP connectivity – confirm the MCP server shares the same base URL and API key as configured in ConfigServer. Use CONFIG_SERVER_TIMEOUT_MS to relax slow connections.

Happy experimenting! Feel free to adapt the services or settings to match your demo scenario.