Skip to main content
Back to Work
PLANNED DESIGN

Nexus

Planned MCP gateway that will give any LLM secure access to enterprise tools through one universal protocol. Not built yet (October 2026)

MCPFastAPIDockerPostgreSQLRedisPydantic
  • Not built yet (October 2026)
  • Solo Architect & Builder
  • Planned
Status, October 2026: planned, not built yet.
Nexus is a design on my roadmap. This page sets out the problem it targets and how I plan to build it. It reports no results, because there are none yet.

The Problem

Every AI tool integration is a custom job. Connect an LLM to Salesforce — custom code. Connect it to Jira — different custom code. Connect it to an internal database — yet another integration. Multiply this by every model, every tool, every team, and you get an integration matrix that grows quadratically.

The Model Context Protocol (MCP) solves this by standardizing how LLMs connect to external tools. But MCP alone is a protocol — someone still needs to build the gateway, handle authentication, manage rate limiting, and ensure enterprise-grade security.


The Architecture

Nexus is a planned MCP gateway that will sit between any LLM and any enterprise tool. One gateway. Universal protocol. No per-tool custom integrations.

Any MCP-compatible LLMCore GatewayFastAPI · MCP protocol · validationAuthentication layercredentials never shown to the LLMRate limiting & cachingRedisTool registrydeclarative YAML · Pydantic schemasEnterprise tools
Nexus: one gateway between any LLM and any tool
Core Gateway

A FastAPI-based server that will implement the MCP specification. It will receive tool requests from any MCP-compatible client, route them to the appropriate backend service, and return structured responses. The gateway will handle protocol negotiation, request validation, and response formatting.

Authentication Layer

Enterprise tools require authentication — API keys, OAuth tokens, service accounts. Nexus will manage credentials securely, injecting them at request time without exposing them to the LLM. Credentials will be stored encrypted in PostgreSQL with rotation support.

Rate Limiting & Caching

Redis-backed rate limiting will stop any single LLM session from overwhelming backend services. Caching tool responses will cut redundant API calls — when 10 agents ask for the same Jira ticket in 30 seconds, only one request hits the Jira API.

Tool Registry

New tools will be registered through a declarative YAML configuration. Define the tool's name, description, input schema (Pydantic models), authentication method, and backend endpoint. Nexus will generate the MCP-compatible tool definition automatically. The aim: adding a new enterprise tool should take minutes, not days.


Technical Decisions

Why FastAPI as the gateway runtime?
Async-first with automatic OpenAPI schema generation. MCP tool definitions map directly to FastAPI's Pydantic-based request/response models. The framework's dependency injection system cleanly handles per-request authentication context.
Why Docker for deployment?
Nexus needs to run in diverse enterprise environments — cloud, on-prem, hybrid. Docker provides the consistent runtime environment. Each tool backend can run as a sidecar container with its own dependency isolation.
Why Redis for rate limiting instead of in-memory?
Horizontal scalability. When Nexus runs behind a load balancer with multiple gateway instances, rate limits must be shared across all instances. Redis provides the distributed state layer.

What I Will Measure

Once Nexus is built, these are the numbers it has to earn before this page reports any:

  • Median gateway latency per tool call
  • Time to add a new tool, from YAML file to first successful call
  • Concurrent sessions held without errors
  • Calls stopped by rate limits and served from cache