Ir al contenido

Modelo de onboarding MCP alojado

Cómo hacer Pasos para una tarea concreta. Da por sabido lo básico.

El modelo de producto más fácil para este framework se apoya en dos piezas:

  • un MCP alojado para onboarding, docs, prompts y ayuda visual
  • un MCP local o bridge local para escribir archivos reales en el proyecto del usuario

Usa esta página cuando necesites explicar cómo el framework puede volverse más fácil sin perder rigor.

Referencia relacionada:

flowchart LR
A["Usuario"] --> B["Cliente IA"]
B --> C["MCP alojado de onboarding SDD"]
B --> D["sdd-mcp local o bridge"]
C --> E["Docs, prompts, estructura, ejemplos"]
D --> F["Archivos reales del proyecto"]
F --> G["idea/"]
F --> H["specs/"]
F --> I["bitacora/"]

Problema:

  • un MCP totalmente local da acceso real a archivos, pero sigue sintiéndose técnico de configurar
  • un MCP totalmente alojado es fácil de conectar, pero no puede escribir de forma segura por sí solo dentro del proyecto local del usuario

Solución:

  • dejar el MCP alojado para la capa de enseñanza
  • dejar el MCP local para la capa de ejecución

Con eso el arranque deja de ser el cuello de botella, las escrituras siguen ocurriendo de verdad en el proyecto, y las reglas no cambian según el cliente IA que tengas abierto.

Propósito:

  • explicar el framework
  • exponer prompts para principiantes
  • exponer mapas visuales de carpetas
  • explicar resultados de comandos
  • guiar al usuario antes de cualquier escritura real en el proyecto

Capacidades recomendadas:

  • prompts como easy_start_project, easy_create_spec, easy_show_structure
  • resources estáticos como policy, quickstart, guía fácil MCP y bancos de prompts
  • ejemplos para proyectos nuevos y existentes
  • guía visual de “qué pasa después”

Propósito:

  • crear carpetas y archivos
  • actualizar specs/INDEX.md
  • escribir archivos de bitácora
  • validar el estado del proyecto
  • revisar la compuerta SDD antes de implementar

Capacidades recomendadas:

  • los tools actuales de sdd-mcp
  • un wrapper CLI o launcher desktop opcional para conexión local de un clic

Para un usuario no técnico, la experiencia debe sentirse así:

flowchart TD
A["Conectar una URL MCP alojada"] --> B["Pedir en lenguaje simple"]
B --> C["La IA explica qué va a hacer"]
C --> D["El MCP local escribe archivos solo cuando hace falta"]
D --> E["El usuario revisa y aprueba el siguiente paso"]

El usuario no debería necesitar entender:

  • transportes
  • esquemas
  • builds de paquetes
  • reglas de workspace en detalle

El usuario debería entender solo:

  • qué acción está ocurriendo
  • qué archivos se tocarán
  • qué resultado aparecerá
  • cuál es el siguiente paso

Corto plazo:

  • mantener sdd-mcp local para operaciones
  • publicar docs que definan el contrato de la capa alojada
  • usar el transporte HTTP actual como base conceptual
  • usar opcionalmente GitMCP como capa externa gratuita de contexto del repo público

Mediano plazo:

  • alojar un endpoint MCP de onboarding orientado a lectura
  • exponer prompts, guías fáciles, mapas de carpetas y ejemplos
  • mantener las escrituras en local

Largo plazo:

  • ofrecer un launcher de un clic o un bridge local delgado que la capa alojada pueda orquestar a través del cliente

GitMCP sirve como capa externa gratuita para repositorios públicos.

Qué sí puede hacer bien:

  • permitir que clientes IA lean y entiendan este repositorio de forma remota
  • exponer docs y estructura pública con casi cero setup
  • ayudar en descubrimiento, demos y difusión

Qué no debe considerarse:

  • un reemplazo de sdd-mcp
  • un reemplazo de tus prompts y comportamiento de producto
  • un escritor seguro dentro del proyecto local del usuario

Entonces la forma correcta de explicarlo es:

  • GitMCP o similar = contexto externo del repo
  • MCP alojado de onboarding = tu capa remota propia de guía
  • sdd-mcp local = capa operativa local de ejecución

El MCP alojado de onboarding debería ofrecer al menos:

  • sdd://docs/easy-mcp
  • sdd://docs/quickstart
  • sdd://policy/current
  • un catálogo de comandos fáciles
  • prompts para inicio de proyecto, creación de spec, explicación de estructura, validación, siguiente paso y cierre de sesión
Puedes usar SDD en dos partes simples.
Una parte te enseña y guía.
La otra parte escribe los archivos reales en tu proyecto.
Así el inicio es simple y la ejecución es segura.