Construção de MCP para CRM: um caso prático com Go e Flutter

Tg Apps · Publicado em 7 de outubro de 2026 · Fontes verificadas em 7 de outubro de 2026

A Tg Apps implementou um adaptador MCP para um CRM operacional com backend em Go, interface de gestão em Flutter e persistência em MariaDB. Este caso técnico explica como ferramentas definidas aproveitam os serviços do sistema, como o acesso é delegado e como consultas e atualizações são separadas.

A arquitetura: um adaptador sobre o CRM existente

O endpoint MCP fica no backend Go e usa o SDK oficial da linguagem com Streamable HTTP. A interface Flutter cuida do cadastro de aplicativos, consentimento, conexões ativas e revogação. O MariaDB guarda concessões de acesso e registros das operações. O assistente consome ferramentas; a interface Flutter continua sendo parte do CRM.

Caminho do pedido: cliente do assistente → endpoint MCP → autorização e validação → serviços existentes do CRM → resultado estruturado. O adaptador aproveita os serviços que já aplicam as regras do CRM, mantendo as decisões de negócio fora dos prompts.

O catálogo de leitura reúne 11 ferramentas para empresas, leads, projetos, Kanban, atividades, horas registradas, recebíveis, resumos do painel, pendências e eventos. Cada ferramenta define parâmetros e formato de resposta, com paginação e acesso delimitado aos dados da operação.

Acesso delegado, preservando o login do CRM

A pessoa mantém o login existente do CRM. Uma concessão OAuth separada autoriza o cliente do assistente. A implementação usa fluxo de código de autorização, PKCE S256, renovação com troca de token e revogação. A interface Flutter permite revisar os escopos solicitados antes do consentimento.

Neste caso, somente responsáveis com perfil owner podem delegar acesso. O servidor obtém a empresa pela identidade autenticada e verifica o escopo exigido em cada operação. Um identificador enviado pelo assistente não concede acesso a outra empresa.

O desenho usa mecanismos descritos na especificação de autorização MCP e na especificação PKCE. Essas referências explicam os mecanismos, não constituem uma certificação da implementação.

Consulta, proposta e execução são capacidades diferentes

O catálogo modela 21 tipos de proposta. Apenas record_payment tem execução implementada na versão revisada. Os outros 20 podem gerar propostas, mas não executá-las. Ter um tipo de proposta disponível não significa disponibilizar toda a operação do CRM para gravação.

A operação executável usa o serviço financeiro existente, validação dos dados, registro de execução e controles de idempotência. O caminho direto depende da política configurada e de um escopo específico de gravação. Ele não exige uma nova aprovação do responsável em cada chamada, portanto não deve ser apresentado como execução sempre confirmada por uma pessoa.

Esse é o limite da implementação analisada, não uma recomendação de habilitar a mesma ação financeira em outra empresa. Cada cliente escolhe as ferramentas, os acessos e as aprovações necessários. Consultas e preparação de tarefas podem ser bons pontos de partida.

O que foi verificado em cada camada

Testes isolados: os registros incluem autorização, separação entre empresas, versões das propostas, pedidos repetidos e consistência financeira em ambiente local isolado.
Componentes publicados: há registro da publicação do adaptador, OAuth, interface de gestão, alterações de persistência e correção do proxy.
Autorização no cliente real: um cliente OpenAI real concluiu o consentimento e recebeu um token.
Próxima verificação de aceite: a descoberta das ferramentas e uma consulta pelo cliente real após a última correção do proxy ainda não estão confirmadas no registro revisado.

Cada verificação responde a uma pergunta. A concessão registrada comprova a delegação; a lista de ferramentas comprova a descoberta; uma consulta bem-sucedida comprova o caminho de leitura; uma atualização exige conferir seu próprio resultado e consistência. Nenhum pagamento sintético foi criado no financeiro de produção durante essa publicação.

Para uma nova integração, mantenha um conjunto objetivo de testes: consulta permitida, consulta negada, tentativa entre empresas, acesso expirado ou revogado, pedido repetido e o fluxo exato de atualização habilitado. Execute também no cliente do assistente usado pela equipe, como orienta a documentação de testes MCP da OpenAI.

O que aproveitar em outro projeto

A decisão reaproveitável é um adaptador pequeno, com ferramentas explícitas, sobre serviços de negócio que já funcionam. Identidade e permissões ficam no servidor; leitura e gravação têm capacidades distintas; o histórico é preservado; a conexão do assistente real é verificada separadamente dos testes locais. Outro CRM pode seguir essas decisões sem adotar Go, Flutter ou MariaDB.

A Tg Apps oferece construção de MCP como serviço opcional já incluído no plano mensal, dentro da capacidade e das prioridades combinadas. Contrato e NDA vêm antes do início, sem adiantamento. Os ciclos de entrega seguem o plano escolhido; publicações em produção seguem o plano acordado. O D-U-N-S 651029828 identifica a empresa responsável.

Comece pelo guia para conectar IA aos sistemas internos ou conheça o serviço de integrações de IA e MCP para definir uma primeira entrega funcionando.

Base da implementação e referências técnicas

O caso usa registros de implementação da Tg Apps revisados em 6 de outubro de 2026. As referências abaixo explicam o protocolo e a autorização; o repositório do projeto e os registros operacionais são privados.