From beta-mcp-skills
Generates server.yaml files for adding custom containerized or remote MCP servers to Docker MCP Gateway catalogs and profiles, including auth, networking, env, and volume configs.
npx claudepluginhub docker/claude-plugins --plugin beta-mcp-skillsThis skill uses the workspace's default tool permissions.
Create valid server.yaml files for custom MCP servers that can be added to Docker MCP Gateway catalogs and profiles using the `--server file://server.yaml` flag.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
Create valid server.yaml files for custom MCP servers that can be added to Docker MCP Gateway catalogs and profiles using the --server file://server.yaml flag.
MCP servers can be of three types:
Start from a template for your server type:
assets/template-server.yaml - Containerized MCP serversassets/template-remote.yaml - Remote HTTP/SSE serversCopy the relevant template and customize it for your needs.
For complex scenarios (nested objects, conditional requirements, OAuth), consult references/spec.md for the complete specification.
All server.yaml files must include:
name: server-name # Lowercase, hyphen-separated
type: server # or: remote
title: Display Name
description: Server capabilities and purpose (1-2 sentences)
Most common type for custom MCP servers. Requires a Docker image. If the user doesn't have a Docker image, ALWAYS guide them on the process on creating a Dockerfile, building it, and pushing it. If they already have a Dockerfile, ALWAYS guide them on building and pushing the docker image so that it can be referenced in the image field.
Essential fields:
name: my-server
type: server
title: My Server
description: Brief description of what the server does (1-2 sentences)
image: myorg/my-server:latest
Common additions:
secrets: API keys, tokens (never hardcode)config: User-configurable settingsenv: Environment variables (can reference config with {{server-name.property}})allowHosts: Network access restrictionsvolumes: File system mounts (can be a named volume "named-volume:/app/data or mapped to a config "{{my-server.config_path}}:/app/config")longLived: Keep running vs on-demand for tool calls (only enable this if there's good reason to keep the server running)tools: An optional (but very helpful) list of tools the server exposes for discovery purposesSee assets/template-server.yaml for a complete example.
For remotely hosted MCP servers.
Essential fields:
name: remote-server
type: remote
title: Remote Server
description: Brief description of what the server does (1-2 sentences)
remote:
url: https://mcp.example.com/sse
transport_type: sse
See assets/template-remote.yaml for a complete example.
User-configurable settings allow users to provide values when using your server.
Basic example:
config:
- name: server-name
description: Connection settings
type: object
properties:
endpoint:
type: string
description: API endpoint URL
timeout:
type: number
description: Timeout in seconds
required:
- endpoint
Reference config values in environment variables:
env:
- name: API_ENDPOINT
value: "{{server-name.endpoint}}"
Environment variables should only ever be used for:
config at the top level.For arrays, nested objects, conditional requirements (anyOf/oneOf), see references/spec.md.
Always use the secrets field for sensitive values:
secrets:
- name: server-name.api_key
env: API_KEY
example: YOUR_API_KEY
Secrets are automatically injected as environment variables. NEVER put a secret in the env field of the server yaml.
For OAuth configuration, see references/spec.md.
Option 1: Restrict to specific hosts
allowHosts:
- api.example.com:443
- github.com:443
Option 2: Disable all network
disableNetwork: true
After creating server.yaml, add it to a profile or catalog:
# Add to a profile
docker mcp profile server add <profile-id> --server file://./server.yaml
# Create catalog with the server
docker mcp catalog-next create <catalog-id> --title "My Catalog" --server file://./server.yaml
Be sure to ask the user what they would like to do. The recommended approach would be to create a new catalog and add it to a new catalog.
If you need to understand more about what docker mcp commands are available, check out the docs at https://raw.githubusercontent.com/docker/mcp-gateway/refs/heads/main/docs/profiles.md
my-custom-serversecrets field for API keys/tokens, never hardcode in envallowHosts to restrict network accessenv, secrets)docker mcp commands that you've been told about. Don't make up commands.