Rebooting Enterprise AI with MCP and Kubernetes

Craig McLuckie, co-founder of Google Compute Engine and a co-creator of Kubernetes, now leads StackLock, which focuses on MCP and AI infrastructure on top of Kubernetes for enterprise use. His framing of MCP is architectural: the LLM acts as the presentation layer, existing databases and systems serve as the persistence tier, and MCP sits in between. He says seeing MCP gave him the same reaction as seeing Docker, recognizing it as a technology that simultaneously occupies two distinct spaces.

LLMs are well suited to natural language interaction and semantic extraction but poorly equipped to handle authentication and authorization with traditional APIs. Anthropic introduced MCP to describe the outside world in natural language terms backed by JSON schema, enabling LLMs to reason about available tools and invoke them deterministically. McLuckie describes MCP as a selectively permeable membrane around existing systems that allows value to flow in both directions while preserving controls, and as the gateway to enterprise value because it lets agents access systems on behalf of users with controlled rather than unfettered permissions. A recruiter workflow illustrates the model, where email, LinkedIn, a candidate management system, and a calendaring system are each described through MCP as discrete nouns and verbs, and the AI ties into identity providers such as Okta or Entra to handle authentication.

Most people currently experience MCP as tied to the developer's machine, with the desktop serving as the aggregation point for all connections. The next evolution is moving agent infrastructure to a centrally managed entry point. A centralized MCP platform stack has four components: a runtime, a registry, a gateway, and a control plane. The registry tracks which MCP servers are available and provides an approved list to the organization. The gateway exposes MCP servers to AI systems through a single endpoint. The control plane becomes necessary as organizations scale from one to hundreds or thousands of MCP servers. Running MCP servers locally via NPX is flagged as a security risk because it pulls packages from the internet that could be exploited.

For any real-world enterprise agentic platform, an LLM gateway and an MCP gateway are described as two required bookends. The LLM gateway directs traffic to a variety of models and enforces controls over which models can be accessed. The MCP gateway connects agents to real-world systems. Security and governance teams are currently blocking agentic AI from reaching production due to risks around agency, autonomy, prompt injection, and insecure tool usage.

On identity, McLuckie argues that a common but problematic practice is setting a single API key as an environment variable for an MCP server, which eliminates per-user identity and access control. Agent identity needs to be a three-legged stool consisting of a service account identity for the agent endpoint, role-based claims from the agent owner, and on-behalf-of claims inherited from the accessing user. He describes existing OIDC tokens as the only identity mechanism that currently works broadly across most organizations and predicts AI will be the forcing function that moves organizations toward zero-trust identity frameworks like SPIFFE. Token exchange should be used so that user credentials are not passed directly to downstream systems and claims are descoped to the minimum necessary for a task. He acknowledges that token exchange and credential mapping are fiddly and require a platform team willing to do the work on behalf of users.

Tool pollution is a significant practical problem. Pulling in three or four MCP servers can result in approximately 150 tools and burn 20,000 to 30,000 tokens per interaction just for tool descriptions. Using a proxy with find-tool and bulk-tool endpoints reduces input token consumption by 80 to 90 percent. Smaller LLMs are notoriously bad at tool invocation, and adding 20 to 30 tools makes correct tool calling unlikely, whereas replacing many tools with a single proxy endpoint providing fine-grained guidance can bring tool-calling accuracy back to 95 to 97 percent. Semantic ambiguity between tools, such as the word feature meaning different things in a GIS system versus a GitHub MCP server, can also confuse agents and degrade behavior.

MCP servers wrapped in Linux application containers become OCI images that enterprises already know how to harden, scan, and validate. The fetch server, described as probably one of the most commonly used MCP servers, illustrates a core security concern: running it behind a firewall without constraints could give an agent access to the totality of the internet. Containerization addresses this by enabling network endpoint and file system restrictions that scope a generic fetch server into a purpose-limited tool. ToolHive, an Apache 2.0 open source project with roots in the Kubernetes community, is seeing 50 percent month-over-month growth in Kubernetes usage of MCP server deployments and is receiving millions of tooling invocations from those deployments.

McLuckie's development team increased engineering throughput 60 percent in a single week by improving at systematic agent concurrency, running between 5 and 15 agents simultaneously with controlled tool access. He argues that knowledge workers cannot use the desktop as the aggregation point for agent orchestration and must instead be served by a platform team providing MCP services. He predicts the productivity gains seen on the development side will translate to every other knowledge worker function. Tracking agent behavior and defining what reconciliation looks like when bounding agent behavior remains an unsolved problem, with current approaches including human-in-the-loop evaluation, signal sampling on behavior patterns, and agents watching other agents.