Empieza por enumerar lo que las personas esperarán que haga tu complemento. Su nombre, su descripción, sus habilidades, sus herramientas y su conexión con un producto existente generan expectativas. Tu implementación debería cumplirlas. Si decides dejar alguna sin cubrir, deberías tener un motivo para hacerlo.
Este análisis te ayuda a decidir qué incluir en el complemento:
- Agrega una habilidad cuando las instrucciones, los ejemplos o los recursos incluidos puedan guiar al modelo a lo largo del flujo de trabajo.
- Agrega un servidor MCP cuando el flujo de trabajo necesite datos en tiempo real, autenticación, herramientas con controles de acceso o código que se ejecute en infraestructura que administras.
- Agrega una interfaz de usuario al servidor MCP solo cuando la interacción visual mejore de forma significativa alguna parte del flujo de trabajo.
Parte de las expectativas de los usuarios
Imagina que alguien instaló tu complemento, pero aún no leyó la documentación. ¿Qué sería razonable que le pidiera?
Recopila posibles solicitudes a partir de estas fuentes:
- Las tareas que las personas ya realizan en tu producto o servicio.
- Las entrevistas con usuarios, las solicitudes de soporte, las consultas de búsqueda y las solicitudes de nuevas funciones.
- Los términos que las personas suelen usar para referirse a tu producto, a los datos y a los flujos de trabajo.
- Las soluciones alternativas que hoy requieren copiar datos de una herramienta a otra.
- El nombre del complemento, su ficha y los prompts iniciales.
Incluye solicitudes directas que mencionen tu complemento y solicitudes indirectas que expresen el objetivo. Por ejemplo, un complemento de gestión de proyectos podría tener que responder tanto a “Muéstrame mi tablero de lanzamiento de Acme” como a “¿Qué está bloqueando el lanzamiento?”.
Al generar ideas, no te limites a los flujos de trabajo que admite tu API actual. Primero, anota lo que las personas esperarán del complemento. Luego, compara esas expectativas con lo que puedes ofrecer de forma segura y confiable.
Crea un inventario de casos de uso
Para cada caso de uso, registra lo siguiente:
| Campo | Pregunta que debes responder |
|---|---|
| Objetivo del usuario | ¿Qué quiere lograr la persona? |
| Ejemplos de solicitudes | ¿Cómo podría pedirlo de forma directa o indirecta? |
| Resultado esperado | ¿Qué resultado haría que la interacción fuera exitosa? |
| Contexto necesario | ¿Qué información, acceso a cuentas o estado previo se necesita? |
| Capacidad del complemento | ¿Basta con una habilidad o se necesita una herramienta MCP? |
| Límite de seguridad | ¿Podría exponer datos, cambiar el estado, gastar dinero o afectar a otra persona? |
| Decisión sobre el alcance | ¿Vas a incluir este caso en la primera versión, posponerlo o excluirlo deliberadamente? |
Agrupa las solicitudes que tengan el mismo objetivo. “Enumera mis tareas abiertas”, “¿Qué tengo que hacer hoy?” y “Muéstrame las tareas vencidas” podrían corresponder a un solo caso de uso de revisión de tareas con distintos filtros, en lugar de constituir tres funciones independientes.
Comprueba la cobertura
Compara cada expectativa con las capacidades propuestas para el complemento:
- Confirma que, para cada caso de uso admitido, el complemento pueda completar todos los pasos desde la solicitud hasta obtener un resultado útil.
- Identifica qué habilidades, herramientas, datos, permisos o estados de error faltan.
- Busca herramientas que ofrezcan operaciones técnicas sin que el usuario pueda alcanzar con ellas un objetivo concreto.
- Verifica que las acciones de escritura incluyan los mecanismos de autorización y confirmación adecuados.
- Comprueba que el complemento pueda explicar qué acciones no puede realizar y sugerir un siguiente paso útil.
Si el complemento solo cubre una pequeña parte del flujo de trabajo esperado, evita presentarlo como si ofreciera funciones más amplias. Si los usuarios pueden crear proyectos, pero no pueden listarlos, inspeccionarlos ni actualizarlos, agrega las funciones que faltan o describe el complemento con un alcance más limitado.
Documenta las exclusiones deliberadas
No necesitas implementar todas las solicitudes imaginables. Deberías tener un buen motivo para cada exclusión importante. Por ejemplo:
- La acción supondría un riesgo inaceptable para la seguridad o la privacidad.
- El producto o la API en que se basa el complemento no admite la acción de forma confiable.
- El flujo de trabajo requiere permisos que el complemento no puede verificar.
- El resultado sería engañoso sin información a la que el complemento no tiene acceso.
- El caso de uso queda fuera del alcance de la primera versión y la ficha del complemento lo deja claro.
Registra estas decisiones. Úsalas para definir el alcance de las habilidades, las descripciones de las herramientas, la forma en que el complemento rechaza solicitudes, los casos de prueba y el texto de la ficha pública.
Decide qué implementar para cada caso de uso
Para cada caso de uso admitido, elige la implementación más sencilla que permita completarlo:
- Crea una habilidad para las instrucciones y los recursos que se usan de forma recurrente.
- Crea un servidor MCP para acceder a datos en tiempo real y ejecutar acciones controladas.
- Agrega una interfaz de usuario al servidor MCP cuando las personas necesiten inspeccionar, comparar, editar, confirmar o explorar información estructurada.
Conserva el inventario de casos de uso como plan de pruebas. Agrega ejemplos representativos de solicitudes directas, indirectas, de casos límite y fuera de alcance. Luego, verifica que el complemento terminado responda a cada una como se espera.
Si el complemento necesita datos en tiempo real o acciones controladas, continúa con Define las herramientas.