Enable Programmatic Access to Gordon via Docker MCP Gateway

[Eliosinstitute]

Formal Request for Architectural Extension

Summary of Research and Architecture

Docker has positioned itself at the vanguard of the agentic engineering revolution. Through the deployment of the declarative docker-agent runtime, the implementation of kernel-isolated microVM Docker Sandboxes, and the integration of the Model Context Protocol (MCP) Gateway, Docker provides a robust, enterprise-grade infrastructure for deploying and governing AI tools. Concurrently, Docker has developed Gordon, a highly specialized, context-aware AI assistant capable of interacting with the local Docker daemon, analyzing container states, and querying a proprietary RAG-backed knowledge base to solve intricate deployment challenges.

Explicit Identification of the Technical Gap

Despite possessing deep, foundational integrations with the MCP ecosystem, a critical asymmetrical limitation exists in Gordon's architecture. Gordon currently operates exclusively as an MCP client—consuming external tools—and is restricted to human-in-the-loop interfaces (the Docker Desktop GUI and the CLI TUI). While the underlying docker-agent framework natively supports serving custom agents as programmatic MCP endpoints via the docker agent serve mcp command, the proprietary Gordon artifact itself is closed to programmatic access.

This architectural silo creates a severe bottleneck in multi-agent automated workflows. External, autonomous AI coding agents (such as Cursor, Claude Desktop, or custom CI/CD swarms) cannot query Gordon to obtain domain-specific insights, container log diagnostics, or verified Docker documentation. Consequently, generalist agents frequently hallucinate infrastructure configurations or fail to debug local deployment issues due to a lack of real-time environmental context. Furthermore, the reliance on a conversational interface leaves Gordon vulnerable to "capability leaks," where probabilistic prompt manipulation can force the agent outside its intended domain.

Proposed Solution and Implementation Mechanism

To resolve this gap, Docker must expose Gordon's contextual awareness and proprietary knowledge base as a formalized MCP server endpoint, seamlessly integrated into the Docker MCP Toolkit.

The gap must be filled by:

1. Creating a Containerized MCP Server (mcp/gordon-server): Developing an official, OCI-packaged MCP server that acts as a secure, programmatic proxy bridging external MCP clients to the Gordon cloud backend and the local Docker daemon.

2. Defining a Strongly Typed, Read-Only Tool Schema: Exposing highly specific, strictly typed JSON-RPC tools rather than conversational endpoints. Capabilities must be limited to read-only contextual retrieval (e.g., gordon.query_docs, gordon.analyze_file, gordon.inspect_state, gordon.diagnose_logs) to maintain absolute security boundaries. State-changing actions (such as shell command execution) must remain strictly outside this programmatic interface to prevent remote code execution and Meta-Context Injection vulnerabilities.

3. Implementing Identity and Governance Routing: Leveraging the Docker MCP Gateway to handle session authentication. The Gateway must inject scoped authentication tokens linked to the user's Docker Desktop identity to enforce subscription tier usage limits and ensure compliance with organizational policies established within the Docker AI Governance control plane.

4. Enforcing Domain Boundaries: Utilizing the structured, strictly typed nature of the MCP interface as a definitive "gatekeeper." By forcing external agents to call specific tools with predefined arguments, Docker entirely eliminates the capability leaks associated with probabilistic, unstructured conversational prompts.

By implementing this architectural extension, Docker will transform Gordon from a standalone human assistant into a foundational infrastructure intelligence layer, enabling the next generation of fully autonomous, secure, and context-aware software development swarms.