Docker Hub

@dockerhub list all repositories in our 'acme-corp' organization and show which ones haven't been updated in the last 90 days

I found 12 repositories in the acme-corp organization. Three haven't been updated recently: 'legacy-api' (last push 147 days ago, 2.3k pulls), 'old-worker' (last push 203 days ago, 890 pulls), and 'deprecated-frontend' (last push 312 days ago, 156 pulls). The remaining 9 repos have activity within the past month, with 'main-service' being the most active (updated 2 days ago, 45k pulls).

This read-heavy example demonstrates repository discovery and filtering. Requires API key with read access to the organization. Response times depend on repository count; organizations with hundreds of repos may see slower queries. The MCP doesn't automatically archive stale images—you'll need to decide on cleanup actions separately.

@dockerhub create a new repository called 'ml-inference-service' in our organization with a description and set it to private visibility

I've created the repository 'acme-corp/ml-inference-service' with private visibility. Description set to 'Machine learning inference API service'. The repository is now ready to receive image pushes. No webhooks or teams are configured yet—you can set those up separately. The repository URL is hub.docker.com/r/acme-corp/ml-inference-service.

This write example shows repository provisioning. Requires API key with write permissions on the organization namespace. Creating a repository doesn't automatically configure CI/CD pipelines or access controls—you'll need to set team permissions and webhooks in follow-up steps. Private repos count against your organization's plan limits.

@dockerhub review all webhooks across our repositories and identify any pointing to deprecated staging URLs, then draft a migration plan

I scanned 12 repositories and found 8 active webhooks. Three are pointing to deprecated endpoints: 'legacy-api' has a webhook to staging-old.acme.com (returns 404), 'main-service' has two webhooks where one targets ci-deprecated.acme.com, and 'worker-queue' points to jenkins-v1.acme.com (no longer in DNS). Recommended migration: update these to your current CI endpoint (ci.acme.com), test with a manual trigger, then delete the old hooks. I can execute these updates if you confirm the new endpoint.

This synthesis example pairs webhook enumeration with AI reasoning to identify configuration drift. The MCP can read webhook configs and delete outdated ones, but cannot test endpoint reachability—you'll need to verify new URLs externally. Webhook updates require deleting and recreating (no in-place edit), which briefly interrupts delivery during the swap.

When this MCP wins for spinning up contractor access fast

A 6-person dev team brings on two contractors for a 3-month feature push. The lead needs to grant them read access to 4 private repos and write access to 1 staging repo, then revoke it all when the contract ends. The Docker Hub MCP handles this in a single Switchy thread: create the contractor accounts as org members with the right role, assign them to a temporary team scoped to those repos, then delete the team and memberships when the sprint wraps. The API key auth means the lead doesn't juggle OAuth tokens or share their personal credentials. This breaks down if you're onboarding more than 10 people at once—at that scale, you want a proper IDP integration, not a chat interface. For small-batch contractor workflows, though, the MCP turns a 20-minute ClickOps chore into a 90-second conversation.

When this MCP saves time after a CI pipeline migration

A 4-person platform team just migrated from Jenkins to GitHub Actions. They have 18 Docker Hub repos, each with 2-4 webhooks pointing at the old Jenkins endpoints. The webhooks are firing 404s on every push, cluttering logs and confusing the on-call rotation. The Docker Hub MCP lets the team list all webhooks across their org repos in one query, identify the stale Jenkins URLs, and delete them in bulk without opening 18 browser tabs. The 26-tool scope includes webhook CRUD, so the entire cleanup happens in a single Switchy session. This scenario assumes you're working with under 50 repos—beyond that, you'd script it directly against the API rather than chat through it. For mid-sized cleanup jobs after a tooling shift, the MCP turns a tedious audit into a 5-minute thread.

When this MCP handles white-label registry setup for new customers

A 10-person SaaS startup provisions a dedicated Docker Hub org and 3 repos for each new enterprise customer as part of their white-label onboarding flow. The support team used to file Jira tickets for DevOps to run Terraform; now they use the Docker Hub MCP in Switchy to create the org, repos, and initial webhooks in real time while the customer waits on a Zoom call. The create-org and create-repo tools cover the happy path, and the delete tools let support clean up if a trial customer churns before converting. This works cleanly for 2-5 new customers per week; if you're onboarding 20+ customers daily, you want this logic in your backend provisioning service, not a shared AI workspace. For low-to-mid-volume customer onboarding, the MCP collapses a 48-hour ticket cycle into a 3-minute live demo.