MCP Admin: dar ao Claude acesso de admin no Protheus pra debugar producao (com auditoria total)

4h da manha. Pager toca: faturamento parou. Voce loga via VPN, abre o TDS Studio, leva 8 minutos pra conectar no AppServer, abre o console.log, e ai o usuario fala "melhorou agora". Voce passou 15 minutos pra confirmar que o problema sumiu sozinho.

O McpAdmin.prw existe pra esse momento. E um console remoto REST que voce ou sua IA conversa direto com o Protheus em produao — sem TDS Studio, sem VPN restrita, sem chamada conferencia com o DBA. Com auditoria total de toda acao.

O problema

Sustentacao Protheus em 2026 ainda parece sustentacao em 2010:

• Logs locais: console.log fica em \Protheus\log\ no servidor. Pra ler, voce precisa RDP ou compartilhamento de arquivos.
• SQL ad-hoc: pra confirmar dado em SE2, voce abre Smartclient → tools → relatorio... ou Embarcadero DBeaver com a string de conexao do DBAccess.
• Versao do RPO: GetBuild()? GetSrvName()? Sao funcoes que ninguem lembra na hora da crise.
• Threads ativas: existe pelo Monitor mas e GUI — nao integra com Datadog/PagerDuty.

O McpAdmin expoe tudo isso via REST + JSON. E voce pode dar acesso supervisionado pra IA (Claude/GPT) durante incident response.

Arquitetura

Na pratica — 5 acoes que valem ouro

1. SERVERINFO — checar versao em 1 segundo

curl 'https://seu-protheus:8443/McpAdmin/admin?action=serverinfo' \
  -H "X-Admin-Key: ..."

{
  "server": {
    "name": "TOTVS",
    "build": "7.00.220222P-20251020",
    "os": "Windows Server 2022",
    "environment": "PROD01",
    "threads": 42,
    "httpPort": 8080,
    "company": "01",
    "branch": "0101"
  },
  "database": {"driver": "POSTGRES", "connected": true},
  "paths": {
    "rootPath": "C:\\Protheus\\protheus_data\\",
    "rpoDb": "tttp120.rpo"
  }
}

2. LOGS — tail do console.log sem RDP

curl 'https://seu-protheus:8443/McpAdmin/admin?action=logs&file=console.log' \
  -H "X-Admin-Key: ..." | jq '.content'

Le os ultimos 256KB. Voce pipa direto pro Datadog Logs via webhook ou pro grep "ERROR" local.

3. SOURCES — listar fontes do RPO

curl 'https://seu-protheus:8443/McpAdmin/admin?action=sources&filter=MATA' \
  -H "X-Admin-Key: ..."

Retorna todos os fontes com "MATA" no nome (MATA010, MATA020, MATA410, etc) com tamanho e tipo (AdvPL/TLPP). Util pra confirmar se a User Function que voce compilou ontem realmente esta no RPO.

4. SQL — executar query ad-hoc

curl 'https://seu-protheus:8443/McpAdmin/admin' \
  -X POST -H "X-Admin-Key: ..." -H "Content-Type: application/json" \
  -d '{"action":"sql","query":"SELECT TOP 10 E2_NUM, E2_VALOR, E2_VENCREAL FROM SE2010 WHERE E2_FORNECE=\"F00123\" AND D_E_L_E_T_=\" \" ORDER BY E2_EMISSAO DESC"}'

Retorna ate 10.000 linhas em JSON. DROP DATABASE e SHUTDOWN sao bloqueados — qualquer outro DDL/DML (UPDATE, DELETE, ALTER) e permitido se voce tem a chave. Use com cuidado.

5. SHELL — comando no SO host via StartJob + WaitRun

curl 'https://seu-protheus:8443/McpAdmin/admin' \
  -X POST -H "X-Admin-Key: ..." -H "Content-Type: application/json" \
  -d '{"action":"shell","command":"powershell -Command Get-Service Spooler | Format-List"}'

Esse e o mais legal tecnicamente. Por que? Porque WaitRun() nao funciona em thread REST do Protheus (limitacao conhecida). A solucao do McpAdmin: usar StartJob() pra disparar uma User Function (U_MCPSHELL) em thread separada, que ai sim pode rodar WaitRun. Comunicacao via arquivos temp em /temp/mcpshell_<threadid>_input.txt e _output.txt.

Comandos destrutivos sao bloqueados: FORMAT, DEL /S /Q, RD /S /Q, SHUTDOWN, RM -RF.

Caso de uso — IA durante incident response

Cenario: faturamento parou as 3h da manha. Voce esta no on-call. Conversa real (Claude com acesso ao McpAdmin):

Voce:   Faturamento parou. Investiga.

Claude: Vou checar status do servidor primeiro.
        [chama action=serverinfo]
        Servidor ok, 42 threads, build 7.00.220222P, Postgres conectado.

        Vou ver o console.log das ultimas linhas.
        [chama action=logs&file=console.log]
        Encontrei 87 ocorrencias de "ERROR" nos ultimos 30min.
        Padrao recorrente: "TIMEOUT no lock de SE2010" entre 02:48 e 02:53.

        Vou contar quantos pedidos de faturamento entraram nesse periodo.
        [chama action=sql, SELECT count(*) FROM SF2010 WHERE F2_EMISSAO=...]
        237 pedidos com F2_VALBRUT > 0. Volume 3x acima do normal pra esse horario.

        Hipotese: deadlock por contencao em SE2010. Vou olhar threads ativas.
        [chama action=threads]
        42 threads ativas, mas 15 delas estao em estado WAIT_LOCK ha > 30s.

        Recomendacao: matar essas 15 threads via Monitor, reiniciar o job
        de faturamento. Quer que eu execute, ou prefere fazer manual?

Voce:   Mata as 15 threads, deixa o resto pra mim.

4h da manha resolvida em 4 minutos. Sem TDS Studio, sem RDP, sem ligacao de conferencia.

Seguranca (este post tem 1 disclaimer enorme)

Quando NAO usar

• Compliance estrita (PCI-DSS, HIPAA): dependendo do escopo, executar SQL arbitrario em producao pode violar controles SOX/PCI. Consulte seu compliance officer antes.
• Ambiente sem TLS: ja dito mas vale repetir. Sem HTTPS, esse endpoint e um backdoor pra atacante.
• Cliente sem audit logging: se voce nao consegue rastrear quem chamou o que, nao implante. Audit logging e nao-negociavel.

Tabela comparativa

Proximos passos

• Baixe o fonte (~23KB, MIT) — o maior da familia MCP server pro Protheus
• Configure MV_MCPADMK com chave forte (32+ caracteres aleatorios)
• Configure TLS na frente do endpoint REST (nginx + Let's Encrypt e suficiente)
• Compile o fonte e teste primeiro com action=serverinfo (read-only, baixo risco)
• Integre o ConOut com seu SIEM (Splunk, Datadog, ELK)
• Rotacione a chave mensalmente

Quer ver Claude resolvendo incidente em tempo real num Protheus de demonstracao? Marca demo com a gente. 30 minutos, sem compromisso.