AI agents deserve a direct connection.
NDP is a local-first alternative to MCP gateways. Agents discover and connect to MCP servers directly on your LAN without routing through a central proxy.
The Gateway Approach
Gateways centralize everything in one place.
MCP gateways, whether cloud or on-prem, centralize routing, auth, and credentials. That is a valid architecture. But it is not the only one. NDP offers a decentralized alternative.
All traffic funnels through one box.
Centralized routing
All traffic flows through the gateway. Good for visibility and policy enforcement. Adds a dependency and an extra network hop.
Centralized credentials
The gateway manages auth for all servers. Simplifies management but concentrates trust in one place.
Configuration overhead
Developers need gateway URLs, tokens, and matching configs. Changes require gateway redeployment.
The Direct Approach
Discover servers. Connect directly.
NDP lets each agent discover and connect to MCP servers on the LAN without routing through a gateway. Each server controls its own auth and permissions. Connections are independent.
Each agent connects directly to each server.
No single point of failure
Each connection is independent. One server going down only affects its own tools.
Distributed auth
Each server can manage its own credentials, allow lists, and per-tool permissions independently.
Direct connection
No intermediate hop. Agent connects straight to the MCP server on LAN.
How It Works
Four steps. Zero config.
Servers broadcast. Agents discover. Auth happens per-connection. Tool calls flow directly using standard MCP JSON-RPC 2.0. NDP handles discovery and auth. The MCP calls are unchanged.
Broadcast
MCP servers broadcast a JSON manifest every 10 seconds via UDP. No registration needed.
{ agentId: "math-server", tools: ["add", "multiply"] }Discover
Agents listen for broadcasts and build a live map of all available servers and tools on the LAN.
Mesh Status: 2 servers, 6 toolsAuthenticate
Each connection uses its own HMAC-SHA256 challenge-response. No shared credential store.
HMAC(nonce, secret) -> verifiedCall Tools
Standard MCP JSON-RPC 2.0 over a direct connection. tools/list, tools/call, just like a gateway, but faster.
tools/call "add" { a: 15, b: 27 } -> 42Security
Distributed trust by default.
Gateways centralize auth and access control. NDP distributes it. Each server independently manages who can connect, which tools are available, and what permissions each agent has.
Gateway Approach
Best for: centralized policy enforcement, multi-network routing, compliance-driven environments, cloud or on-prem.
NDP Approach
Best for: local development, LAN environments, on-prem setups, teams that want zero-config discovery without infrastructure.
Access control without a central authority
Gateways handle permissions centrally. NDP takes a different approach. Each server enforces its own access rules, with the same level of control distributed across the servers that own the tools.
Server-side allow lists
Each MCP server maintains its own list of approved agent IDs. The server decides who can call its tools, not a central authority.
Tool-level permissions
A server can expose "read" to everyone but restrict "write" or "delete" to specific agents. Per-tool granularity, enforced at the source.
Capability tokens
Instead of one shared secret, each agent gets a scoped token. Servers verify independently.
Manifest trust filtering
The caller mesh can be configured to only connect to servers signed by a trusted key. Rogue servers on the LAN get ignored.
Two approaches compared
| Capability | Gateway | NDP |
|---|---|---|
| Read/write restrictions | Central ACL on gateway | Each server enforces its own |
| Per-tool access | Gateway routes and filters | Server exposes only what it allows |
| Agent allow/deny | Gateway-level allow list | Per-server allow list |
| Revoke access | Update gateway config (affects all) | Update that one server only |
| Audit log | Centralized (correlatable) | Distributed per-agent logs |
| Breach impact | Depends on secret management | Contained to one server |
The Proof
Real output. Real resilience.
This is actual output from the NDP prototype. Two servers discovered, tools called across both, one server killed. The rest keeps working.
How It Connects
From MCP server to AI agent. Automatically.
NDP sits between your MCP servers and the agents that call them. Servers broadcast what they offer. Agents discover and connect. No URLs to hardcode. No config files to sync.
One-Command Install
Run install.ps1 and NDP configures Claude Code, Claude Desktop, Cursor, VS Code, and Windsurf automatically. All five tools, one command.
NDP Discovery
The server broadcasts its manifest via UDP or mDNS. Every 10 seconds, it announces: here I am, here are my tools.
AI Agent Connects
The agent discovers the server, authenticates, and calls tools using standard MCP protocol. No gateway in between.
One command.
Five tools configured.
Working in 60 seconds.
git clone https://github.com/eddyficial/ndp.git && cd ndp && .\install.ps1The installer configures Claude Code, Claude Desktop, Cursor, VS Code, and Windsurf. It installs dependencies, creates a startup task, and gets NDP running across all your AI tools.