Genera leads para tu Universidad a través de
un Asistente IA.

1.1Discovery y arquitectura del Core

• Facilitación de 2 workshops con el cliente para alinear visión y limitar scope del Core.
• Mapeo de stakeholders y plan de comunicación durante el proyecto.
• Identificación inicial del roadmap de aplicaciones sobre el Core (Advisor → futuras aplicaciones) para anticipar requisitos de escalabilidad.
• Diseño de arquitectura de referencia: framework común + Servers distintos por familia de uso. Documento técnico con diagrama de componentes y patrones de auth, consentimiento y observabilidad.
• Decisiones técnicas tempranas: lenguaje (TS o Python), transporte HTTP, modelo de hosting, stack de monitoring.
• Risk register inicial — incertidumbre el CRM, calendario regulatorio EU, capacidad del equipo del cliente para entregar info técnica a tiempo.
• Consolidación de documento "Arquitectura del MCP Core" como handoff a la fase de construcción.

1.2MCP Server core

• Skeleton del proyecto en TypeScript con SDK oficial de MCP. El SDK es el kit de desarrollo de código abierto del protocolo MCP. Permite no implementar desde cero todo el protocolo MCP; el código se construye encima de él. Se elige TypeScript porque es el SDK más maduro del ecosistema MCP.
• Implementación del transporte HTTP Streamable. El "transporte" es la forma en que el cliente LLM (ChatGPT) habla con nuestro Server. Para el Advisor siempre será HTTP remoto porque los estudiantes lo consumen desde su ChatGPT personal.
• Gestión stateful de sesiones. A diferencia de una API REST típica, MCP mantiene memoria de conversación mientras el usuario interactúa con el Advisor. Requiere identificar cada sesión con un ID único y guardar el estado intermedio en una base de datos rápida (típicamente Redis).
• Capability negotiation. Al abrir conexión, Client y Server intercambian "qué sabe hacer cada uno" en un handshake breve. Permite que el mismo Server funcione con distintos clientes LLM.
• JSON-RPC 2.0 boilerplate. JSON-RPC es el formato de mensajes que MCP usa por debajo — un estándar de años, no inventado para IA.
• Logging básico estructurado. Cada acción del Server queda registrada en formato JSON, con niveles de severidad y un identificador de sesión que permite reconstruir toda la conversación de un usuario a posteriori.
• Estructura modular pensada para escalabilidad. El MCP Server se prepara para hospedar múltiples Servers desde origen, sin retrabajo al añadir aplicaciones posteriores.
• Tests unitarios del core. Pruebas automatizadas que validan cada función individual del Core en aislamiento.

1.3Framework de autenticación

• Implementación de OAuth 2.1 con PKCE según spec MCP. OAuth es el estándar de la industria para autenticar usuarios sin gestionar contraseñas. PKCE es una capa de seguridad adicional obligatoria en MCP. Su fallo es la principal causa de rechazo en la review de marketplace (~30% de submissions).
• Modo anónimo para Advisor consumer. El estudiante que abre el Advisor en su ChatGPT no necesita hacer login en el cliente. La identificación viene cuando rellena el formulario de lead, no antes.
• Estructura preparada para SSO corporativo. El framework queda listo para enchufarse al SSO del cliente cuando llegue una aplicación de uso interno. En esta fase solo se deja preparado; la integración real va más adelante.
• Gestión de tokens. Ciclo de vida completo: refresh automático, expiración, revocación, almacenamiento seguro encriptado.
• Callback URLs configurables por plataforma destino. ChatGPT requiere callbacks que apunten a sus dominios.
• Tests de seguridad básicos del flow OAuth. Validación ante tokens expirados, callbacks falsificados, intentos de replay.

1.4Plantilla de consentimiento conversacional

• Diseño UX del flujo de consentimiento conversacional. Cómo se redacta de manera natural dentro del chat (no como banner de cookies), qué se pregunta exactamente, y qué niveles de aceptación se ofrecen: analytics agregado (anónimo, opt-out), almacenamiento de la conversación (opt-in), envío del contexto al CRM (opt-in explícito).
• Microcopy reutilizable. Textos cortos de la interfaz redactados en plantilla, parametrizables por cliente y por aplicación.
• Audit trail técnico. Registro auditable y completo de cada consentimiento: marca de tiempo, versión de la política aceptada, niveles aceptados. Es el documento que se enseña ante una inspección de la AEPD.
• Endpoint de revocación del consentimiento. Mecanismo que permite al usuario retirar su consentimiento desde dentro de la conversación, disparando borrado o anonimización automática de sus datos.
• Tests unitarios del flujo de consentimiento. Validación de todos los escenarios: consiente, rechaza, consiente parcialmente, revoca después.
• Documentación del patrón para reutilizar en aplicaciones futuras.

1.5Hosting e infraestructura

• Despliegue containerizado en GCP Cloud Run (o equivalente — AWS ECS, Railway, Fly.io). Un container es un paquete con el código del Server + sus dependencias, que se ejecuta igual en cualquier máquina.
• Configuración de certificados HTTPS (Let's Encrypt automático). Conexión segura sin renovación manual.
• DNS + subdominio. Decisión a cerrar con el cliente: ¿subdominio propio del cliente o de Secuoyas? Tiene implicaciones de branding y certificados.
• Pipeline CI/CD básico (GitHub Actions o equivalente). Automatización que toma el código nuevo, lo prueba y, si todo pasa, lo despliega al servidor.
• Configuración inicial de secretos. Credenciales sensibles guardadas en sistemas seguros separando tres entornos: dev, staging y prod.
• Healthchecks y autoscaling básico. Verificación continua del Server; reinicio automático si falla; escalado horizontal en momentos de pico.

1.6Observabilidad y métricas

• Logs estructurados por sesión. Cada sesión deja un rastro detallado y correlacionado: qué tools invocó, qué resources consultó, qué errores ocurrieron.
• Métricas operativas · indicadores clave del sistema vivo:
  • Uptime: % de tiempo que el Server está respondiendo (objetivo típico 99,5%+).
  • Latencia por tool: cuánto tarda cada tool en ejecutarse, percentil 50 y 95.
  • Error rate: % de llamadas que fallan.
  • Número de sesiones: cuántos usuarios consumen el Advisor por hora/día/semana.
  • Duración media de sesión: cuánto dura cada conversación.
• Métricas de producto base reutilizables por toda aplicación: telemetría de uso, eventos de negocio agregables, base para dashboards de tracción (sesiones, conversaciones, leads, conversión).
• Integración con stack de monitoring (Datadog, Logtail, CloudWatch o equivalente según preferencia del cliente y coste).
• Dashboards básicos operativos. Gráficos con la salud del sistema en tiempo real.
• Alertas operativas. Notificaciones automáticas (Slack o email) cuando algo va mal: error rate disparado, certificado por expirar, latencia disparada.

1.7Testing framework reutilizable

• Harness de tests funcionales estandarizado. Andamiaje técnico que ejecuta y valida pruebas automáticamente. Sirve para cualquier tool/resource/prompt de cualquier aplicación del Core.
• Estructura de tests adversariales reutilizable. Catálogo base de prompts hostiles, framework para añadir casos específicos, y criterios objetivos fail/pass. El catálogo se hereda en cada aplicación nueva sin reinventar.
• Tests de robustez. Pruebas de qué pasa cuando algo va mal "por fuera": backends responden tarde, devuelven datos malformados, fallos de red. El Server debe degradarse de forma controlada.
• Métricas de cobertura del testing y reporting. Cobertura mide qué porcentaje del código está cubierto por pruebas (objetivo típico 70-80%+).
• Documentación del testing framework para que aplicaciones futuras lo reutilicen sin reinventar.

1.8Documentación técnica del framework

• Docs internas Secuoyas sobre cómo crear una nueva aplicación sobre el MCP Core. Estructura del módulo, "hooks" disponibles, patrones recomendados. Permite que la segunda aplicación tarde menos de la mitad que la primera (Advisor).
• Docs handoff al cliente si quiere que su IT entienda la arquitectura. Versión sanitizada para auditorías técnicas o políticas de seguridad.
• Runbooks operativos para el IT del cliente: criterios de seguridad, procedimientos de despliegue, gestión de incidentes. Útil si el cliente quiere autonomía técnica futura sobre el Core.
• Diagrama de componentes actualizado. Esquema visual de cómo se relacionan Core, aplicaciones, integraciones externas, hosting, observabilidad y consentimiento.

2.1Discovery del Advisor + mapeo de la KB

• Workshop específico del Advisor con el cliente: identificación uno-a-uno de Tools/Resources/Prompts concretos del Advisor.
• Mapeo de la KB: inventario exhaustivo del contenido del site del cliente que entra en la base de conocimiento (programas, becas, faculty, calendario, FAQs).
• Identificación explícita de qué NO entra en la KB (los brochures completos quedan como moneda de cambio para la conversión tradicional).
• Definición del tono y voz de marca específica del cliente.
• Mapping inicial de tools a campos del CRM (preparación para 2.3).
• Documento de scope del Advisor firmado por el cliente antes de pasar a construcción.

2.2Integración del CMS (CMS → Resources)

• Conexión vía la API del CMS con un patrón de integración que ya dominamos (ventaja operativa: no es exploración, es aplicación de patrón conocido).
• Definición de Resources MCP que se exponen desde el CMS: catálogo de programas estructurado, fichas individuales, becas, calendario académico, FAQs, faculty.
• Mapeo de schema del CMS → schema MCP. Cómo se traduce el contenido interno del CMS a la superficie pública del MCP Server. Cubre cinco decisiones:
  • Diseño del esquema de URIs: patrón estable que identifica cada Resource (program://master-of-science-in-management). Una vez publicadas no se pueden cambiar sin romper integraciones aguas abajo.
  • Elección del MIME type: Markdown para narrativa, JSON para datos cuantitativos, HTML cuando hace falta formato embebido.
  • Selección y reformateo de campos: qué campos entran, cuáles se filtran (campos internos, drafts) y cuáles se reformatean.
  • Manejo de relaciones entre Content Types: inline el contenido relacionado o devolver solo la URI del Resource hijo.
  • Política de estados: solo published va al Resource. Drafts, scheduled y archived se filtran.
• Lógica de caching y refresco automático cuando el CMS actualiza contenido.
• Tests de integración contra el entorno del CMS del cliente.

2.3Integración del CRM (Tool create_lead)

• Integración con la API del CRM. API pública documentada que permite crear leads desde sistemas externos. Cada universidad la adapta a sus campos y workflows.
• Implementación de la Tool create_lead. Cubre cuatro pasos: validar datos, llamar al CRM, procesar respuesta, devolver confirmación al usuario.
• Mapeo de campos del payload conversacional a campos del CRM. Hay que decidir qué campo conversacional alimenta qué campo del CRM, incluyendo metadatos extra: fuente, contexto conversacional resumido, capa legal con timestamp del consentimiento.
• Manejo de errores específicos del CRM: rechazo por dato inválido, dedupe (lead ya existe), timeouts, autenticación caída.
• Idempotencia y audit trail. Si por error de red la llamada al CRM se envía dos veces, no se crea el lead duplicado. Audit trail registra cada lead enviado.

2.4Diseño de prompts y voz de marca

• System prompt del Advisor. Instrucción base de personalidad y comportamiento que se da al LLM al inicio de cada conversación. Define quién es el Advisor, cómo habla, qué sabe, qué no debe hacer. Personalidad del cliente con tono coloquial pero institucional, énfasis en outcomes diferenciadores.
• Guardrails de scope. Barreras de seguridad:
  • Qué temas responde: programas del cliente, admisiones, becas, vida en campus, faculty, salidas profesionales.
  • Qué temas redirige al humano: situaciones complejas → derivación al equipo Admissions con contexto.
  • Qué temas rechaza: política, opiniones sobre otras universidades, consejos médicos/legales, contenido inapropiado.
• Voz de marca bajo estrés. Cómo se comporta el tono cuando el usuario rompe el registro habitual. Riesgo con público joven que tiende a hablar con confianza alta: si mimetiza pierde institucionalidad; si se pone formal de golpe ahuyenta.
• Pruebas iniciales de tono. Antes de cerrar el system prompt se le pasan ~20 conversaciones representativas para afinar iterativamente.

2.5Tools del Advisor

• Implementación de ~4-5 tools (mix Simple/Medio):
  • create_lead — destructive, crea registro en el CRM.
  • book_advisor_call — agendamiento con el equipo de Admissions.
  • request_brochure_link — envío de brochure vía email. No se le pasa el PDF al LLM.
  • get_program_details — readOnly.
  • compare_programs — readOnly.
  • find_scholarships — readOnly.
• Schema JSON preciso de inputs por tool. Especificación formal de qué espera recibir cada tool. El LLM lo lee para saber qué pedirle al usuario antes de invocar.
• Annotations correctas. Críticas para la aprobación en marketplace — el 30% de rechazos son por annotations mal definidas:
  • readOnlyHint: true — solo lee, no modifica.
  • destructiveHint: true — efectos secundarios irreversibles.
  • idempotentHint: true — se puede llamar dos veces sin efecto adicional.
• Tests unitarios por tool con baterías de inputs válidos e inválidos.

2.6Resources del Advisor

• Implementación de ~6-8 Resources estructurados (catálogo MVP): catálogo de másteres, fichas de cada programa, tuition, calendario académico, becas, requisitos por país, application timeline, campus.
• URIs estables, content type apropiado. La URI es el identificador único de cada Resource. Una vez publicada, no se cambia.
• Modo de exposición decidido por Resource:
  • Estático: el Server tiene el dato cargado. Útil para info inmutable.
  • Dinámico contra el CMS: el Server consulta el CMS en cada petición. Útil para info que cambia.
  • Con cache de N minutos: intermedio.

2.7Prompts del Advisor

• Redacción de ~3 Prompts reutilizables expuestos al Host. Plantilla pre-definida de tarea que el Host muestra al usuario como atajo:
  • compare_programs — comparativa estructurada entre dos másteres.
  • explain_admission_for_country — requisitos personalizados por país.
  • next_steps_application — guía paso a paso del proceso de aplicación.
• Parametrización correcta de cada Prompt. Definir qué inputs acepta, de qué tipo, si son obligatorios u opcionales, con qué valores válidos.
• Plantilla de mensaje con placeholders. Texto fijo con huecos que se rellenan con los argumentos del usuario. Incluye el tono de marca del cliente para consistencia.
• Validación de comportamiento con baterías de inputs típicos.

2.8UI embebida en el chat

• Formulario de captura de lead embebido en el chat. Mini-formulario visual dentro del chat (email, programa, país, fecha, consentimiento) que el usuario rellena de golpe. Reduce fricción significativamente.
• Tarjeta de programa. Componente visual con foto, datos clave y CTA.
• Comparativa entre programas en formato tabla embebida. Cuando el usuario invoca compare_programs, se renderiza una tabla con columnas paralelas en lugar de prosa larga.
• Componentes para el Apps SDK de OpenAI (ChatGPT).
• Tests visuales en ChatGPT (Dev Mode).

2.9Testing del Advisor

• Tests funcionales de cada tool, resource y prompt con baterías de inputs válidos.
• Tests de robustez: errores en el CRM, en el CMS, timeouts, datos malformados, inputs inesperados.
• Adversarial — jailbreaks específicos (~30-50 prompts hostiles) que intentan saltarse los guardrails, revelar información confidencial o romper la voz de marca.
• Adversarial — prompt injection vía KB. Manipulación del contenido que el LLM consume (Resources del CMS) con instrucciones disfrazadas. Se valida que el Advisor las ignora.
• Validación de voz de marca bajo estrés con perfiles tipo:
  • Usuario casual: jerga juvenil → tono cercano pero no chabacano.
  • Usuario hostil: insulta o cuestiona → se mantiene profesional.
  • Usuario confundido: fuera de contexto → redirige sin frustrar.
  • Usuario en crisis emocional: comparte problemas personales → maneja con cuidado y deriva.
• Validación de la capa de consentimiento en escenarios de revocación, no consentimiento, consentimiento parcial.
• Reporte de testing con fail/pass por categoría.

2.10Publicación en ChatGPT

• Rutas privadas (siempre incluidas, sin review externa):
  • App in ChatGPT (Developer Mode). "Modo desarrollador" donde la app es accesible para QA y demos antes de publicar.
• Rutas públicas (submission a marketplaces):
  • Submission a Apps in ChatGPT directory (OpenAI): manifest, política de privacidad publicada, OAuth callbacks, test account, gestión de la review.

2.11Acompañamiento al DPO del cliente

• Sesiones con el DPO del cliente (2-3 sesiones de 1-2h cada una). El DPO (Delegado de Protección de Datos) es la figura legalmente responsable del cumplimiento RGPD. Las sesiones definen el alcance exacto de qué información puede manejar y guardar el Advisor.
• Documento de qué se puede pasar al CRM:
  • Campos PII: nombre, apellido, email, teléfono. Datos personales identificativos.
  • Campos sensibles: salud, ideología, situación económica detallada. Requieren protección reforzada.
  • Contexto conversacional: resumen de lo que el usuario habló con el Advisor.
  • Capa legal: marca de tiempo del consentimiento, versión aceptada.
• Versión final de política de privacidad del Advisor para enlace público. Requerida también para aprobación en marketplace.
• DPIA específica del flujo del Advisor. La DPIA (Data Protection Impact Assessment) es un documento formal requerido por RGPD para tratamientos nuevos o de alto riesgo. Secuoyas facilita y aporta criterio del sector; el DPO del cliente es quien formaliza el documento.

2.12Refinamiento del Advisor tras testing

• Ajuste de prompts que no se comportaron bien en testing.
• Recalibración del system prompt si el adversarial reveló debilidades.
• Refactor de tools que dieron error en condiciones de borde.
• Re-test focalizado post-ajustes.