new-mcp

name	new-mcp
description	Protocolo completo para crear un nuevo MCP server. Use when: crear MCP, nuevo MCP, diseñar MCP, nuevo servidor MCP, iniciar proyecto MCP, scaffolding MCP. Incluye entrevista de requisitos, diseño de arquitectura, scaffolding, implementación, testing e integración.
argument-hint	Nombre o descripción breve del MCP que quieres crear

Protocolo de Creación de MCP Server

Workflow completo para diseñar e implementar un nuevo MCP server dentro de mcp-factory.

Fases del protocolo

Fase 1: Discovery — Entender el proyecto

Usar la herramienta de preguntas para entrevistar al usuario. Recopilar:

1. Nombre del MCP — Slug válido (lowercase, hyphens). Ej: weather-api, postgres-manager.
2. Descripción — Qué hace en una frase. Ej: "Consulta datos meteorológicos desde OpenWeather API".
3. Template base — Determinar cuál aplica:
   • basic → Tools simples sin I/O externo.
   • api → Consume APIs HTTP externas.
   • db → Accede a bases de datos.
4. Tools que expondrá — Lista de herramientas que el LLM podrá usar. Para cada tool:
   • Nombre (snake_case).
   • Qué hace (será el docstring).
   • Parámetros de entrada (nombre, tipo, descripción).
   • Tipo de retorno.
5. Resources (opcional) — Datos estáticos o dinámicos que el LLM puede leer.
6. Prompts (opcional) — Templates de conversación predefinidos.
7. Dependencias externas — APIs, bases de datos, servicios que necesita.
8. Variables de entorno — API keys, URLs, configuración necesaria.

Fase 2: Arquitectura — Diseñar antes de codear

Antes de escribir código, crear un plan estructurado:

1. Diagrama de tools — Lista cada tool con su firma completa:

   @mcp.tool()
   async def nombre_tool(param1: tipo, param2: tipo) -> tipo_retorno:
       """Descripción del tool.
   
       Args:
           param1: Descripción.
           param2: Descripción.
       """
   

2. Diagrama de dependencias — Qué módulos de _shared/ usará:

   • config → Siempre.
   • mcp_logging → Siempre.
   • http_client → Si consume APIs.
   • db → Si accede a base de datos.
   • auth → Si necesita API keys.

3. Variables de entorno — Lista completa para .env:

   MCP_DEBUG=false
   API_KEY=xxx
   BASE_URL=https://...
   

4. Checklist de verificación — Qué probar para confirmar que funciona.

Presentar el plan al usuario y esperar confirmación antes de implementar.

Fase 3: Scaffolding — Generar la estructura

Ejecutar el script de creación:

cd /Users/binngrow/Documents/MCP/mcp-factory
python _scripts/create_mcp.py --name {nombre} --template {template} --description "{descripción}"

Verificar que se creó correctamente:

ls -la servers/{nombre}/
cat servers/{nombre}/server.py

Fase 4: Implementación — Escribir los tools

1. Editar server.py — Reemplazar los tools de ejemplo con los diseñados en Fase 2.
2. Agregar imports necesarios — De _shared/ y dependencias externas.
3. Actualizar .env — Con las variables definidas en Fase 2.
4. Actualizar .env.example — Sin valores reales, solo placeholders.
5. Actualizar pyproject.toml — Agregar dependencias extra si las hay.
6. Ejecutar uv sync en el directorio del server para instalar nuevas deps.
7. Actualizar README.md — Con la lista real de tools y configuración.

Fase 5: Testing — Verificar que funciona

1. Syntax check:

   cd servers/{nombre} && uv run python -c "import server"
   

2. Inspector web:

   python _scripts/test_mcp.py --name {nombre}
   

3. Verificar cada tool desde el Inspector:

   • Invocar con parámetros válidos → verificar respuesta.
   • Invocar con parámetros inválidos → verificar manejo de error.

4. Lint check:

   cd servers/{nombre} && uv run ruff check server.py
   

Fase 6: Integración — Conectar con el cliente

1. Instalar en VS Code:

   python _scripts/install_mcp.py --name {nombre} --target vscode
   

2. Verificar que el MCP aparece disponible en el chat.

3. Test end-to-end — Pedir al LLM que use uno de los tools.

Reglas del protocolo

• Nunca saltar fases — Siempre seguir en orden 1→6.
• Siempre confirmar el plan — No implementar sin aprobación del usuario en Fase 2.
• Un tool a la vez — Implementar y verificar cada tool antes de pasar al siguiente.
• Docstrings obligatorios — Cada tool necesita docstring en español con Args.
• Async para I/O — Si un tool hace HTTP, DB o filesystem, debe ser async.
• Variables en .env — Nunca hardcodear secretos o URLs en server.py.

Referencia rápida de templates

Template	Ideal para	Deps incluidas	Tools de ejemplo
basic	Tools sin I/O externo	fastmcp, dotenv	hello, add
api	Consumir APIs REST/GraphQL	+ httpx	api_get, api_post
db	Acceder a PostgreSQL/MongoDB	+ asyncpg	query, list_tables, describe_table

Archivos del skill

• Referencia de FastMCP — Patrones comunes de tools, resources y prompts
• Checklist de verificación — Lista completa de checks antes de deploy