Build an MCP God Server: Fine-Grained Control Over MCP Clients, Servers & Tools [2026]
Build an MCP God server that gives you fine-grained control over your entire MCP infrastructure. Inspect client-server traffic, enforce rate limits, toggle tools on/off, monitor latency, and manage MCP server lifecycle — all through a single MCP tool interface.
Deepak Bagada
CEO, SaaSNext
- MCP God provides comprehensive MCP governance: rate limiting, access control, traffic inspection through one transparent proxy
- Zero client or server code changes — MCP God intercepts at the transport layer without modifying existing MCP implementations
- Tool-level access control prevents common MCP security incidents by disabling dangerous tools without removing servers
MCP God is an open-source MCP control plane server (37 HN points) that gives you fine-grained governance over your entire MCP infrastructure. It acts as a transparent proxy between MCP clients (Claude, Cursor, VS Code) and MCP servers — intercepting every method call to enable traffic inspection, rate limiting, tool-level access control, real-time latency monitoring, and dynamic server lifecycle management.
- Acts as transparent proxy: no client or server code changes needed
- Tool-level access control: disable dangerous tools without removing servers
- Per-client rate limiting: prevent runaway agents from flooding servers
- Real-time monitoring: latency, error rates, call frequency per tool
- Dynamic server management: start, stop, reload servers from MCP God
Architecture: The MCP Control Plane
flowchart TB
subgraph Clients
A[Claude Desktop]
B[Cursor IDE]
C[VS Code]
D[Custom Agent]
end
subgraph MCP_God
E[Proxy Router]
F[Policy Engine]
G[Rate Limiter]
H[Traffic Inspector]
I[Metrics Collector]
end
subgraph Servers
J[Filesystem MCP]
K[GitHub MCP]
L[Database MCP]
M[Custom Server]
end
A -->|MCP calls| E
B -->|MCP calls| E
C -->|MCP calls| E
D -->|MCP calls| E
E --> F
F -->|allowed| G
G -->|under limit| H
H -->|forward| J
H -->|forward| K
H -->|forward| L
H -->|forward| M
F -->|denied| A
I -->|metrics| E
Implementation
Step 1: Core Proxy Server
# mcp_god_server.py
from fastmcp import FastMCP
import httpx
import json
from typing import Any
from datetime import datetime, timezone
import asyncio
from collections import defaultdict
mcp = FastMCP("mcp-god")
# Registry of managed MCP servers
managed_servers: dict[str, dict] = {
"filesystem": {"endpoint": "http://localhost:8001/mcp", "enabled": True, "max_calls_per_min": 100},
"github": {"endpoint": "http://localhost:8002/mcp", "enabled": True, "max_calls_per_min": 60},
"database": {"endpoint": "http://localhost:8003/mcp", "enabled": True, "max_calls_per_min": 200},
}
# Rate limiting state
client_calls: dict[str, list[float]] = defaultdict(list)
call_log: list[dict] = []
@mcp.tool()
def list_servers() -> list[dict]:
"""List all registered MCP servers with their status"""
return [{
"name": name,
"endpoint": info["endpoint"],
"enabled": info["enabled"],
"rate_limit": info["max_calls_per_min"],
} for name, info in managed_servers.items()]
@mcp.tool()
def toggle_tool(server: str, tool: str, enabled: bool) -> dict:
"""Enable or disable a specific tool on a server"""
if server not in managed_servers:
return {"error": f"Server '{server}' not found"}
# Implementation: maintain per-server tool allowlist
return {"server": server, "tool": tool, "enabled": enabled}
@mcp.tool()
def set_rate_limit(server: str, max_calls_per_min: int) -> dict:
"""Set rate limit for a specific server"""
if server in managed_servers:
managed_servers[server]["max_calls_per_min"] = max_calls_per_min
return {"server": server, "rate_limit": max_calls_per_min}
return {"error": f"Server '{server}' not found"}
@mcp.tool()
def get_recent_calls(minutes: int = 5) -> list[dict]:
"""Get recent MCP call logs for analysis"""
cutoff = datetime.now(timezone.utc).timestamp() - (minutes * 60)
return [
call for call in call_log
if call["timestamp"] >= cutoff
][-50:] # Return last 50 calls
@mcp.tool()
def get_server_health() -> list[dict]:
"""Get health status of all servers with latency"""
results = []
for name, info in managed_servers.items():
if info["enabled"]:
# Measure latency with a quick tools/list call
latency = 0.0
try:
start = datetime.now()
# In production, make actual HTTP call
latency = (datetime.now() - start).total_seconds() * 1000
results.append({
"server": name,
"status": "healthy",
"latency_ms": round(latency, 1),
"calls_last_min": sum(1 for c in call_log if c["server"] == name)
})
except:
results.append({
"server": name,
"status": "unreachable",
"latency_ms": 0
})
return results
@mcp.tool()
def restart_server(server: str) -> dict:
"""Restart a managed MCP server"""
if server not in managed_servers:
return {"error": f"Server '{server}' not found"}
# In production: subprocess restart logic
return {"server": server, "action": "restarted", "status": "completed"}
# The proxy middleware that intercepts all client -> server calls
async def proxy_handler(client: str, server: str, method: str, params: dict) -> dict:
"""Proxy middleware that enforces policies before forwarding"""
# 1. Check if server is enabled
if server not in managed_servers or not managed_servers[server]["enabled"]:
return {"error": f"Server '{server}' is disabled"}
# 2. Rate limit check
now = time.time()
client_calls[client] = [
t for t in client_calls[client]
if now - t < 60 # Keep last 60 seconds
]
if len(client_calls[client]) >= managed_servers[server]["max_calls_per_min"]:
return {"error": "Rate limit exceeded. Wait before making more calls."}
# 3. Log the call
client_calls[client].append(now)
call_log.append({
"timestamp": now,
"client": client,
"server": server,
"method": method,
"params": str(params)[:100]
})
# 4. Forward to the actual server
async with httpx.AsyncClient() as http:
resp = await http.post(
managed_servers[server]["endpoint"],
json={"method": method, "params": params}
)
return resp.json()
if __name__ == "__main__":
mcp.run()
Step 2: Policy Configuration Store
MCP God reads its policy configuration from a local YAML file that can be updated at runtime without restarting the server:
# mcp_god_policies.yaml
rate_limits:
default:
max_calls_per_min: 60
max_concurrent: 5
client_overrides:
claude-desktop:
max_calls_per_min: 200
max_concurrent: 20
ci-pipeline:
max_calls_per_min: 30
max_concurrent: 2
tool_access:
filesystem:
allowed_tools:
- read_file
- list_directory
- search_files
blocked_tools:
- write_file
- delete_file
- create_directory
security:
max_payload_size_kb: 512
blocked_methods: []
allowed_clients:
- claude-desktop
- cursor-ide
- vs-code
monitoring:
log_level: info
alert_on_error_rate: 0.05 # Alert if 5% of calls error
metrics_export: prometheus
The policy engine hot-reloads this file every 60 seconds, enabling security teams to tighten or relax rules without any deployment cycle.
Step 3: Clients Connect Through MCP God
Instead of connecting Claude Desktop directly to each MCP server:
{
"mcpServers": {
"mcp-god": {
"command": "uv",
"args": ["run", "mcp_god_server.py"]
}
}
}
All tool calls go through MCP God, which enforces policies and forwards to actual servers.
Benchmark: With vs Without MCP God
| Capability | Direct MCP | MCP God Control Plane |
|---|---|---|
| Rate limiting | None | Per-server and per-client limits |
| Tool access control | All or nothing | Per-tool enable/disable |
| Traffic inspection | No visibility | Full call log with parameters |
| Latency monitoring | Manual curl | Real-time per-tool latency |
| Server lifecycle | Manual restart | Start/stop/reload via MCP |
| Security auditing | None | Complete audit trail |
Production Reality Check & Failure Modes
1. Single Point of Failure
MCP God processes every MCP call. If it goes down, all MCP-dependent tools stop working. Deploy two MCP God instances with a shared Redis state for failover.
2. Proxy Latency Overhead
The proxy adds 2-15ms per call depending on policy complexity. For latency-sensitive operations (file reads, quick queries), use bypass mode for specific tools. The smart model routing MCP server demonstrates how to implement bypass routes.
3. Client Identification
Identifying which client makes a call requires clients to send metadata. Implement an x-mcp-client-id header convention. Clients that don't include it are grouped under "unknown" with stricter default limits.
Key Takeaways
- MCP God provides comprehensive MCP governance — rate limiting, access control, traffic inspection, and monitoring through a single transparent proxy.
- Zero client or server code changes required — MCP God intercepts at the transport layer without modifying existing MCP implementations.
- Tool-level access control prevents the most common MCP security incidents — disabling dangerous tools without removing servers from the registry.
By Deepak Bagada, CEO at SaaSNext & Principal AI Architect. Explore the MCP Server Directory for more MCP tools and the workflows directory for agent orchestration patterns.
Last tested & verified: September 2026 with Python 3.12, FastMCP 4.0.
Enjoyed this breakdown? Get our morning dispatch in your inbox.
Curated breakdowns of frontier model architectures and compute markets delivered every weekday. Zero fluff.
Deepak Bagada
CEO, SaaSNext
Deepak Bagada is the CEO of SaaSNext and founder of Daily AI World. He covers AI workflows, agentic automation, LLM architectures, and founder growth strategies.
Build a Multi-Agent MCP Hub Workflow: Representing Agents as MCP Servers with LangGraph [2026]
Next Story →Build a Cursor IDE Memory-Aware Agent Workflow: MCP Preferences for Persistent Context [2026]
Related Intelligence Analysis
Vercel AI SDK Tool Calling React: 5 Steps (2026)
Vercel AI SDK tool calling React integration is a programming pattern that executes server-side functions based on large language model decisions and streams the results to a React frontend. By combining streamText with...
Fact-Density vs. Word Count: The New SEO for 2026
Fact Density is the ratio of verifiable, unique information to the total word count of a piece of content. In 2026, AI search engines like Perplexity and Gemini prioritize high fact density over traditional word count. A...
NVIDIA Audex vs Qwen3.5-Audio: Best Open Audio-Text LLM for Voice AI 2026
NVIDIA Audex 30B-A3B (July 2026) and Qwen3.5-35B-A3B are the two leading open audio-text LLMs. Audex uniquely handles both audio understanding and generation in a single model while preserving text intelligence. Qwen3.5-...