Discussion: Dynamic MCP Discovery, Agent Execution Loops, and Gateway Design

Overview

Hi everyone 👋

I’m building docker-mcp-bridge — a middleware service that extends the MCP Gateway with runtime tool discovery, routing, and scoped execution.
Reference implementation: https://github.com/Sagnnik/docker-mcp-bridge
(Current working prototype for the ideas discussed below)

I was encouraged to open this thread here to discuss dynamic MCP discovery, agent execution loops, and registry standardization

This project serves as:

• a FastAPI-based LLM integration service,
• a dynamic tool discovery engine that parses MCP tool definitions at runtime,
• and a bridge that lets clients (OpenAI, Anthropic, Google, Ollama, OpenRouter, etc.) use MCP tools without static embedding.

See the README for details:
https://github.com/Sagnnik/docker-mcp-bridge/blob/main/README.md

Purpose of This Discussion

1. Core design & abstractions

   • Is the gateway + registry the right way to approach dynamic MCP tool discovery and execution?
   • Are there existing MCP patterns or conventions we should align with?
   • What is the recommended architecture for implementing an MCP-native agent loop?

2. Standardization of dynamic MCP catalog

   • How to best integrate or augment the official Docker MCP catalog?

3. Security, permissions & scopes

   • Best practices for isolating and restricting MCP tool execution safely.

4. Execution model, isolation & automation primitives

   • How user-level MCP isolation should be modeled (per-user / per-agent scoping, session boundaries).
   • What the recommended MCP-native agent execution loop should look like, and what parts (if any) should be gateway-owned.
   • Whether MCP secrets and credentials should support API-level programmatic management in addition to the current CLI workflow.
   • What observability primitives should exist for sandboxed MCP tool execution in multi-tenant environments.

5. Future roadmap

   • Where this project could evolve in the context of Docker’s MCP ecosystem

Current Architecture (Short Recap)

• FastAPI backend — orchestrates MCP calls.
• Dynamic tool catalog — ingests MCP server tools.json and normalizes them against the official Docker MCP catalog (YAML) as the ground-truth schema before routing and execution.
• MCP Gateway client — routes and proxies requests to appropriate MCP servers.
• Supports multiple providers — OpenAI, OpenRouter, (will add) Anthropic, Ollama, Google.
• Container-isolated tool execution — reduces context bloat & increases safety.

(See README for more detailed architecture and examples.)

Feedback Requested

I’d love input on:

✅ What minimal standard fields, schemas, and lifecycle hooks should be considered mandatory for MCP servers (e.g., tool schema versioning, capability negotiation, permission scopes, health / heartbeat, etc.) to make dynamic discovery reliable.

✅ What security boundaries should be considered mandatory for MCP gateways:

• execution sandboxing models,
• permission / capability scopes,
• audit logging & traceability,
• and safe tool exposure to LLM clients.

✅ Any architectural pitfalls, edge cases, or alternative designs that should be considered early.

✅ Anything else the maintainers feel is important for community adoption.

This is a broad design discussion with no target file, test, or concrete change named. Start with the linked docker-mcp-bridge README and compare its FastAPI, catalog, gateway, and isolation model with the current repository. Done would require an agreed scope and architecture before implementation work can be defined.