Empieza por enumerar lo que las personas esperarán que haga tu complemento. Su nombre, descripción, habilidades, herramientas y conexión con un producto existente generan expectativas. Tu implementación debería cumplir esas expectativas o tener una razón deliberada para no hacerlo.
Este trabajo determina 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 controladas o código que se ejecute en infraestructura que tú administras.
- Agrega una interfaz de usuario al servidor MCP solo cuando la interacción visual mejore de manera significativa una parte del flujo de trabajo.
Partir de las expectativas de los usuarios
Imagina que una persona instaló tu complemento, pero no leyó su documentación. ¿Qué sería razonable que le pidiera hacer?
Recopila posibles solicitudes a partir de:
- 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 funciones.
- Los términos habituales que las personas usan para referirse a tu producto, tus datos y tus flujos de trabajo.
- Las soluciones alternativas existentes que requieren copiar datos entre herramientas.
- El nombre del complemento, su ficha, las capturas de pantalla 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 necesitar responder tanto a “Muéstrame mi tablero de lanzamiento de Acme” como a “¿Qué está bloqueando el lanzamiento?”.
No limites las ideas a los flujos de trabajo que se ajusten a tu API actual. Primero, registra lo que las personas esperarán. Luego, compara esas expectativas con lo que puedes ofrecer de forma segura y confiable.
Crear un inventario de casos de uso
Para cada caso de uso, registra:
| Campo | Pregunta por responder |
|---|---|
| Objetivo del usuario | ¿Qué intenta lograr la persona? |
| Ejemplos de solicitudes | ¿Cómo podría pedirlo de forma directa o indirecta? |
| Resultado esperado | ¿Qué haría que la interacción fuera exitosa? |
| Contexto necesario | ¿Qué información, acceso a cuentas o estado previo se necesita? |
| Capacidad del complemento | ¿Puede resolverlo 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 de implementación | ¿Se incluirá en la primera versión, se pospondrá o se excluirá intencionalmente? |
Agrupa las solicitudes que compartan el mismo objetivo. “Enumera mis tareas abiertas”, “¿Qué tengo que hacer hoy?” y “Muestra el trabajo atrasado” pueden pertenecer a un solo caso de uso de revisión de tareas con distintos filtros, en lugar de ser tres funciones independientes.
Comprobar la cobertura
Contrasta cada expectativa con las capacidades propuestas para el complemento:
- Confirma que cada caso de uso admitido tenga un recorrido completo desde la solicitud hasta un resultado útil.
- Identifica las habilidades, herramientas, datos, permisos o estados de error que falten.
- Busca herramientas que ofrezcan operaciones técnicas sin cumplir un objetivo reconocible para el usuario.
- Verifica que las acciones de escritura incluyan la autorización y la confirmación adecuadas.
- Comprueba que el complemento pueda explicar lo que no puede hacer y ofrecer un siguiente paso útil.
Un complemento no debería dar a entender que tiene amplias capacidades si solo permite realizar una pequeña parte del flujo de trabajo esperado. Si los usuarios pueden crear proyectos, pero no pueden enumerarlos, inspeccionarlos ni actualizarlos, agrega las funciones que faltan o acota el alcance con el que presentas el complemento.
Documentar las exclusiones intencionales
No necesitas implementar todas las solicitudes imaginables. Deberías tener una buena razón para cada exclusión importante, por ejemplo:
- La acción generaría un riesgo inaceptable para la seguridad o la privacidad.
- El producto o la API subyacente no permite realizarla 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 puede acceder.
- El caso de uso queda fuera del alcance de la primera versión y la ficha del complemento lo deja claro.
Registra estas decisiones. Deberían orientar los límites de las habilidades, las descripciones de las herramientas, el comportamiento al rechazar solicitudes, los casos de prueba y el texto de la ficha pública.
Convertir los casos de uso en decisiones de desarrollo
Para cada caso de uso admitido, elige la implementación mínima que permita completarlo:
- Crea una habilidad para instrucciones y recursos reutilizables.
- Crea un servidor MCP para datos en tiempo real y acciones controladas.
- Agrega una interfaz de usuario al servidor MCP cuando las personas necesiten inspeccionar, comparar, editar, confirmar o navegar por información estructurada.
Conserva el inventario de casos de uso como plan de pruebas. Agrega solicitudes representativas que sean directas, indirectas, de casos límite y fuera de alcance. Luego, verifica que el complemento terminado se comporte según lo previsto en cada una.
Si el complemento necesita datos en tiempo real o acciones controladas, continúa con Definir herramientas.