Skip to main content
Workflows Library MCP Directory Realtime AI News Sponsor Tier Subscribe
Front Page / AI Tools / Deep Dive

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

Deepak Bagada

CEO, SaaSNext

Sep 09, 2026 Published
|
Sep 09, 2026 Updated
|
7 Minutes Reading Time
Core Takeaways for Founders & Builders
  • 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

  1. MCP God provides comprehensive MCP governance — rate limiting, access control, traffic inspection, and monitoring through a single transparent proxy.
  2. Zero client or server code changes required — MCP God intercepts at the transport layer without modifying existing MCP implementations.
  3. 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.

Executive Briefing

Enjoyed this breakdown? Get our morning dispatch in your inbox.

Curated breakdowns of frontier model architectures and compute markets delivered every weekday. Zero fluff.

🎉 Thank You for Subscribing!

Frequently Asked Questions
No — MCP God is a transparent proxy. Existing MCP servers continue running unchanged. The only configuration change is that clients point to MCP God's endpoint instead of directly to each server. MCP God forwards all standard MCP method calls (tools/list, tools/call, resources/list, etc.) without any protocol modifications.
MCP God identifies clients via an x-mcp-client-id header (or fallback to source IP). Each client maps to a role with defined policies: which servers they can access, which tools are allowed/blocked, and their rate limits. Claude Desktop might have full access, while a CI pipeline agent has restricted access to read-only tools only. Unknown clients get the strictest default policy.
All connected clients lose access to MCP tools. For production deployments, run two MCP God instances with a shared Redis-backed state. If the primary fails, DNS or load balancer routes to the secondary. For critical servers (filesystem, database), maintain a direct fallback bypass URL that clients can use during MCP God maintenance windows.
Yes — MCP God maintains a tool allowlist/blocklist for each server. When a client calls a tool, MCP God checks the tool name against the list before forwarding. If the tool is blocked, the client receives an access denied error without the actual server ever receiving the request. This is useful for disabling dangerous tools like write_file or delete_database without modifying the underlying MCP server code.
Deepak Bagada
Author Profile

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.

Related Intelligence Analysis

Briefing AI Tools

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...

Deepak Bagada Deepak Bagada
12m read
Breaking AI Tools

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...

Deepak Bagada Deepak Bagada
4m read
Audio Briefing
Accessibility Preferences
High Contrast Mode
Accessible Reading Font

Keyboard Shortcuts

Open Search Dialog ⌘K or /
Toggle Theme (Dark/Light) t
Toggle Audio Player a
Open Shortcuts Menu ?
Close Active Dialog Esc