Organizations adopting the Model Context Protocol (MCP) often face the challenge of curating, distributing, and managing AI tools across teams. To address this, we are excited to announce the general availability of Custom MCP Catalogs and MCP Profiles—two complementary features that transform how teams package, share, and control MCP servers.
Custom MCP Catalogs enable organizations to curate approved collections of MCP servers, providing a single source of truth for trusted AI tooling. MCP Profiles, on the other hand, allow individual developers to define portable, named groupings of MCP servers, making it easier to build, run, and share configurations across projects and teams.
In this guide, we will walk through creating a custom catalog—improving on our previous approach—and introduce Profiles as a new primitive designed to solve practical use cases today while laying groundwork for future expansion.
Why Custom Catalogs Matter for Enterprises
As MCP adoption grows within organizations, a recurring need emerges: teams require a way to curate a trusted list of MCP servers, including internally developed ones. Without a centralized approach, team members may waste time searching for servers across the open internet or risk using unvetted tools.
Custom Catalogs solve this by allowing organizations to publish and distribute curated collections of approved MCP servers. Developers can then discover and use these trusted servers within organizational boundaries, ensuring consistency, security, and governance.
These catalogs can reference servers from Docker’s MCP Catalog, community sources, and custom in-house MCP servers, combining flexibility with control and trust in a single experience. Below, we demonstrate how to build and share a custom catalog using Docker.
Building and Sharing a Custom MCP Catalog
In this example, we will create a custom catalog that includes servers from the Docker MCP Catalog along with a self-built MCP server. All functionality shown can be executed via the CLI, while user-centric features are also accessible through Docker Desktop.
Note: Replace the Docker Hub ID roberthouse224 with your own credentials where appropriate (e.g., when pushing images).
Step 1: Create a Custom MCP Server and Push It to Docker Hub
We built a reference server called roll-dice (available on GitHub). This is a standard MCP server that communicates over stdio and is packaged as a Docker image. The image is already built and pushed to Docker Hub.
To describe the server, we create a YAML metadata file named mcp-dice.yaml:
name: roll-dice
title: Roll Dice
type: server
image: roberthouse224/mcp-dice@latest
description: An MCP server that can roll dice
Step 2: Create a Catalog Blending External and Internal Servers
Now we can compose a custom catalog that includes servers from the Docker MCP Catalog alongside our own server. This allows teams to easily adopt both curated external tools and proprietary internal tools in one unified list.
To create the catalog, we define a manifest that references the mcp-dice.yaml metadata and selects servers from the public catalog. The catalog definition can be stored as a file (e.g., my-catalog.yaml) and then imported into Docker Desktop for team distribution.
For example, a catalog manifest might look like this:
catalog:
name: My Enterprise MCP Catalog
servers:
- from: mcp-dice.yaml
- from: docker://mcp/mcp-filesystem
- from: docker://mcp/mcp-slack
After creating the catalog file, use the CLI command:
mcp catalog import --file my-catalog.yaml
This imports the catalog into Docker Desktop, making the approved servers discoverable to all team members.
Introducing MCP Profiles: Portable, Named Server Groupings
While catalogs solve the curation problem at an organizational level, individual developers often need to define their own reusable sets of MCP servers for specific projects or tasks. This is where MCP Profiles come in.
A Profile is a portable, named grouping of MCP servers that can be easily shared and reused across projects and teams. Profiles allow developers to define their toolset once and then apply it everywhere, reducing configuration overhead and ensuring consistency.
For example, a developer might have a profile called frontend-dev that includes servers for code analysis, documentation lookup, and design feedback. They can share this profile with teammates through version control or a central repository, streamlining onboarding and collaboration.
How Profiles Complement Catalogs
Catalogs provide the what—the approved pool of servers. Profiles provide the how—the specific combinations and configurations that individuals or teams need. Together, they offer a complete workflow:
- Catalog: Central governance and trust
- Profile: Flexibility and personalization
This separation of concerns allows enterprises to enforce policies without stifling developer productivity.
Getting Started with Custom Catalogs and Profiles
Ready to implement these features in your organization? Here’s a quick roadmap:
- Define your trusted servers: Decide which external and internal MCP servers should be in the approved catalog.
- Create a custom catalog: Use the CLI to build a YAML manifest referencing those servers.
- Import the catalog: Distribute the catalog via Docker Desktop so all team members can discover and use the approved servers.
- Encourage Profile usage: Let developers create and share Profiles for common workflows, promoting reuse and best practices.
For detailed command-line instructions, refer to the official documentation.
Future Outlook
Custom Catalogs and Profiles are just the beginning. We are actively working on extending these primitives to support versioning, access controls, and integration with enterprise identity systems. Our goal is to provide a scalable and secure foundation for AI tooling management in organizations of any size.
We invite you to try both features today and share your feedback. Your input will help shape the next generation of MCP management.