Comece listando o que as pessoas esperam que seu plug-in faça. O nome, a descrição, as habilidades, as ferramentas e a conexão do plug-in com um produto existente criam expectativas. Sua implementação deve atender a essas expectativas ou ter um motivo deliberado para não atendê-las.
Esse trabalho determina o que incluir no plug-in:
- Adicione uma habilidade quando instruções, exemplos ou recursos incluídos puderem guiar o modelo pelo fluxo de trabalho.
- Adicione um servidor MCP quando o fluxo de trabalho precisar de dados em tempo real, autenticação, ferramentas controladas ou código executado em uma infraestrutura que você opera.
- Adicione uma interface ao servidor MCP somente quando a interação visual melhorar de forma significativa parte do fluxo de trabalho.
Comece pelas expectativas dos usuários
Imagine que uma pessoa instalou seu plug-in, mas não leu a documentação. O que seria razoável ela pedir que ele fizesse?
Reúna possíveis solicitações com base em:
- Tarefas que as pessoas já realizam no seu produto ou serviço.
- Entrevistas com usuários, solicitações de suporte, consultas de pesquisa e pedidos de recursos.
- Termos comuns que as pessoas usam para se referir ao seu produto, aos dados e aos fluxos de trabalho.
- Soluções alternativas existentes que exigem copiar dados entre ferramentas.
- Nome, página de apresentação, capturas de tela e prompts iniciais do plug-in.
Inclua solicitações diretas que mencionem seu plug-in e solicitações indiretas que expressem o objetivo. Por exemplo, um plug-in de gerenciamento de projetos pode precisar atender tanto a “Mostre meu quadro de lançamento da Acme” quanto a “O que está impedindo o lançamento?”.
Não limite as ideias aos fluxos de trabalho compatíveis com sua API atual. Primeiro, registre o que as pessoas vão esperar. Depois, compare essas expectativas com o que você pode oferecer com segurança e confiabilidade.
Monte um inventário de casos de uso
Para cada caso de uso, registre:
| Campo | Pergunta a responder |
|---|---|
| Objetivo do usuário | O que a pessoa está tentando realizar? |
| Exemplos de solicitações | Como ela poderia pedir isso de forma direta ou indireta? |
| Resultado esperado | O que faria a interação ser bem-sucedida? |
| Contexto necessário | Quais informações, acessos a contas ou estados prévios são necessários? |
| Capacidade do plug-in | Uma habilidade consegue atender ao caso de uso ou é necessária uma ferramenta MCP? |
| Limite de segurança | Isso poderia expor dados, alterar o estado, gastar dinheiro ou afetar outra pessoa? |
| Decisão sobre suporte | A primeira versão oferecerá suporte a esse caso de uso, deixará para depois ou o excluirá intencionalmente? |
Agrupe solicitações com o mesmo objetivo. “Liste minhas tarefas em aberto”, “O que preciso fazer hoje?” e “Mostre o trabalho em atraso” podem fazer parte de um único caso de uso de revisão de tarefas com filtros diferentes, em vez de três recursos sem relação entre si.
Verifique a cobertura
Compare cada expectativa com as capacidades propostas para o plug-in:
- Confirme que cada caso de uso com suporte tenha um caminho completo, da solicitação até um resultado útil.
- Identifique habilidades, ferramentas, dados, permissões ou estados de erro que estejam faltando.
- Identifique ferramentas que disponibilizam operações técnicas sem atingir um objetivo claro do usuário.
- Verifique se as ações de escrita incluem autorização e confirmação adequadas.
- Verifique se o plug-in consegue explicar o que não pode fazer e oferecer um próximo passo útil.
Um plug-in não deve sugerir que tem capacidades amplas quando oferece suporte apenas a uma pequena parte do fluxo de trabalho esperado. Se os usuários conseguem criar projetos, mas não podem listá-los, inspecioná-los ou atualizá-los, adicione a cobertura que falta ou restrinja o posicionamento do plug-in.
Documente as exclusões intencionais
Você não precisa implementar todas as solicitações imagináveis. Deve haver um bom motivo para cada exclusão importante, como:
- A ação criaria um risco inaceitável à segurança ou à privacidade.
- O produto ou a API subjacente não oferece suporte confiável a ela.
- O fluxo de trabalho exige permissões que o plug-in não consegue verificar.
- O resultado seria enganoso sem informações às quais o plug-in não tem acesso.
- O caso de uso está fora do escopo da primeira versão, e a página de apresentação do plug-in deixa isso claro.
Registre essas decisões. Elas devem orientar os limites das habilidades, as descrições das ferramentas, o comportamento de recusa, os casos de teste e o texto da página pública de apresentação.
Transforme casos de uso em decisões de implementação
Para cada caso de uso com suporte, escolha a menor implementação capaz de atendê-lo por completo:
- Crie uma habilidade para instruções e recursos reutilizáveis.
- Crie um servidor MCP para dados em tempo real e ações controladas.
- Adicione uma interface ao servidor MCP quando as pessoas precisarem inspecionar, comparar, editar, confirmar ou navegar por informações estruturadas.
Use o inventário de casos de uso como plano de testes. Adicione solicitações representativas que sejam diretas, indiretas, de casos extremos e fora do escopo. Depois, verifique se o plug-in pronto se comporta como esperado em cada uma delas.
Se o plug-in precisar de dados em tempo real ou ações controladas, prossiga para Defina ferramentas.