Cinco componentes MCP para MODX testados contra falhas: agente reporta sucesso quando só metade das edições foi salva

Uma tarefa comum: escolher um componente MCP para delegar a um agente de IA o trabalho rotineiro em sites. Mas um desenvolvedor de um estúdio web que trabalha com MODX 2 e 3 olhou o código e viu um laço que atualiza os campos adicionais de uma página e não verifica o resultado de setTVValue(). O primeiro campo foi gravado, o segundo não, e o manipulador reportou sucesso. O agente vai acreditar nessa resposta e dizer ao usuário que está tudo pronto.

Disso nasceu uma pequena pesquisa. O autor selecionou cinco projetos: karamble/modxmcp, dampilov94/mcp-component, rumata-estor/modx3-mcp, modxcms/modAI e ShevArtV/mxBoard. Ele fixou o código-fonte em 26 de outubro de 2026 e fez 25 verificações com PHP 8.3.6. Foram usadas as classes reais dos componentes, mas, no lugar de um MODX e de um banco de dados reais, havia objetos de teste. Parte dos testes reproduzia erros de propósito, então PASS nem sempre significa que o componente se comporta corretamente.

Com quais permissões o agente age

Imagine um gerente de conteúdo que só pode mexer em notícias. Se você lhe der um assistente de IA, quais permissões o próprio assistente recebe? No código foram encontrados dois esquemas. Em karamble, são verificadas tanto a permissão para a operação quanto o acesso ao recurso específico. Na issue nº 11 houve até um erro real: um usuário restrito obtinha via MCP dados que não via no painel administrativo. Foi corrigido na versão 1.2.0.

Em dampilov94 e rumata-estor é possível restringir grupos de comandos, mas eles são executados por um usuário de serviço com direitos de administrador. Para tarefas de administrador, isso é aceitável. Para assistentes pessoais de funcionários com suas próprias restrições, já não.

Dados desatualizados e respostas perdidas

O preço na página é 1000 rublos, o agente o lê e, enquanto isso, um funcionário coloca 1100. O agente grava 1200, e a edição da pessoa desaparece. No código de dampilov94, o valor antigo não é comparado. Em rumata-estor existe uma verificação do valor esperado com o status STALE_STATE, e no teste ela preservou a edição humana. Mas a verificação é opcional: se o cliente não enviar a pré-condição, a gravação passa. Além disso, a verificação e a gravação ocorrem separadamente, sem comparação atômica no nível do banco de dados.

Com as repetições, a história é outra. Se o servidor criou uma página mas a resposta se perdeu, o agente pode repetir o comando e gerar uma duplicata. O RequestStore de dampilov94 guarda o estado pelo identificador da requisição. Uma duplicata paralela recebe 409, uma requisição concluída devolve a resposta salva e, se os argumentos mudarem sob o mesmo identificador, a requisição é rejeitada. Mas, com um novo identificador, o comando será executado de novo.

O bloqueio de arquivo em rumata-estor fez um segundo processo esperar 350 ms. No entanto, um terceiro processo, que não o conhecia, alterou o arquivo tranquilamente. O painel administrativo comum do MODX se comportaria da mesma forma. Identificador de requisição, bloqueio e verificação do valor esperado resolvem problemas diferentes e não substituem uns aos outros.

Gravação parcial e aceitação

rumata-estor envolve a gravação de TV em uma transação: se setTVValue() retornou false, é chamado o rollback. No teste, os valores voltaram aos originais. Em modAI, o resultado da atualização do cache não é verificado, e no teste a ferramenta informou sucesso com false. Em karamble, após a alteração o recurso é lido novamente. O mxBoard separa a execução da tarefa da sua aceitação: o executor não conseguiu fechar a tarefa de outra pessoa.

O que fazer a respeito

As limitações são honestas: o autor ainda não executou um MODX real com MySQL e um modelo de linguagem, e o rollback foi verificado apenas com um substituto de teste. Ainda assim, a conclusão vale para qualquer CMS e qualquer aplicação em que se permita a um agente alterar dados de produção. Antes do lançamento, decida em nome de quem ele trabalha. Exija que o cliente envie um identificador de requisição e o valor esperado. Verifique o resultado de cada gravação, e não apenas da última chamada. E não tome o «sucesso» de um agente como confirmação de que tudo foi salvo no site.