Flujo de usuario: cómo GPT sugiere la App y llama a sus funciones

1. Introducción

Imagina que estás desarrollando un servicio web normal. Todo es sencillo: tienes la URL /search, el usuario pulsa un botón y llamas al controlador searchController. En el mundo de ChatGPT Apps el usuario no ve ningún /search. Escribe texto en lenguaje natural:

«Elige un regalo para mi hermano gamer por hasta 50$»

Y después:

• el modelo decide: «Oh, esto va de regalos; tengo GiftGenius, que sabe hacer eso»;
• GPT «pulsa los botones» por su cuenta: invoca las herramientas de tu App;
• a veces incluso le propone al usuario: «¿Quieres que abra GiftGenius y te muestre opciones?».

Cambio clave: el usuario expresa la intención y el modelo pulsa los botones. Si no entiendes este flujo, es muy fácil:

• crear herramientas con nombres sin sentido (run_func, doStuff),
• acabar con una App que nunca es sugerida por el modelo o se invoca fuera de lugar,
• crear un widget que «salta de la nada» y rompe la conversación.

Por eso en esta lección formamos el modelo mental: cómo GPT se entera de tu App y en qué puntos de la conversación la «integra».

Insight: la aplicación es un complemento de ChatGPT

A diferencia de las apps del móvil o de una mini-app en WeChat, las aplicaciones en ChatGPT funcionan de otra manera.

ChatGPT decide por sí mismo cuándo lanzar tu aplicación y qué función llamar. Las aplicaciones en ChatGPT pueden intervenir activamente (aunque con límites) en la lógica del chat. Su objetivo principal y su mayor fortaleza — ampliar las capacidades del propio ChatGPT.

Si ChatGPT puede resolver perfectamente el problema del usuario, no necesita llamar a tu aplicación. Si ChatGPT no puede resolver en absoluto el problema del usuario, este ni siquiera lo preguntará. El caso ideal es cuando ChatGPT solo puede resolver la petición del usuario parcialmente. Eso significa que peticiones hay, y muchas, pero el resultado es insuficiente.

Justo entonces ChatGPT llama a tu aplicación y entre los dos hacéis feliz al usuario. El usuario se vuelve más feliz y tú — más rico.

2. Formas de iniciar una ChatGPT App desde la mirada del usuario

El usuario no tiene un botón de «invocar el servidor MCP y call_tool», pero sí un campo de texto y (a veces) un menú de aplicaciones. Desde su punto de vista hay dos esquemas básicos de inicio: explícito e implícito.

Inicio explícito (explicit)

Es el escenario en el que el usuario elige conscientemente tu App.

Variantes típicas:

• la encuentra en el Store de ChatGPT y pulsa «Abrir»;
• la elige en el launcher (por ejemplo, con el botón + en el campo de entrada de texto, el Composer);
• empieza el mensaje con el nombre de la aplicación: «GiftGenius, elige un regalo…» — a esto se le llama named mention. Si el nombre de la App está al principio del prompt, ChatGPT mezcla automáticamente tu App en el contexto de la respuesta.

En el modo explícito el modelo sabe desde el principio: el usuario ha venido a trabajar con esa App. Por tanto:

• GPT llama más a menudo y más activamente a tus tools;
• el widget de UI de tu App puede aparecer ya en la primera respuesta;
• GPT ignora con menos frecuencia la App para responder «por sus propios medios».

Ejemplo favorito: el usuario abre GiftGenius directamente porque quiere «jugar» con la selección de regalos. Pulsa en la App en la lista y GPT muestra un saludo del estilo:

«¡Hola! Soy GiftGenius, te ayudaré a elegir un regalo. ¿Para quién y con qué presupuesto buscamos?»

Y a partir de ahí usa activamente tus herramientas de búsqueda.

Inicio implícito (implicit / suggested)

Un escenario totalmente distinto: el usuario ni piensa en la App. Simplemente escribe en un chat normal:

«Elige un regalo para el cumpleaños de mi madre; le encanta la jardinería; presupuesto hasta 100$»

GPT analiza la petición y ve que:

• en el ecosistema existe la App GiftGenius, cuyas herramientas están descritas como «Use this when the user wants to get gift recommendations»;
• las tareas y las restricciones (regalo, presupuesto, intereses) encajan muy bien con esa App.

En ese caso el modelo puede «colarse con discreción» con una sugerencia:

«Puedo usar la aplicación GiftGenius para seleccionar opciones concretas de regalo y mostrarlas como tarjetas. ¿La abro?»

Si el usuario acepta, GPT invoca la herramienta necesaria de la App y, posiblemente, renderiza tu widget.

Lo importante es que tú no escribes en ningún sitio if (prompt.includes("regalo")) openApp(). El modelo toma la decisión por sí mismo, basándose en:

• el texto de la petición y el historial del diálogo;
• los metadatos de tus herramientas (nombres, descripciones, esquemas de parámetros);
• el estado del vínculo del usuario con la App (si está autenticado o no), si es usuario corporativo o no.

Influyes no en el algoritmo, sino en cómo están «descritos» para el modelo tu App y sus tools.

Híbrido: cuando GPT primero aclara y luego sugiere la App

A veces el usuario escribe algo muy general:

«Hay que pensar en algo para un colega; no tengo ni idea de qué»

El modelo entiende que GiftGenius puede ayudar, pero la información es demasiado vaga. Un patrón frecuente:

1. GPT formula 1–2 preguntas de aclaración en texto.
2. Después propone abrir la App: «Tengo una herramienta para elegir regalos. ¿Quieres que la abra y te muestre opciones?».

Es un buen UX: el usuario no siente que lo han «forzado a pasar a otra aplicación».

3. Discovery: cómo GPT encuentra tu App

Ahora veamos cómo se ve todo esto desde el punto de vista del propio modelo.

En la documentación del Apps SDK esto se llama Discovery — todos los modos en los que el usuario y el modelo se enteran de tu App. Incluye tanto peticiones naturales en el chat como el catálogo de aplicaciones, y puntos de entrada especiales como el launcher.

De dónde sabe el modelo que tu App existe

Durante el registro ChatGPT lanza tu App y esta (a través de MCP) cuenta sobre sí misma: enumera las herramientas disponibles con sus esquemas — nombre, descripción y esquema JSON de los parámetros de entrada. La información de la aplicación habrá que indicarla al registrar, y la información sobre las herramientas ChatGPT la obtendrá automáticamente mediante el método MCP list_tools.

El modelo no ve tu código fuente, solo tiene acceso a:

• el nombre de la herramienta (name);
• la descripción (description);
• la firma de entrada (inputSchema).

Eso es precisamente «la API para el modelo». Si llamas a la herramienta run_func con la descripción «Executes the function», el modelo no entenderá cuándo invocarla. Si la llamas suggest_gifts con la descripción «Use this when the user wants gift ideas based on recipient, occasion and budget», todo se vuelve transparente.

Named mention e in‑conversation discovery

La especificación oficial del Apps SDK distingue dos mecanismos clave:

• Named mention — cuando el usuario empieza el mensaje con el nombre de tu App. En este caso la App casi con seguridad se activará y se usará en la respuesta.
• In‑conversation discovery — cuando el usuario simplemente escribe una petición y el modelo decide si conectar la App. Para ello se tienen en cuenta:
  • el contexto de la conversación (historial de mensajes, resultados de tools previas, preferencias del usuario);
  • menciones explícitas de marca en el texto;
  • los metadatos de tus tools — nombres, descripciones, documentación de parámetros;
  • el estado del «link» — si el usuario está conectado a la App (autenticado, si los permisos necesarios están concedidos).

El desarrollador influye en este proceso de forma indirecta: con metadatos de calidad y patrones de UX, no con if/else en el código.

Catálogo y launcher

Además del modo conversacional, existe también la Store dentro de ChatGPT y el launcher, accesible desde el composer. A través de ellos los usuarios pueden elegir explícitamente una App, como en una tienda de aplicaciones normal.

Para nosotros esto es importante a nivel conceptual: al diseñar el flujo de GiftGenius, debemos recordar que:

• alguien entrará por el catálogo y caerá directamente «dentro» de la App;
• alguien nunca navegará por el catálogo y verá la App solo como sugerencia en el diálogo.

Todo esto trata del discovery de la propia App: los momentos en que el modelo decide si «levantar» tu aplicación y ofrecérsela al usuario en la conversación actual.

4. Anatomía del ciclo de interacción: de la frase al widget

Hora de juntar todos los niveles de la lección anterior — desde el UI de ChatGPT y el widget hasta el Apps SDK y el servidor MCP — en un ciclo lógico claro.

Esquema de alto nivel

Desde el punto de vista del proceso, el ciclo se ve así:

sequenceDiagram
    participant U as Usuario
    participant G as ChatGPT (modelo)
    participant A as App / servidor MCP

    U->>G: Consulta en texto
    G->>G: Análisis de la solicitud + selección de herramientas
    G->>A: Llamada a la herramienta (call_tool)
    A-->>G: Respuesta (datos / structuredContent)
    G->>U: Respuesta de texto + (opcional) widget de la App

En lenguaje humano:

1. El usuario escribe un mensaje en ChatGPT.
2. El modelo analiza la petición y el contexto actual, y decide:
   • si responder por sí mismo,
   • o invocar una o varias herramientas.
3. Si se elige una herramienta de tu App, ChatGPT forma una petición estructurada (call_tool) y la envía al servidor MCP.
4. Tu backend (o servidor MCP) ejecuta la acción: consulta la base de datos, APIs externas, ACP, etc., y forma el resultado.
5. El resultado vuelve en forma de datos estructurados (y, quizá, JSON para el widget).
6. El modelo usa esos datos para:
   • generar un texto comprensible para el usuario,
   • y, si es necesario, renderizar el widget de la App directamente en la respuesta.

Toda la planificación multietapa — «cuándo llamar a qué», «si pedir una aclaración», «si hacer otra llamada» — está del lado del modelo de IA. El Apps SDK y MCP solo proporcionan un contrato unificado para las herramientas.

Dónde escribimos código aquí

En este ciclo hay tres puntos donde realmente escribes TypeScript/código:

1. Configuración de la App y de las herramientas — descripciones de los tools (nombre, descripción, esquema) y metadatos de la App (nombre, icono, categorías). En tu proyecto será, probablemente, un archivo tipo openai/app-config.ts.
2. Servidor MCP / backend — manejo de call_tool: ir a la BD, filtrar productos, llamar a otras APIs, etc.
3. Widget (UI) — componente React en una aplicación Next.js, que se renderiza en el chat y lee los resultados de las herramientas a través de window.openai o hooks del Apps SDK.

Todo lo demás — es cosa del modelo y de la plataforma.

5. GiftGenius en acción: dos escenarios del flujo de usuario

Pasemos a escenarios más concretos para que puedas «ver» este flujo.

Escenario 1: el usuario abre GiftGenius de forma explícita

Escenario:

1. El usuario en ChatGPT abre el catálogo de Apps y encuentra GiftGenius.
2. Pulsa «Abrir».
3. ChatGPT inicia la conversación ya en el contexto de GiftGenius.

El diálogo sería algo así:

Usuario:

Abre GiftGenius desde el catálogo.
Y escribe: «¡Hola! Quiero elegir un regalo para un amigo»

GPT:

«Perfecto, te ayudo a elegir un regalo. ¿Para quién, con qué presupuesto y con qué motivo estás buscando?»

En este paso GPT puede llamar ya a la primera herramienta, por ejemplo start_gift_session, para inicializar una sesión en tu backend (crear un carrito temporal, generar un sessionId, etc.).

Tu código del lado del servidor MCP puede tener este aspecto (muy esquemático):

// Pseudo-ejemplo future-TS: descripción de la herramienta GiftGenius
const suggestGiftsTool = {
  name: "suggest_gifts",
  description: "Use this when the user wants gift ideas by recipient, occasion and budget",
  inputSchema: {
    type: "object",
    properties: {
      recipient: { type: "string" },
      occasion: { type: "string" },
      budgetUsd: { type: "number" },
    },
    required: ["recipient", "occasion", "budgetUsd"],
  },
};
    

En detalle, cómo se registra en MCP/Apps SDK lo veremos en otro módulo; ahora nos importa la idea: con esta descripción el modelo entiende que la herramienta sirve para peticiones de «selección de regalos».

Tras la respuesta del usuario, GPT llama a suggest_gifts, recibe de ti un array de opciones y luego:

• las resume en texto;
• incrusta el widget de GiftGenius, donde se pueden hojear y filtrar las tarjetas de regalos.

Escenario 2: el usuario pide «elige un regalo» en un chat normal

Ahora otro caso: el usuario no sabe nada de GiftGenius.

Escribe en un chat normal:

«Necesito un regalo para mi hermano; le encantan los juegos de mesa; máximo 50$»

Dentro de ChatGPT pasa, aproximadamente, lo siguiente:

1. El modelo analiza la petición y la lista de herramientas disponibles.
2. Ve la herramienta suggest_gifts con una descripción adecuada.
3. Entiende que la App GiftGenius está hecha precisamente para estas tareas.
4. Comprueba si el usuario ya instaló esa aplicación, si está autenticado, qué permisos ha concedido.

El comportamiento posterior puede variar:

• si la petición es lo bastante concreta, GPT puede invocar en silencio suggest_gifts y devolver una respuesta con el widget;
• si falta algo (por ejemplo, no se indica el motivo o la edad), GPT puede pedir primero una aclaración en texto y luego sugerir la App.

Esta flexibilidad —es lo que diferencia a las Apps de UIs «rígidas» con formularios: el modelo elige cuándo usar herramientas y cuándo conversar.

6. Enrutamiento semántico: «un LLM como despachador»

En el nivel de discovery el modelo decide si conectar tu App a la petición actual. Pero después, cuando la App ya está «levantada» y sus herramientas son conocidas por el modelo en la sesión, entra un segundo nivel — el enrutamiento semántico dentro de esos tools: qué herramienta concreta debe procesar la siguiente réplica.

En un backend web clásico la ruta se elige por URL: /checkout — entonces se llama al controlador de checkout. En ChatGPT Apps no hay enrutamiento por URL, pero sí enrutamiento semántico: el modelo compara el significado de la petición con las descripciones de tus herramientas.

Simplificando, el proceso es este:

1. Al iniciar la sesión ChatGPT recibe la lista de tools: sus nombres, descripciones y esquemas.
2. Estos datos se integran en las instrucciones del sistema para el modelo.
3. Cuando el usuario escribe una petición, el modelo compara su significado con las descripciones de las herramientas: dónde «selección de regalos», dónde «búsqueda de hoteles», dónde «dibujar un gráfico».
4. Si encuentra una buena coincidencia, forma una llamada estructurada a la herramienta necesaria.

De aquí se desprende la conclusión práctica principal:

• la descripción de la herramienta es tu API para el modelo; vuelve a leerlo. Y otra vez.
• si escribes «does stuff», el modelo de verdad no entenderá cuándo invocarla.

La documentación y las mejores prácticas sobre discovery subrayan: a los metadatos hay que tratarlos como trabajo de copywriting de producto. Son ellos los que determinan en qué conversaciones el modelo recordará tu App.

7. Patrones de diálogo en torno a la App

Ahora veamos patrones de UX típicos que surgen cuando GPT interactúa con una App dentro de una misma conversación. Es importante para no construir tu App «en el vacío», sin entender el papel de la parte GPT.

Todas las guías prácticas del Apps SDK destacan varios patrones característicos:

«El asistente» (The Wizard)

GPT guía al usuario paso a paso, apoyándose a menudo en la App.

Con GiftGenius como ejemplo:

1. GPT: «Cuéntame, ¿para quién es el regalo?»
2. Usuario: «Mi hermano, 25 años, le encantan los juegos de mesa».
3. GPT: «¿Qué presupuesto?»
4. Usuario: «Hasta 50$».
5. GPT invoca suggest_gifts, muestra resultados en el widget y escribe: «He elegido varias opciones; échales un vistazo en la lista de abajo».

En este patrón la App y su widget son una capa visual sobre un diálogo de varios pasos. El usuario escribe la mayor parte del tiempo, y el widget ayuda a visualizar la elección.

«Widget adaptativo» (The Adaptive Widget)

El texto sigue siendo el canal principal y la App se conecta puntualmente para tareas especiales: dibujar un gráfico, mostrar una tabla, renderizar tarjetas de productos.

Ejemplo:

• Usuario: «Compara tres opciones de regalo: un juego de mesa, un libro y una experiencia».
• GPT primero explica en texto pros y contras.
• Después invoca una herramienta que devuelve una lista de productos estructurada y renderiza una pequeña tabla o tarjetas.

Aquí la App es un complemento visual, no el «modo por defecto».

«Agente invisible» (Invisible Agent)

La App puede no mostrar ningún UI. Funciona «bajo el capó» como fuente de datos:

• implementas un MCP‑tool que busca regalos en tu BD;
• GPT lo invoca, obtiene la lista y ya él mismo resume los resultados en texto, sin ningún widget.

Se parece a un «plugin sin UI» clásico: el usuario solo ve que GPT conoce precios y surtido actualizados.

Este patrón es útil para Apps tool‑first, donde el UI no es crítico.

8. Cómo el flujo influye en el diseño de la App

Entender el flujo importa no solo para la filosofía, sino para decisiones muy prácticas: qué herramientas crear, cómo describirlas, cuándo mostrar un widget y cuándo es mejor responder en texto.

Principio «chat‑first»

La idea clave del ecosistema: el chat es el canal principal de interacción y los componentes de UI son auxiliares.

Esto significa:

• no intentes meter «todo un sitio» en un único widget;
• los widgets deben ayudar donde el chat es incómodo: selección en listas, filtrado, comparación, formularios complejos.

Para GiftGenius esto es:

• elegir una lista de regalos y dejar que el usuario «toque» las tarjetas;
• visualizar filtros (precio, categoría, disponibilidad);
• ayudar a tramitar el pedido (checkout) en unos pocos pasos claros.

Pero escribir en el widget largas explicaciones de «cómo elegir un regalo para una chica introvertida» no es buena idea; eso es tarea del chat.

Cuándo lanzar la App y cuándo no

Otra consecuencia: no conviertas tu App en «la invasora del diálogo».

Patrón malo:

• el usuario mantiene una conversación seria;
• la App se lanza y abre un widget a pantalla completa sin avisar;
• el usuario se pierde: «¿dónde ha ido mi chat?».

Mejor:

• primero discutir todo en texto, hacer un par de aclaraciones;
• luego sugerir abrir la App suavemente si realmente mejora el UX (comparación, configuración, checkout).

Impacto en el conjunto de herramientas

Como el modelo elige la herramienta por su descripción, cada herramienta debe:

• resolver una tarea clara;
• estar bien descrita al estilo «Use this when…»;
• tener parámetros que surjan de forma natural de las preguntas que GPT hará al usuario.

Para GiftGenius, en lugar de un do_everything gigantesco, es más lógico tener:

• suggest_gifts — selección de una lista de opciones;
• get_gift_details — detalles de un ID concreto;
• create_order — formalización del pedido.

Diseñaremos las herramientas en detalle en el módulo 4, pero la idea general ya importa: el flujo del diálogo determina qué herramientas hacen falta.

9. Mini‑ejemplo: cómo las descripciones de tools influyen en el flujo (boceto TypeScript)

Un pequeño fragmento de un imaginario openai/app-config.ts, para conectar teoría y código. No lo tomes como sintaxis exacta del SDK (lo veremos en el siguiente módulo): ahora nos importa la idea de los nombres y las descripciones.

// Fragmento condicional de configuración de GiftGenius (código futuro)
const tools = [
  {
    name: "suggest_gifts",
    description: "Use this when the user wants gift ideas based on recipient, occasion, and budget.",
    inputSchema: {/* ... */},
  },
  {
    name: "get_gift_details",
    description: "Use this when the user asks for more information about a specific gift from a previous list.",
    inputSchema: {/* ... */},
  },
];

Si sustituyes suggest_gifts por run_func y la descripción por «Main function», GPT:

• entenderá peor para qué peticiones conviene llamar a esa herramienta;
• puede sugerir tu App con menos frecuencia en in‑conversation discovery;
• le costará más vincular los follow‑ups del usuario con la lista de regalos ya mostrada.

Y al contrario, buenos nombres y descripciones aumentan la probabilidad de que tu App aparezca justo en el momento adecuado.

10. Errores típicos al diseñar el flujo de usuario

Error n.º 1: Esperar control total — «yo decidiré cuándo lanzar la App».
A veces los desarrolladores piensan en la parádi gma «captaré todas las peticiones sobre regalos y conectaré mi App». En el mundo de ChatGPT Apps no es así: las decisiones las toma el modelo. Tiene en cuenta las descripciones de las herramientas, el contexto del diálogo, el estado de los permisos y cuánto satisface al usuario invocar precisamente tu App.

Error n.º 2: Nombres y descripciones sin sentido para las herramientas.
Herramientas con nombres como run, main, tool1 y descripciones como «Calls the main function» crean la tormenta perfecta: el modelo no entiende cuándo invocarlas, el in‑conversation discovery prácticamente no funciona y tu App se vuelve «invisible». Una buena descripción al estilo «Use this when the user wants…» y un nombre claro son mucho más importantes de lo que puede parecer.

Error n.º 3: Intentar meter «de todo» en una sola App.
Si tu App a la vez «elige regalos, reserva hoteles, calcula impuestos y muestra gatitos», el modelo no podrá enrutar de forma fiable las peticiones. Las recomendaciones oficiales y guías prácticas subrayan el principio «one clear job per tool/App»: mejor varias aplicaciones especializadas que un megamonolito.

Error n.º 4: Autoarranque agresivo de un UI pesado.
El desarrollador está orgulloso de su precioso widget a pantalla completa y quiere mostrarlo «por cualquier motivo». El resultado es que al usuario le parece que el chat «se rompe» y se convierte en una web extraña. Mucho mejor cuando GPT primero conversa en texto, hace preguntas de aclaración y solo después sugiere abrir la App, explicando para qué sirve.

Error n.º 5: Ignorar el papel de GPT como capa de UX.
Se puede diseñar la App como un SPA típico: hacerlo todo en el widget y que ChatGPT «se calle y no moleste». Pero no funcionará. ChatGPT puede no mostrar tu widget, o mostrar un widget nuevo en cada llamada a una herramienta. Si quieres un producto exitoso, adáptate a la plataforma; no esperes que ella se adapte a ti.