Docker announces an MCP Catalog and Toolkit

Source record: MCP discovery and local tooling

On April 22, 2025, Docker announced the Docker MCP Catalog and MCP Toolkit. The announcement described a Docker Hub catalog with publisher verification, versioned releases, curated collections, and pull-based distribution for MCP tools. It described the toolkit as a local way to launch MCP servers, manage credentials and OAuth, expose enabled tools through a gateway server, and use a Docker MCP command-line interface. Docker also described memory, network, and disk isolation as part of its toolkit design. These are product and roadmap statements from Docker's launch article.

Engineering guidance: catalog entries need an adoption record

A catalog listing is the beginning of evaluation, not the end of it. Maintain an adoption record for every selected server: publisher identity, image reference and digest, declared tools, input and output schemas, required secrets, OAuth scopes, network destinations, persistent volumes, update owner, and retirement plan. Pin the image digest used in development and test environments, then review a new digest before it enters another environment. This record connects discovery to operational ownership and gives a reviewer a single place to inspect the technical surface introduced by a catalog choice.

Container distribution supports reproducible review

Container packaging makes the runtime artifact, declared dependencies, and execution settings easier to inspect together. Build a review process around the complete launch configuration: image digest, entrypoint, environment variables, filesystem mounts, user identity, resource limits, network policy, and exposed transport. Publisher verification and version labels provide useful provenance signals, while digest pinning identifies the exact bytes under review. Keep development fixtures separate from customer or production data, and require explicit approval for any configuration that adds a secret, writable mount, outbound destination, or state-changing tool.

Hypothetical implementation: a bounded developer tool set

Consider a hypothetical local development environment that exposes a documentation-search server and a read-only issue-query server to one coding client. The manifest pins both server images by digest, grants each only its required credential, and allows network access solely to the documented API host. The gateway enables a small named tool list and records every invocation with the client identity and server version. The coding client receives search results and issue metadata, while issue creation, source writes, and deployment operations are absent from the environment. This example demonstrates how catalog discovery can become a narrow, reproducible tool surface.

Credential management needs lifecycle controls

Store credentials outside images and source control, inject them only into the server that needs them, and make their scope visible in the adoption record. OAuth grants should identify the principal, scopes, expiration, revocation path, and server instance that receives the token. Rotate credentials through a documented procedure that verifies the replacement and removes the prior value. Prevent diagnostic output from printing secret values, authorization headers, or full unredacted tool arguments. Credential inventory, rotation evidence, and access-denial tests turn a local convenience feature into an accountable operating practice.

Validation before broader enablement

Test each adopted server with approved requests, denied requests, malformed input, unavailable dependencies, expired credentials, network-policy denial, and repeated calls. Confirm that the server image, tool manifest, and runtime logs match the reviewed configuration. Test client behavior when a tool returns untrusted text, oversized output, or an ambiguous failure. Record results alongside the selected image digest and catalog revision. A small starter set of tools with complete evidence is easier to operate than a broad catalog with unknown scopes, and it provides a durable template for evaluating the next server.

Catalog maintenance continues after adoption. Subscribe the named owner to upstream release notices, security advisories, image deprecations, and schema changes for the selected server. Establish a review cadence for the pinned digest and remove servers whose owner, purpose, credential, or test suite no longer exists. When a catalog entry adds a tool, compare its new capability list with the approved manifest before enabling it. Keep a local bill of materials for the server image and its transitive components when the environment requires supply-chain review. These practices keep catalog convenience aligned with an accountable change process.

Test removal as carefully as installation. Disable one adopted server in a fixture environment and verify that clients receive a clear unavailable result, dependent workflows stop cleanly, credentials are no longer injected, and audit history remains searchable. A clean removal path limits abandoned tools, stale permissions, and surprise dependencies in the local environment.

Related capabilities

• MCP integration and interoperability