The Dependency Problem: Agent Skills and MCP Servers
Agent skills reference MCP server tool names in skill.md files, creating an implicit dependency. If the server interface or configuration changes, evals break. Bobby House wanted a single addressable dependency: one package, immutable via SHA, configurable by both skill author and user, and decoupled from the server’s execution environment. Existing approaches like MCP JSON define execution, not dependencies. The MCP registry’s server.json schema is close but cannot separate author vs user configuration.
Why OCI Artifacts Solve the Pin and Config Problem
House looked at OCI artifacts as the packaging format. OCI registries already exist (DockerHub). An artifact bundles a name, a list of MCP servers, author-defined configuration, and blank fields for user configuration. The artifact is pushed to a registry and referenced by its SHA digest. This guarantees no drift between server versions. The skill author pins the SHA in the skill, so the agent always loads the exact same dependency. The approach reuses existing infrastructure without new tooling.
Demo: Building and Running a Skill with OCI Dependencies
House built a skill builder that resolves MCP servers from the registry, finds the floating tag, resolves it to a SHA, and packages everything into an OCI artifact pushed to DockerHub. The skill runner (a daily quote skill using Gutenberg and logging servers) loads the artifact, checks the MCP JSON, pulls the artifact, prompts the user for configuration (e.g., Gutenberg base URL), writes the MCP JSON, and requires a Claude restart to activate the servers. The demo showed the full flow.
The Gateway Pattern: Cleaner Lifecycle Management
The restart requirement and persistent MCP servers after skill completion are drawbacks. House’s preferred pattern uses a thin MCP gateway connected to the client. The gateway knows how to load OCI artifacts, spin up each server in a Docker container, and proxy communication. When the session ends, the servers disappear. No MCP JSON modification needed. The gateway provides deterministic dependency resolution and lifecycle management. Docker’s MCP gateway is open source and implements this pattern.
Q&A
As a maintainer, how do downstream users pull updates when the agent skill or MCP server changes? House said the OCI artifact’s SHA changes, so users can pull the new dependency, but broadcasting updates is not yet solved; the gateway could check for newer versions. ▶ Watch (18:48)
Do agent skills provide MCP servers, or do MCP servers provide agent skills? House noted the tension and said enterprise customers want predictable results, which is why he leans on pinning SHAs to avoid drift. ▶ Watch (21:17)
Notable Quotes
I want a single addressable dependency. Bobby House · ▶ Watch (3:27)
I want a Shaw. So it guarantees if like anything within that dependency changes, then then the Shaw changes. Bobby House · ▶ Watch (3:49)
It’s weird to have to restart cloud code to then be able to use the servers. Bobby House · ▶ Watch (13:28)
me as an agent skill author, I should be able to take a snapshot of that in time, do my eval, and really tailor that experience to that MCP server and then know that I can reliably run that over and over again. Bobby House · ▶ Watch (16:54)
Key Takeaways
- Package MCP servers and config as OCI artifacts pinned by SHA for immutable dependencies.
- Use a gateway to load artifacts, spin up containers, and avoid persisting servers after the session.
- The pattern enables predictable, reproducible agent skill execution across environments.
About the Speaker(s)
Bobby House is a senior software engineer at Docker that enjoys building products for engineers. His recent work centers on integrating MCP into enterprise environments by enabling organizations to publish and manage private catalogs of MCP servers as OCI artifacts.