
Skill
mcp-server-yaml-creator
configure custom MCP servers in Docker
Description
Add and configure custom MCP servers in Docker MCP Gateway. Use when users want to: (1) Integrate their own MCP server into the gateway, (2) Add new servers to catalogs or profiles, (3) Set up server authentication, networking, and configuration, (4) Understand MCP server integration requirements.
SKILL.md
MCP Server YAML Creator
Overview
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:
- server: Containerized MCP servers (most common)
- remote: Remote HTTP/SSE MCP servers
Quick Start - Creation from Templates
Start from a template for your server type:
assets/template-server.yaml- Containerized MCP serversassets/template-remote.yaml- Remote HTTP/SSE servers
Copy the relevant template and customize it for your needs.
Advanced Configuration
For complex scenarios (nested objects, conditional requirements, OAuth), consult references/spec.md for the complete specification.
Core Requirements
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)
Type: "server" (Containerized)
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/dataor 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 purposes
See assets/template-server.yaml for a complete example.
Type: "remote" (HTTP/SSE)
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.
Configuration Schema
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 values that are setup in the
configat the top level. - Hard-coded environment variables that the server requires.
- Secrets should never be added here, as they are injected automatically as environment variables.
For arrays, nested objects, conditional requirements (anyOf/oneOf), see references/spec.md.
Secrets and Authentication
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.
Network Security
Option 1: Restrict to specific hosts
allowHosts:
- api.example.com:443
- github.com:443
Option 2: Disable all network
disableNetwork: true
Usage
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
Best Practices
- Use lowercase-hyphenated naming:
my-custom-server - Keep server descriptions short and concise (1-2 sentences maximum)
- Always use
secretsfield for API keys/tokens, never hardcode inenv - Use
allowHoststo restrict network access - Provide clear descriptions for all config properties
- Consider if any environment variables should be hard-coded rather than user-defined.
- Use SHA256 digests for production images, tags for development
- Mark config fields as required when necessary
- Omit fields that are empty (e.g.
env,secrets) - Test the server.yaml by adding it to a profile and running the gateway
- ONLY use or show
docker mcpcommands that you've been told about. Don't make up commands.
Resources
- assets/: Template examples for each server type (server, remote)
- references/spec.md: Complete technical specification with advanced patterns