An ultra-simple MCP server architecture centralizing Supabase and Redis behind a unified API.
Configuration
View docs{
"mcpServers": {
"ak125-mcp": {
"url": "http://localhost:3001",
"headers": {
"PORT": "3001",
"REDIS_URL": "redis://localhost:6379",
"SUPABASE_KEY": "your-anon-key",
"SUPABASE_URL": "https://your-project.supabase.co"
}
}
}
}You run a centralized MCP server that exposes a clean API to access your Supabase and Redis-backed data and actions. This design keeps your frontend, backend, and data sources cohesive, so you can build and scale with a single, authoritative API layer as the source of truth.
Interact with the MCP server through its API to read and modify data, trigger backend jobs, and view real-time information. The frontend and backend components consume this single API, ensuring consistent behavior and validation across the stack. You can access the frontend, the MCP server, and its API documentation from the local development URLs while building and testing.
Prerequisites you need before installation: Node.js and npm, and a running Redis instance if you are not using the included local setup.
# 1) Clone the project repository (adjust path as needed)
# git clone https://example.com/ak125/mcp.git
# 2) Install all required packages for the MCP server and related components
cd mcp
npm run install:all
# 3) Start the development environment (local Redis is included in the setup)
npm run dev
# 4) Open the local URLs to verify the setup
# Frontend: http://localhost:3000
# MCP Server: http://localhost:3001
# API Docs: http://localhost:3001/docs
# Backend: http://localhost:3002Configure the MCP server to connect to your data sources and cache. The main MCP server runs on port 3001 and requires access to Supabase and Redis. You also set environment variables to point to your services.
# mcp-server/.env
PORT=3001
SUPABASE_URL=https://your-project.supabase.co
SUPABASE_KEY=your-anon-key
REDIS_URL=redis://localhost:6379All access to data goes through the MCP API. Direct database or cache access from clients is blocked to enforce a single, auditable path. ESLint rules can be applied to prevent direct data source imports in client code.
In production, build and deploy using the same single API surface. The MCP server provides health checks and centralized logs to monitor the system health and traffic. You can verify the health endpoint and access API docs for current capabilities.
# Health check
curl http://localhost:3001/health
# API docs
http://localhost:3001/docsThe stack uses TypeScript auto-generated types, a single source of truth for API contracts, and hot reloading across services to speed up development. It includes a Swagger-generated API surface and clear validation with Zod to reduce runtime errors.
If you encounter issues during startup, verify that the MCP server URL is reachable, Redis is running, and the required environment variables are set. Check the MCP server logs for any authentication or connection errors and ensure the API surface is accessible at the expected port.
This architecture keeps operations simple by funneling all data access through one API, while preserving the full frontend/backend stack and data source capabilities.
Endpoint to verify MCP server health and readiness.
Swagger-generated documentation for the MCP API surface.
All logs are collected in the MCP server for unified monitoring.
Rule preventing direct access to data sources from client code.
TypeScript types are generated and shared across the stack.