{"id":4073,"date":"2026-05-15T13:15:59","date_gmt":"2026-05-15T13:15:59","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/05\/15\/custom-mcp-catalogs-and-profiles-advancing-enterprise-mcp-adoption\/"},"modified":"2026-05-15T13:15:59","modified_gmt":"2026-05-15T13:15:59","slug":"custom-mcp-catalogs-and-profiles-advancing-enterprise-mcp-adoption","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/05\/15\/custom-mcp-catalogs-and-profiles-advancing-enterprise-mcp-adoption\/","title":{"rendered":"Custom MCP Catalogs and Profiles: Advancing Enterprise MCP Adoption"},"content":{"rendered":"

We\u2019re excited to announce the general availability of Custom Catalogs and Profiles for managing Model Context Protocol (MCP) servers. These two complementary capabilities fundamentally change how teams package, distribute, and manage AI tooling.\u00a0<\/p>\n

Custom MCP Catalogs let organizations curate and distribute approved collections of MCP servers. MCP Profiles enable individual developers to easily build, run, and share their MCP tools and configurations across projects and teams.<\/p>\n

In this post, we\u2019ll walk through how to create your own custom catalog \u2013 building on and improving our previous approach<\/a>. We\u2019ll also introduce Profiles<\/strong>, a new primitive that lets you define portable, named groupings of MCP servers. Profiles are designed to solve several practical use cases today, while giving us a foundation to expand in the future.<\/p>\n

Creating custom catalogs with Docker<\/h2>\n

As organizations adopt MCP, we consistently hear the same need: teams need a way to curate a trusted list of MCP servers, including internally built servers.<\/p>\n

To address these needs, we built Custom Catalogs<\/strong>. Instead of every team member searching for MCP servers across the open internet, organizations can publish and distribute catalogs that define approved servers. This allows developers to centrally discover and use trusted MCP servers within organizational boundaries.<\/p>\n

Custom Catalogs can reference servers from Docker\u2019s MCP Catalog, community sources, and custom MCP servers developed internally, bringing flexibility, control, and trust together in a single experience. We will show you how to do that with a Custom Catalog.\u00a0<\/p>\n

Step-by-step: Building and sharing a custom MCP catalog\u00a0<\/h2>\n

In this example, we will create a Custom Catalog containing servers from the Docker MCP Catalog and an MCP server we created ourselves from the CLI. Then we will show you how to use Docker Desktop to import the catalog.<\/p>\n

All the functionality we will show can be exercised through the CLI, while a subset of primarily user-centric features can be exercised through Docker Desktop.<\/p>\n

Here, we will use my personal Docker Hub ID roberthouse224<\/code> in the commands, but you should adapt to use your information where appropriate (e.g. pushing an image).<\/p>\n

Step 1: Creating my custom MCP server and pushing it to Docker Hub<\/h3>\n

We built a reference server called roll-dice (GitHub Repository<\/a>). It is a regular MCP server that communicates over stdio and can be built as a Docker image. The image has already been built and pushed to Docker Hub<\/a>.<\/p>\n

We can create the metadata that describes the server including where the image can be found and save it to a file named mcp-dice.yaml to be used when creating our catalog.<\/p>\n

\n
\nname: roll-dice\ntitle: Roll Dice\ntype: server\nimage: roberthouse224\/mcp-dice@latest\ndescription: An mcp server that can roll dice\n<\/pre>\n<\/div>\n
Step 2: Creating a catalog that includes servers from the Docker MCP Catalog alongside a server you have built yourself<\/h3>\n
Now we can create a custom catalog containing servers from the Docker MCP Catalog and the MCP server we created ourselves.<\/p>\n
\n
\ndocker mcp catalog create roberthouse224\/our-catalog \n--title \"Our Catalog\" \n--server catalog:\/\/mcp\/docker-mcp-catalog\/playwright \n--server catalog:\/\/mcp\/docker-mcp-catalog\/github-official \n--server catalog:\/\/mcp\/docker-mcp-catalog\/context7 \n--server catalog:\/\/mcp\/docker-mcp-catalog\/atlassian \n--server catalog:\/\/mcp\/docker-mcp-catalog\/notion \n--server catalog:\/\/mcp\/docker-mcp-catalog\/markitdown \n--server file:\/\/.\/mcp-dice.yaml\n<\/pre>\n<\/div>\n
Step 3: Verifying the MCP servers in the custom catalog\u00a0<\/h3>\n
We can now list our catalogs and see the catalog that we created
docker mcp catalog list<\/code><\/p>\n
We can also inspect the contents of the catalog
docker mcp catalog show roberthouse224\/our-catalog --format yaml<\/code><\/p>\n
Step 4: Share the catalog<\/h4>\n
At the moment our custom catalog only lives on our machine. But what we have \u2013 and this is really powerful \u2013 is an immutable OCI artifact containing our trusted MCP servers that can be easily shared.<\/p>\n
We can push our catalog to a container registry, in this example we\u2019re using Docker Hub. Now, anyone that has access to your organization\u2019s namespace can access the catalog.<\/p>\n
docker mcp catalog push roberthouse224\/our-catalog<\/code><\/p>\n
Using a custom MCP catalog<\/h2>\n
Now that our custom catalog has been shared, colleagues can import it from within Docker Desktop (or from the cli using docker mcp catalog pull<\/code>).<\/p>\n
Import the catalog from Docker Desktop by selecting \u201cImport catalog,\u201d and then specifying the OCI reference in the dialog.<\/p>\n
\n                \"image5\"\n        <\/div>\n
Figure 1: Importing a custom catalog from OCI reference<\/strong><\/p>\n
The catalog is now browsable. You can double click into the catalog and see all of the servers contained within it. Notice the custom MCP server that we added named \u201cRoll Dice.\u201d<\/p>\n
\n                \"image7\"\n        <\/div>\n
Figure 2: A custom MCP catalog within the Docker Desktop app, including a newly added \u201cRoll Dice\u201d server.<\/strong><\/p>\n
To make this a private<\/em> catalog all you need to do is manage access to the repository<\/a> the way you always have for container images \u2013 no new infrastructure to manage or systems to learn.<\/p>\n
This is exactly what Jim Clark was describing in his post Private MCP Catalogs and the Path to Composable Enterprise AI<\/a>.<\/p>\n
This simple pattern can be extended to support more complex use cases. For example, you might use a private container registry instead of Docker Hub, or connect to a remote MCP server over streamable HTTP you host yourself rather than running a containerized server as shown in the example.<\/p>\n
Now that we have a shareable custom catalog of trusted MCP servers we can shift focus to how individuals can effectively leverage MCP servers from the catalog we built in their workflows.<\/p>\n
Using Profiles to create and share MCP Workflows<\/h2>\n
With MCP Profiles, developers can organize workflows efficiently and maintain separate server collections and configurations for different use cases. Profiles can be shared across teams, enabling collaboration on server setups and ensuring consistent configurations for teams working within the same projects or contexts.<\/p>\n
Switch between Profiles<\/h3>\n
At a basic level, a Profile is a named grouping of MCP servers that can be connected to an agent session. This makes it straightforward to define different Profiles for different ways of working.<\/p>\n
Now let\u2019s see an example in action.\u00a0<\/p>\n
We create a profile named coding <\/em>and another named planning<\/em>. We browse our custom catalog, select the MCP servers that we want (e.g. Playwright, GitHub, and Context7) then select the \u201cAdd to\u201d drop down, and select \u201cNew profile\u201d.<\/p>\n
\n                \"image3\"\n        <\/div>\n
Figure 3: Selecting MCP servers to be added to a new profile<\/strong><\/p>\n
Give the profile a name, select the client you want to connect to, and select \u201cCreate\u201d.<\/p>\n
\n                \"image6\"\n        <\/div>\n
Figure 4: Creating a new MCP profile named coding in Docker Desktop.<\/strong><\/p>\n
From the Profiles tab, we can see the profile we just created. Our client is connected and our tools are ready to use.\u00a0<\/p>\n
\n                \"image4\"\n        <\/div>\n
Figure 5: Example of a profile that is connected to a client.<\/strong><\/p>\n
Next we create a profile named planning<\/em> with servers relevant to planning (e.g. Atlassian, Markitdown, Notion).\u00a0<\/p>\n
Navigate back to \u201cour-catalog\u201d (if not already there), select the servers relevant to planning, and select \u201cAdd to\u201d -> \u201cNew profile.\u201d Give the profile a name (e.g. planning). Then select \u201cCreate\u201d to create the planning profile without a client. Specifying the client is optional.<\/p>\n
\n                \"image8\"\n        <\/div>\n
Figure 6: Example of creating multiple profiles, including separate profiles for coding and planning\u00a0<\/strong><\/p>\n
Now we have two profiles that mirror two modes of working. When we switch to planning mode we only want the tools from our planning profile to be in context. To do that, we can easily reassign our client to the planning profile.<\/p>\n
\n                \"image9\n        <\/div>\n
Figure 7: Reassign Claude Code to the planning profile.<\/strong><\/p>\n
If we go back to coding mode, we just reassign our client back to the coding profile. You can have any number of Profiles that mirror your many ways of working and easily switch between them, keeping only the tools you care about in context.<\/p>\n
This will work with any agent, not just Claude Code. Profiles provide a truly portable way to manage your MCP server setups and avoid vendor lock-in.<\/p>\n
Persist configuration<\/h3>\n
You can avoid repeatedly configuring MCP servers by using a Profile. Profiles add a persistence layer for MCP server configurations. When an MCP server exposes configurable options, you can define them once in a Profile and reload them as needed, avoiding repeated configuration.<\/p>\n
In this example, we are\u00a0specifying which paths Markitdown can access.<\/p>\n
\n                \"image1\"\n        <\/div>\n
Figure 8: Using an MCP profile to save server configurations for reuse<\/strong><\/p>\n
Context windows can easily fill up when the MCP servers you use export a lot of tools. With Profiles you can specify which tools are enabled, making sure only the tools you need for a specific task are used.<\/p>\n
Here we enable the get_me<\/code> tool from the GitHub MCP server and disable all the others. All the other tools will not show up in our agent session or contribute to the context window.<\/p>\n
\n                \"image2\"\n        <\/div>\n
Figure 9: Optimize your context window by enabling only the tools you need in the MCP profile<\/strong><\/p>\n
This model of saved configuration becomes far more powerful for MCP servers you build in-house. By exposing richer configuration options, you can reuse the same server across projects, reconfigure its behavior per context, and achieve more predictable outcomes.<\/p>\n
Share Profiles<\/h3>\n
Identifying MCP servers and configurations that work well for a project doesn\u2019t need to be repeated by every team member. Once you\u2019ve found a setup that works, share it with the rest of the team.<\/p>\n
To share a Profile you can push it as an OCI artifact to a container registry just like we did with our custom catalog. Just provide a name for it along with an OCI reference.<\/p>\n
\n
\n\u279c  ~ docker mcp profile push coding [your-namespace]\/coding\n\n<\/pre>\n<\/div>\n
For someone to pull it down, all they have to do is issue the corresponding pull command.<\/p>\n
\n
\n\u279c  ~ docker mcp profile pull [your-namspace]\/coding\n<\/pre>\n<\/div>\n
Although the example above demonstrates sharing Profiles across a team, the concept extends naturally to agents as well. An agent skill could, for instance, reference a Profile and pull in the required MCP servers and their configurations as dependencies.<\/p>\n
Conclusion and What\u2019s Next\u00a0<\/h2>\n
As MCP adoption grows, the challenge isn\u2019t access to tools \u2014 it\u2019s coordination. Teams need a way to standardize what\u2019s trusted and supported without constraining how individuals actually work. Custom Catalogs and Profiles are designed to solve exactly that problem.<\/p>\n
Custom Catalogs: shared foundation<\/h3>\n
Custom Catalogs allow platform and admin teams to define approved MCP servers, bundle internal and public tooling together, and distribute those choices as a single, portable artifact. This creates clarity and consistency while significantly reducing the cost of discovery and evaluation.<\/p>\n
Profiles: supercharge workflow<\/h3>\n
Profiles give individual developers a lightweight way to assemble, configure, and reuse MCP servers for specific contexts like coding, planning, or research. Profiles persist configuration, limit context to what matters, and make effective setups easy to share across teams.<\/p>\n
Together, these primitives separate:<\/p>\n