AI agents deserve a direct connection.
TDP 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. TDP 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.
TDP 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. TDP 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. TDP 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.
TDP 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. TDP 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.
Closing the shell bypass gap
A common flaw in MCP permission models: you restrict a tool to read-only, but the agent uses PowerShell to run the same write operation directly. The gateway never sees it. TDP includes a command filter that monitors shell commands and blocks operations that violate the security profile.
read-only
SQL reads allowed, writes blocked. GET requests allowed, POST/PUT/DELETE blocked via shell.
no-network
Blocks all network access via shell: curl, wget, ssh, Invoke-RestMethod. MCP tools still work.
strict
Blocks writes, network, and destructive operations. Only safe read commands allowed via shell.
Example: Agent has read-only MCP access to your database. It tries sqlcmd -Q "DELETE FROM users" via PowerShell. TDP blocks it. It tries curl -X POST to your API. Blocked. It runs sqlcmd -Q "SELECT * FROM users". Allowed. Rules are customizable in security/rules.json.
Two approaches compared
| Capability | Gateway | TDP |
|---|---|---|
| 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 |
| Shell bypass | Not addressed at gateway level | Built-in command filter with security profiles |
The Proof
Real output. Real resilience.
This is actual output from the TDP prototype. Two servers discovered, tools called across both, one server killed. The rest keeps working.
The Difference
MCP is getting easier. TDP takes it further.
MCP has come a long way. You can serve MCP over HTTP, add a server to VS Code with Ctrl+Shift+P, and get up and running fast. But once you have 5, 10, or 20 servers across multiple IDEs, you need a layer that manages, monitors, and secures all of them. That is what TDP adds.
MCP Today
Great foundation, getting better fast
- +HTTP transport makes serving MCP servers simple
- +VS Code, Cursor, and others have quick-add flows
- +Growing ecosystem of community servers
- -Each IDE configured separately -- add to one, repeat for others
- -No unified view of which servers are healthy across tools
- -No built-in shell bypass protection
- -Security is per-server, per-IDE, managed manually
MCP + TDP
Management, monitoring, and security on top
- +One install configures Claude Code, Cursor, VS Code, Claude Desktop, and Windsurf at once
- +System tray icon shows server health at a glance -- green, yellow, or red
- +Right-click to start, stop, restart servers, or switch security profiles
- +Drop a file in a folder to add new tools -- auto-discovered in 15 seconds, no config changes
- +Four security profiles (read-write, read-only, no-network, strict) switchable with one click
- +Shell bypass protection blocks destructive commands that skip MCP permissions
- +Auto-restarts dead servers, starts everything on boot
TDP does not replace MCP. It sits on top of it. Your MCP servers keep working exactly the same way. TDP adds the management, monitoring, and security layer that makes MCP safe enough to hand to someone who has never opened a terminal.
How It Connects
From MCP server to AI agent. Automatically.
TDP 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 once. It configures all five AI tools, installs dependencies, and starts the server manager. 5 demo servers with 20 tools launch automatically in the background.
Drop In New Servers
Write a *_server.py script and drop it in the servers/ folder. The bridge re-scans every 15 seconds and picks up new servers automatically. No restarts needed.
AI Agent Connects
The bridge uses fresh connections per tool call with no stale connections. Your AI tools discover and call tools using standard MCP protocol. No gateway in between.
One command.
Five tools configured.
Working in 60 seconds.
git clone https://github.com/eddyficial/tdp.git && cd tdp && .\install.ps1The installer configures Claude Code, Claude Desktop, Cursor, VS Code, and Windsurf. It installs dependencies, creates a startup task, and gets TDP running across all your AI tools.