MCP no Tigy: como conectar ferramentas a agentes de voz

Escolha as ações necessárias

MCP, ou Model Context Protocol, é um protocolo para conectar aplicações a ferramentas e recursos oferecidos por servidores compatíveis. No Tigy AI, uma ferramenta MCP permite ao agente usar ações de um servidor externo. Inspecione nomes, descrições, parâmetros e permissões antes de selecionar o catálogo; a presença de uma ação não significa que ela seja adequada ao atendimento.

O servidor externo precisa oferecer a operação. Descrever uma ação no prompt não faz uma ferramenta ausente aparecer no catálogo.

Configure e confira a descoberta

Peça ao responsável pela integração o endereço completo do servidor MCP e a chave de acesso, quando exigida. No Tigy, crie a ferramenta na categoria MCP, preencha esses valores e selecione quais ações devem aparecer. Salve, atualize o catálogo e associe a integração ao agente.

Se uma ação não aparecer, confira se o filtro a excluiu e atualize o catálogo. Se a conexão falhar, envie a mensagem de erro ao responsável pela integração para que verifique se o servidor está disponível e acessível ao Tigy. Não compartilhe a chave de acesso junto do relato.

Teste entradas e resultados

Explique nas instruções quando usar cada ação e quais dados obter primeiro. Faça uma pergunta que exija a ferramenta, revise seus parâmetros e confira a resposta no sistema externo.

Teste também autenticação recusada, registro inexistente e retorno incompleto. Para ações que modificam dados, use permissões e registros de teste adequados. O filtro do catálogo não substitui a autorização do servidor.

Teste uma ferramenta conhecida antes de ampliar o catálogo

Comece com uma consulta cujo resultado de teste você conhece. Peça a informação de duas maneiras, omita um parâmetro e corrija um valor durante a conversa. Confira se o agente seleciona a ferramenta esperada e se usa a correção mais recente.

Depois simule retorno vazio e indisponibilidade. A resposta deve explicar o limite e oferecer o caminho definido pela operação. Não aceite uma resposta plausível como substituto da evidência de consulta. Quando houver escrita, confira a mudança no sistema externo e a proteção contra repetição.

Registre a configuração do servidor e o conjunto de ferramentas exposto durante o teste. Se o servidor atualizar descrições ou parâmetros, repita a avaliação. Compatibilidade de protocolo não garante estabilidade do contrato de negócio. Credenciais válidas também não comprovam que o agente deve ter acesso a todos os recursos disponíveis.

Quando escolher MCP e quando usar HTTP

Escolha a conexão que sua equipe consegue manter e testar. Se a empresa já tem um servidor MCP com as ações necessárias, ele pode oferecer um catálogo organizado de ferramentas. Se a necessidade é uma única consulta ou alteração em um sistema, uma ferramenta HTTP pode ser mais direta. Peça à equipe de integração que confirme qual opção atende ao caso.

Compare descoberta, autenticação, validação, observabilidade e manutenção. Não escolha apenas pela quantidade de recursos anunciados. O melhor caminho é aquele em que você consegue explicar qual ação ocorre, com quais parâmetros e como o erro aparece para a conversa.

MCP não elimina a necessidade de um adaptador quando o sistema externo exige transformação de dados ou regras próprias. Documente onde essa lógica vive. Ao investigar uma falha, separe seleção da ferramenta, transporte, autorização e operação; alterar o prompt não resolve todas essas camadas.

Inspecione o catálogo antes de escrever o prompt

Um servidor MCP oferece ações que o agente pode usar, mas sua presença não significa que toda necessidade da conversa está atendida. Inspecione o catálogo disponível e identifique a ação concreta para cada tarefa. Uma consulta de pedido exige uma ferramenta que consulte pedido; uma criação de contato exige uma ação de escrita com contrato próprio. Não peça ao agente que improvise uma operação ausente.

No Tigy, a configuração de ferramentas MCP recebe a URL completa do servidor, a credencial quando necessária e um filtro de catálogo. Depois de salvar, atualize o catálogo e examine as ações descobertas. Confirme a associação ao agente testado. Uma conexão criada no workspace não prova que uma conversa específica tem acesso às ações necessárias.

Leia nome, descrição e parâmetros de cada ação selecionada. Esses elementos precisam permitir que o modelo distinga consultas e alterações. Uma descrição genérica pode levar à escolha errada, mesmo quando a conexão está correta. Se você controla o servidor, melhore o contrato; se não controla, restrinja o conjunto e escreva instruções coerentes com as capacidades efetivas.

Considere um servidor fictício que oferece busca de contato e criação de contato. Uma pessoa pede para confirmar se já está cadastrada. A tarefa correta começa pela busca, com os requisitos aprovados. Criar um novo contato porque a descrição é mais clara produz um efeito diferente da intenção. O teste deve verificar a ação escolhida, não somente a resposta falada.

Quando o catálogo muda, atualize-o antes de testar. Uma ação removida ou um parâmetro novo pode tornar instruções antigas incompatíveis. Registre quais tarefas dependem desse servidor e mantenha uma verificação de compatibilidade. A estabilidade da conversa depende do contrato de ferramentas que ela realmente encontra.

Restrinja o catálogo e autorize no servidor

O filtro ajuda a selecionar ações relevantes, mas não substitui autorização. A documentação do Tigy faz essa distinção. O sistema externo precisa controlar quais dados a conta pode consultar e quais alterações pode executar. Se uma ferramenta aceita um identificador, isso não significa que qualquer identificador citado pelo cliente deva ser autorizado.

Escolha acesso proporcional ao piloto. Para avaliar consultas, uma credencial de leitura limitada aos registros de ensaio costuma ser mais adequada que uma conta capaz de alterar toda a operação. O responsável pelo servidor define as permissões, e a configuração do agente deve respeitar esse recorte. Não acrescente acesso amplo apenas para evitar um erro de permissão no teste.

Separe ações com efeitos distintos. Buscar disponibilidade, criar reserva e cancelar reserva não devem ser tratadas como capacidade única. Cada uma exige dados, condições e confirmação próprias. O prompt orienta quando usar; o servidor valida se pode ocorrer. Essa divisão preserva controle mesmo quando a conversa recebe uma solicitação insistente.

Não coloque credenciais no prompt nem em exemplos. Use a configuração de autenticação apropriada. O agente precisa conhecer o propósito da ferramenta, não o segredo que permite acesso. Se a autenticação falha, investigue seleção de credencial, formato e permissão no sistema externo. Pedir ao cliente que repita sua solicitação não corrige uma chave expirada.

Teste acesso negado como parte do contrato. O retorno deve permitir uma explicação compreensível sem expor detalhes internos ou dados de outro registro. A conversa deve reconhecer o limite e oferecer a alternativa aprovada. Não tente contornar a recusa chamando uma ação diferente que parece produzir o mesmo dado.

Confirme efeitos somente depois do retorno

Uma ferramenta MCP pode consultar dados ou produzir efeitos externos. Para escrita, a fala precisa depender do retorno. Uma pessoa concordar com a criação de um contato não prova que ele foi salvo. O agente deve seguir o contrato de resposta e diferenciar confirmado, recebido e pendente.

Defina antes do teste o que acontece sem resposta. A criação pode ter sido realizada mesmo que a conexão interrompa. O servidor precisa de uma forma de reconhecer repetição ou investigar o resultado. Repetir por tentativa e erro pode gerar duplicidade. A conversa explica a falta de confirmação, mas a prevenção do efeito duplicado pertence ao sistema responsável.

Considere uma correção durante a coleta. O cliente informa um email e depois substitui uma letra. A chamada deve enviar o valor novo. Se a correção acontece depois de uma ação enviada, o agente precisa verificar a capacidade de alteração em vez de anunciar que “corrigiu” apenas porque entendeu a frase. Intenção compreendida e estado persistido são coisas diferentes.

Teste também uma resposta externa com informação insuficiente. Um retorno que apenas aceita uma solicitação não autoriza anunciar o resultado final. Se a ação depende de processamento posterior, o próximo passo deve refletir isso e ter responsável. Uma integração assíncrona não se torna instantânea por causa da linguagem da conversa.

Investigue descoberta, execução e explicação separadamente

Quando a ação não aparece, revise catálogo atualizado e filtro. Quando aparece mas não executa, revise conexão, autenticação e parâmetros. Quando executa e a fala está errada, confira a interpretação do retorno. Separar essas etapas evita mudanças de prompt que deixam o contrato externo ainda mais confuso.

Prepare casos de sucesso, dado ausente, ferramenta não disponível, acesso negado e falha temporária. Para cada um, escreva a ação permitida e a resposta esperada. Depois de atualizar o servidor, repita o conjunto. Uma mudança aparentemente pequena pode alterar o significado de um campo ou de um estado retornado.

Use o guia de ferramentas MCP externas para conferir conexão, seleção e atualização do catálogo. Verifique quais ações do servidor foram selecionadas para o agente antes de testar seu uso durante uma chamada.

Revise o conjunto de ações antes de ampliar o piloto

Antes de liberar novas tarefas, compare o catálogo atual com o escopo aprovado. Uma ação nova pode estar disponível no servidor sem ser necessária ao agente. Atualize filtro e instruções com intenção, mantendo a regra de autorização no sistema externo. A descoberta de uma capacidade não é uma decisão automática de oferecê-la ao cliente.

Revise com a equipe um caso de consulta e outro de alteração. Ela deve conseguir explicar os dados mínimos, a confirmação e a saída quando o retorno não chega. Se essas condições ainda não estão claras, mantenha o recorte anterior até validar.