Publica tu MCP Server en GitHub con un README profesional, licencia y documentación de instalación.
Antes de publicar en GitHub, tu repositorio debe estar limpio y organizado. Esto significa inicializar Git y configurar un .gitignore adecuado para Python y garantizar que nunca se hagan commits de archivos sensibles o innecesarios. Un repositorio bien preparado transmite profesionalismo y facilita las contribuciones.
Pasos esenciales para preparar el repositorio:
# Inicializar o repositório $ git init # Criar .gitignore com template Python $ curl -o .gitignore https://raw.githubusercontent.com/github/gitignore/main/Python.gitignore # Primeiro commit $ git add . $ git commit -m "Initial commit: MCP Server structure"
O .gitignore para Python debe excluir: __pycache__/, .env, .venv/, dist/, *.egg-info/ y otros artefactos de compilación.
.env — claves de API y secretos__pycache__/ — caché de Python.venv/ — entorno virtual localdist/ — artefactos de buildpyproject.toml — definición del paqueteuv.lock — lockfile de dependenciassrc/ — código fuente del server.gitignore — reglas de exclusión
Usa el plantilla oficial de .gitignore para Python de GitHub: cubre más de 30 patrones de archivos que no deben incluirse en un commit. Si ya hiciste commit de un .env si lo borras por accidente, elimínalo del historial con git filter-branch o BFG Repo-Cleaner y cambia de inmediato todas las claves expuestas.
El README es la puerta de entrada de tu proyecto. Es lo primero que cualquier persona ve al visitar tu repositorio en GitHub. Un README bien escrito marca la diferencia entre que alguien instale y use tu server o cierre la pestaña en 5 segundos. Debe comunicar claramente qué hace el server, cómo instalarlo y cómo configurarlo.
Un README profesional para un MCP Server debe contener secciones esenciales: título y descripción clara sobre lo que hace el servidor; instalación con comandos exactos para instalar mediante uv o pip; configuración en Claude Desktop con el JSON exacto para el claude_desktop_config.json; tools disponibles con la descripción de cada herramienta; y ejemplos de uso mostrando interacciones reales. Los badges de Python y License en la parte superior aportan credibilidad visual.
Nombre del proyecto, descripción en una línea y badges (versión de Python, License, estado de Build).
Comandos claros: uv pip install git+https://github.com/usuario/repo o clonar + instalar localmente.
JSON exacto para agregar a claude_desktop_config.json, con las variables de entorno necesarias.
Lista de todas las tools con descripción y ejemplos de prompts que el usuario puede usar en Claude.
Usa el prueba de los 30 segundos: si alguien no puede entender qué hace tu server y cómo instalarlo en 30 segundos leyendo el README, hay que reescribirlo. Pon el comando de instalación y la configuración de Claude Desktop al principio: son la información que más se busca.
Un proyecto sin licencia es, por defecto, todos los derechos reservados — nadie puede usar, modificar ni distribuir legalmente tu código. Agregar una licencia open source es esencial para que la comunidad pueda contribuir y usar tu MCP Server. Además, las pautas de contribución ayudan a mantener la calidad del proyecto.
A licencia MIT es la opción más popular para proyectos open source: es simple, permisiva y permite el uso comercial. Basta con crear un archivo LICENSE en la raíz del proyecto con el texto estándar de MIT. Para contribuciones, un CONTRIBUTING.md debe explicar cómo reportar errores, sugerir funcionalidades y enviar pull requests. Opcionalmente, un CODE_OF_CONDUCT.md establece reglas de convivencia para la comunidad.
La MIT License se usa en más de 44% de los proyectos de código abierto en GitHub, seguida por Apache 2.0 (18%) y GPL 3.0 (9%). Los proyectos con una licencia clara reciben 3 veces más contribuciones que los proyectos sin licencia. La mayoría de los MCP Servers publicados por la comunidad usan MIT; es el estándar de facto de este ecosistema.
GitHub Actions permite automatizar pruebas y verificaciones en cada push o pull request. Para un MCP Server, un workflow básico de CI (integración continua) garantiza que el código pase el linter, que el paquete se construya sin errores y que los imports funcionen correctamente. Esto evita que llegue código defectuoso a la branch principal.
Un workflow YAML simple para CI del MCP Server:
name: CI on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: astral-sh/setup-uv@v4 - run: uv sync - run: uv run ruff check . - run: uv build - run: uv run python -c "import meu_server"
Este workflow instala dependencias y ejecuta el linter ruff, prueba el build y verifica que se pueda importar el paquete. Guarda en .github/workflows/ci.yml.
Usa astral-sh/setup-uv para configurar el uv en GitHub Actions: es la forma más rápida de instalar dependencias de Python en CI. El ruff es el linter más rápido del ecosistema de Python y cubre las mismas reglas que flake8, isort y pyupgrade en un solo binario.
Nunca pongas secretos directamente en el workflow YAML. Si tu MCP Server necesita claves de API para las pruebas, usa GitHub Secrets (Settings → Secrets → Actions) y haz referencia a ellos como ${{ secrets.API_KEY }} en el workflow. Los secretos codificados directamente en los workflows son visibles para cualquier persona con acceso al repositorio.
Las etiquetas y las releases son la forma profesional de marcar versiones estables de tu proyecto. Una etiqueta Git marca un punto específico del historial; un GitHub Release combina esa etiqueta con notas del changelog para que los usuarios puedan identificar e instalar versiones específicas de tu MCP Server.
El flujo para crear una release:
# Atualizar versão no pyproject.toml para 0.1.0 # Commitar a mudança $ git add pyproject.toml $ git commit -m "Release v0.1.0" # Criar tag anotada $ git tag -a v0.1.0 -m "First stable release" # Push com tags $ git push origin main --tags
Usa semver (versionado semántico): v0.1.0 para la primera release, incrementando PATCH para correcciones, MINOR para funcionalidades y MAJOR para breaking changes. En GitHub, crea un Release a partir de la tag con un changelog que describa qué cambió.
Actualizar la versión en el pyproject.toml y confirmar el cambio con un commit.
Crear una etiqueta anotada con git tag -a y hacer push al remoto con --tags.
En GitHub, crea una Release a partir de la tag con un changelog que describa los bugs corregidos, las features agregadas y los breaking changes.
Mantén un formato de changelog consistente en las releases. Usa categorías como "Added", "Fixed", "Changed" e "Breaking" para que los usuarios sepan rápidamente qué cambió. El formato Keep a Changelog es una excelente referencia.
La prueba final antes de anunciar tu MCP Server es el prueba del clon limpio: clona el repositorio en otra carpeta (o en otra máquina), sigue exactamente las instrucciones del README y verifica que todo funcione. Si no puedes instalarlo siguiendo tu propio README, nadie más podrá hacerlo.
La prueba de instalación simula la experiencia de un usuario nuevo:
# Clonar em pasta limpa $ git clone https://github.com/usuario/meu-mcp-server /tmp/teste $ cd /tmp/teste # Seguir instruções do README $ uv sync $ uv run meu-server # Verificar que funciona no Claude Desktop # Configurar e testar uma chamada de tool
Si algún paso falla, actualiza el README o corrige el problema antes de publicar. La prueba debe cubrir: instalación, ejecución, configuración en Claude Desktop y al menos una llamada funcional a una tool.
Clonar el repositorio en una carpeta temporal y verificar que la estructura esté completa.
Instalar siguiendo exactamente el README, sin pasos adicionales que "tú sabes" pero no documentaste.
Ejecutar el server, configurarlo en Claude Desktop y ejecutar al menos una tool correctamente.
Siguiente Módulo: 5.3 — Transporte HTTP/SSE