Linhas de código coloridas sobre fundo escuro

Como expor seu produto ao agente do usuário com MCP?

Por luizeof|

Seu cliente pode ter um assistente para preparar a agenda e consultar os documentos do trabalho. Ao entrar no seu produto, porém, ele volta a procurar o contato em várias telas. Oferecer uma consulta por MCP permite que aquele assistente acesse uma tarefa da aplicação, sem exigir que você construa outra conversa dentro do produto para a mesma finalidade.

Eu começaria por uma consulta que já tem utilidade na interface. A integração deve oferecer ao assistente uma ação reconhecível, com um retorno que o cliente consiga conferir. Acrescentar ferramentas sem ligar cada uma a uma tarefa deixa a implementação pronta sem explicar por que alguém a usaria.

Direto ao ponto

O MCP (Model Context Protocol) permite expor ferramentas que um agente pode descobrir e chamar. A descrição informa a ação e suas entradas para que o agente prepare a chamada ao servidor, responsável por executar a consulta ou alteração na aplicação. O agente do cliente pode então utilizar essa ação durante uma conversa que já estava em andamento.

O produto continua aplicando suas permissões. A descrição da ferramenta explica o que ela faz, mas não autoriza uma consulta nem define a identidade do cliente. A implementação precisa usar o acesso correspondente à identidade autenticada pelo cliente.

Uma consulta útil fora das telas do produto

Considere um sistema hipotético de atendimento. O cliente quer saber o último assunto tratado com um contato para preparar a próxima reunião. Hoje ele abre o cadastro, localiza a conversa e lê o histórico. Uma ferramenta pode devolver o atendimento mais recente daquele contato, incluindo a data e uma referência para abrir a conversa original.

O assistente recebe essa informação enquanto prepara a reunião. Você mantém a consulta no produto e oferece outro modo de acessá-la. A referência para a conversa permite verificar o resultado quando o resumo estiver incompleto ou o cliente quiser ler a troca inteira. O artigo sobre classificação de conversas no Chatwoot com Jev distingue a interpretação da mensagem das ações posteriores no atendimento.

Para mim, esse acesso oferece uma razão concreta para criar a integração. O cliente utiliza a informação junto das outras tarefas que já acompanha pelo assistente. O benefício não exige que toda navegação da aplicação seja substituída por uma conversa.

A especificação de ferramentas do MCP descreve o nome da ferramenta, os esquemas das entradas e os resultados. Também determina validação e controle de acesso no servidor. Essas características permitem apresentar uma consulta utilizável pelo agente, com a execução mantida na aplicação.

API, terminal e ferramenta MCP

Uma interface de programação de aplicações, ou API, oferece acesso ao sistema para outras implementações. Uma ferramenta MCP apresenta uma ação ao agente e pode usar essa interface na execução. Você não precisa criar outra lógica de consulta se já existe um serviço adequado para buscar o atendimento.

Uma interface de linha de comando, ou CLI, atende ao uso pelo terminal. Ela pode ser útil para tarefas técnicas e também participar de uma integração com agentes. O cliente que quer preparar uma reunião, porém, não precisa aprender o comando utilizado internamente para receber o resultado.

Esses caminhos podem compartilhar a lógica do produto e oferecer formas diferentes de interação. A escolha depende de onde a tarefa começa. Expor um comando e expor uma ferramenta MCP não são a mesma entrega: o assistente precisa descobrir a ação e interpretar suas entradas e seu retorno.

Na consulta de atendimento, o primeiro trabalho é delimitar qual informação o agente recebe, evitando devolver todo o histórico para uma dúvida sobre o contato mais recente. O artigo sobre Jev e histórico de leads no Mautic desenvolve a leitura das interações registradas sem tratar cada ação como intenção de compra.

A credencial não pode ampliar a consulta

O cliente que acessa apenas os contatos da própria empresa deve manter esse alcance ao conectar o assistente. Uma integração com credencial administrativa pode consultar outros registros se o servidor não aplicar a autorização correspondente. O nome da ferramenta não impede essa exposição.

Você consegue verificar o isolamento com dois contatos de empresas distintas. A mesma identidade que consulta o primeiro deve receber a recusa ao tentar abrir o segundo. O resultado precisa corresponder ao acesso concedido na aplicação, preservando a consulta autorizada sem liberar outros históricos.

Uma informação sensível também não precisa aparecer inteira no retorno. Para preparar a reunião, a data e o assunto do último atendimento podem ser suficientes. Acrescentar campos sem utilidade para a tarefa aumenta o conjunto de informações compartilhado com o assistente.

Ler o histórico e enviar uma mensagem

A consulta pode servir de base para preparar um texto. Enviar esse texto altera o atendimento e exige uma autorização própria. Você pode oferecer ferramentas separadas para as duas ações, mantendo a consulta disponível sem conceder envio por consequência.

Quando a empresa exige revisão, o conjunto autorizado precisa corresponder ao conteúdo enviado e ao destinatário. Acrescentar outro contato depois da aprovação muda a ação. O sistema deve tratar essa diferença de acordo com o processo definido para o atendimento. O artigo sobre specs para agentes mostra como descrever os estados de uma mensagem preparada, cancelada ou já em envio.

Uma falha de conexão durante o envio também exige acompanhamento. O assistente pode ficar sem resposta mesmo quando a mensagem saiu. A identificação da tentativa permite investigar o resultado e evitar repetir automaticamente a comunicação. A leitura sobre o custo previsível de um agente de WhatsApp aprofunda o trabalho que acompanha essas integrações.

Um primeiro acesso para o assistente do cliente

Eu manteria a consulta inicial restrita à leitura para examinar a utilidade do retorno e a autorização aplicada. Você consegue comparar o resultado com a conversa original e ouvir se a informação serviu à preparação da reunião. Essa experiência fornece uma pergunta específica para a próxima ferramenta.

O Plano Martech da Promovaweb se relaciona ao estudo de automação e integração entre sistemas. O hub de planos da Promovaweb reúne os caminhos por objetivo. Para um produto existente que precisa organizar as ações oferecidas aos assistentes, o Diagnóstico de Produto e Arquitetura da Dev Side Studio permite examinar essa preparação.

Compare os Planos

Escolha o plano adequado ao seu objetivo e consulte tudo o que está incluído.

O Plano Martech cobre automação e atendimento. O Plano IA Makers acrescenta desenvolvimento com IA, enquanto o Plano Founders trata de gestão de negócios. Todos são anuais.

Plano Martech

Para conectar automação, marketing e atendimento com infraestrutura própria.

R$ 897

R$ 597/ano

  • Grade de automação, atendimento, marketing e análise de indicadores
  • Instalador Exclusivo Promovaweb
  • n8n, Evolution API, Chatwoot e Mautic
  • Trilha DevOps incluída
  • Encontros ao vivo (terça e quinta)
  • Comunidade e acompanhamento
Conhecer o plano

Plano Founders

Plano anual para fazer um projeto de tecnologia avançar, com 90 dias de mentoria intensiva. R$ 1.997 à vista ou até 10x de R$ 219 no cartão.

R$ 1.997/ano

  • 12 meses de acesso ao Founders
  • 90 dias de mentoria intensiva (segunda a sexta)
  • War Rooms às segundas, quartas e sextas
  • Encontro semanal em grupo após a fase intensiva
  • Formação Vibe Coding incluída no plano anual
  • Consultoria individual de até duas horas (bônus)
Conhecer o plano