Carta detalha arquitetura de microapps dentro de plugin MCP e os trade-offs da abordagem

O texto vem de Anubhav Srivastava, Senior Director of Product da Carta, e descreve a arquitetura de microapps da empresa (a fonte é a descrição, o projeto é o padrão em si). O ponto de partida é que chamadas de tool via MCPs têm mais latência que uma chamada direta de API, e isso não se resolve no design. A resposta da Carta foi mudar o momento da busca: os dados são puxados uma vez na inicialização, gravados num snapshot local, e o app roda sobre essa cópia até o usuário refazer o pull. O exemplo é o Fund Modeling, em que as marcações do portfólio mudam por trimestre.

O pacote do plugin tem quatro camadas. O skill em markdown só orquestra, sem matemática nem regra de negócio. A camada de consulta e transformação usa SQL sobre views pré-construídas do data warehouse, mais scripts que geram os JSONs do app, sem modelo de IA no caminho dos dados. O app é JSX pré-compilado e concentra a lógica (XIRR, waterfall, repricing, liquidation preferences). Por fim, um shell React com servidor local, service worker e cópia vendorizada do React dispensa toolchain de build, o que deixa a lógica editável pelo cliente. O diretório de dados do usuário fica fora do pacote, então atualizações não apagam snapshots nem cenários salvos.

Para quem desenvolve integrações com MCPs, a leitura é que latência de tool call empurra o design para snapshot em vez de fetch sob demanda. Tirar o modelo do caminho de cálculo troca confiança por verificação: dá para abrir a função e conferir. O custo é claro: sem sync em tempo real nem colaboração ao vivo. Se esses forem requisitos duros, a própria Carta diz que um app hospedado é a escolha certa.