Jim Clark

Jim Clark is a co-founder of Atomist whose work spans developer automation, software supply-chain security, and infrastructure for AI agents. A principal software engineer at Docker at the time of his 2026 AI Engineer World’s Fair talk, he has written extensively about the Docker MCP Gateway and the practical problem it addresses: giving agents useful access to external systems while controlling which tools they can use and how those tools execute.

From developer automation to agent infrastructure

At Atomist, Clark explored how automation could fit into software teams’ daily work. His 2018 presentation on developer-team bots emphasized delivering information when developers could act on it, making messages actionable, and spreading useful practices across groups. The concern was as much about how people used automation as about what a bot could do.

Docker acquired Atomist in June 2022, bringing its developer-productivity and software supply-chain capabilities into Docker. Clark’s early Docker work included layered software bills of materials: understanding which packages came from which container-image layers, how rebuilding an image changed its contents, and where security fixes were available. Examining software at the layer level made dependencies inherited from base images easier to distinguish from those introduced elsewhere in an image.

As language models gained tool-calling capabilities, Clark and his colleagues began packaging tools in containers. In December 2024, he co-authored an introduction to containerized MCP servers with Anthropic’s David Soria Parra. Containers addressed a mundane but consequential obstacle: installing the same tool reliably across machines, operating systems, and development environments.

That packaging approach developed into infrastructure for selecting, running, and governing tools. The Docker MCP Gateway, introduced as an open-source project in July 2025, aggregates MCP servers behind one connection and lets developers choose which capabilities a client can reach. It provides a common point of control between an agent and the tools available to it.

Making autonomy manageable

Clark’s writing develops several complementary approaches to making agent behavior inspectable and controllable:

• Scoped tools and credentials: In his explanation of the Toolkit and Gateway, each client receives a deliberate subset of tools, prompts, and resources. Credentials go to the specific server that needs them, while the gateway handles connections and remote authorization. Versioning these configurations alongside application code makes a team’s access choices repeatable.

• Dynamic tool discovery: Loading an entire tool catalog into every model request consumes context even when most tools are irrelevant. Clark’s dynamic MCP approach lets agents search for servers and select capabilities as needed. Its code-mode mechanism allows an agent to compose several tool operations in JavaScript inside a container sandbox, reducing the tool descriptions and intermediate results that must pass through the model while keeping external permissions at the MCP layer.

• Reliable tool execution: Clark distinguishes the agent’s planning, evaluation, and recovery loop from the tools that execute its decisions. His MCP design guidance calls for validating model-generated inputs, declaring success conditions, controlling side effects, and recording enough of the sequence to replay failures. Prompts and resources also need versions, tests, and explicit permissions; they shape behavior alongside executable tools.

• Reusable organizational knowledge: Clark’s vision for private MCP catalogs goes beyond maintaining an approved server list. He proposes packaging catalogs and workflow profiles as versioned OCI artifacts, using the distribution model familiar from container infrastructure. Teams could pin known configurations, adapt useful combinations of tools, and share what worked. Richer discovery and accumulated workflow knowledge remain a direction for development rather than a claim that the entire system already exists.

Safety follows the task’s intent

In “How Many Credentials Should Your AI Agent Have? Zero.”, Clark argues that safety depends on the context and tools available to an agent, making the sandbox a central unit of control. As agents run longer without supervision, their permissions need to reflect the task they are performing. Separating research, fact-checking, and publishing into distinct sandboxes illustrates the principle: access to untrusted material should not automatically come with the power to publish. Likewise, a coding agent should receive access to signing capabilities only when the task requires a commit.

A single MCP gateway endpoint per sandbox gives developers a control point while allowing them to change agent harnesses. Clark’s call for zero credentials in the sandbox complements server-specific credential handling: the agent can use authorized capabilities without holding the underlying credentials in its execution environment. He presents Cross App Access with Okta as a way to connect agent identity and authorization grants to existing single sign-on.

His guidance for AI prototypes applies similar discipline to experimentation. He advocates small, inspectable workloads, local iteration with deliberate use of remote compute, measurable user benefit, and clear operational ownership. Logging, cost controls, and repeatable evaluation belong at the beginning, so teams can understand and improve the system after the demonstration ends.