Skip to main content
Hello — welcome to this section. Quick recap: earlier we validated the MCP read path end-to-end using curl. That flow covered the health check, handshake, and subsequent interactions with the MCP server. At that time the setup had two moving parts: a Kubernetes MCP server running inside Docker, and a Supergateway that translated the server’s stdio-based protocol into HTTP so curl could reach it.
A dark-themed diagram titled "The Setup Had Two Moving Parts" showing a flow from curl to a SuperGateway to an MCP Server inside Docker, with arrows labeled HTTP and stdio. A turquoise badge reading "Two moving parts" highlights the SuperGateway box.
That demonstration showed the full read path but introduced an extra translation layer. The question going forward: do we still need the Supergateway? A typical curl call we used looked like this:
Both approaches — running the MCP through a Supergateway or exposing the MCP over HTTP directly — surface the same MCP protocol and the same tool names. For example, common kubectl-style tools such as kubectl and describe are available in both setups.
A dark presentation slide titled "Both Paths Expose the Same Thing" showing two blue boxes joined by an equals sign: left "With Gateway: curl → HTTP" and right "Standalone: MCP over HTTP." A caption below reads "Same protocol, same tool names."
Below is a concise comparison to help decide which path to choose when building the agent:
When building a long-lived agent that talks to MCP, running a standalone MCP service inside Docker and connecting the agent directly is cleaner and removes the translation layer. Both approaches expose the same protocol and tool set, so you won’t lose functionality by removing the Supergateway.
Because the next step is to create a full-fledged agent that connects directly to the MCP service, we will remove the Supergateway translation layer. Instead, we’ll run the MCP Kubernetes service in Docker and have the agent talk straight to it over HTTP.
A dark blue slide titled "The Agent Connects Directly" showing a rounded blue card with a robot icon labeled "Our Agent" and the subtitle "Talks straight to it," with a short connecting line extending to the right.
Next steps
  • Start the standalone MCP service in Docker.
  • Validate the MCP endpoints (health, handshake, tools) using curl or an HTTP client.
  • Connect the agent directly to the MCP service and verify tool invocation (for example, tools/list and kubectl-style commands).
References
  • Kubernetes Basics
  • Docker Hub
  • For MCP-specific details, follow your MCP project’s README or internal spec to ensure the HTTP endpoints, health checks, and handshake semantics match the agent’s expectations.
That’s all for this section — see you in the next step where we run and validate the standalone MCP service.

Watch Video