Conecte seu agente ao EVODA (MCP)

O modelo de segurança, antes de tudo

• Chave por projeto: a AgentKey dá acesso a UM projeto, nada mais. É exibida uma única vez, guardada como hash (SHA-256) e revogável na tela do projeto.
• Somente leitura por desenho: os roteiros de investigação saem com SET default_transaction_read_only = on e statement_timeout no preâmbulo — e um lint determinístico bloqueia credencial inline e escrita no servidor antes de o roteiro existir.
• O agente informa, nunca decide: ele pode marcar um ponto de atenção como em andamento ou resolvido (com evidência obrigatória) — descartar ou aceitar risco é decisão de gente, e a rota recusa.
• Teto de tráfego por IP e bloqueio com evento de auditoria em falha repetida de autenticação.

Como conectar

1. No EVODA, abra o projeto e gere uma chave em Agente conectado (é preciso ter conta — o plano Free basta). Copie na hora: ela não aparece de novo.
2. No Claude Code, adicione o servidor MCP:

   claude mcp add EVODA --transport http https://app.evoda.ai/api/mcp --header "Authorization: Bearer evoda_ak_SUA_CHAVE"

3. Peça ao agente: “veja as investigações pendentes do EVODA e execute”. Ele lista, roda no seu ambiente e devolve os relatórios — o consultor lê e traz as conclusões na conversa.

Qualquer cliente MCP serve: o transporte é HTTP com Authorization: Bearer <chave> em https://app.evoda.ai/api/mcp.

No pull request, sem agente nenhum

A revisão de migration também responde por HTTP simples, para rodar no CI: ela confere o DDL do PR contra o modelo aprovado, a classificação de dado pessoal por coluna e as premissas registradas — sem IA, então roda em todo push sem custo e sempre com o mesmo veredito. A resposta traz blocked: true|false já decidido, para o job reprovar sozinho.

# .github/workflows/evoda-schema-review.yml
name: Revisão de schema (EVODA)
on:
  pull_request:
    paths: ['**/migrations/**']

jobs:
  revisar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - name: Revisar as migrations do PR
        env:
          EVODA_AGENT_KEY: ${{ secrets.EVODA_AGENT_KEY }}
        run: |
          bloqueou=0
          for f in $(git diff --name-only "${{ github.event.pull_request.base.sha }}...HEAD" | grep -E 'migrations/.*\.sql$'); do
            resposta=$(jq -Rs --arg n "$f" '{sql: ., migration_name: $n}' < "$f" \
              | curl -sS -X POST https://app.evoda.ai/api/ci/schema-review \
                  -H "Authorization: Bearer $EVODA_AGENT_KEY" \
                  -H 'Content-Type: application/json' --data @-)
            echo "$resposta" | jq -r .summaryMd
            [ "$(echo "$resposta" | jq -r .blocked)" = "true" ] && bloqueou=1
          done
          exit $bloqueou

Guarde a chave do projeto em secrets.EVODA_AGENT_KEY. O que reprova o PR é só o BLOQUEIO (o DDL contradiz o desenho registrado); aviso sai no log e não derruba o build — alarme que derruba build por gosto é alarme que o time desliga.

O que o agente consegue fazer

20 ferramentas, todas no escopo do projeto da chave. As avaliações (benchmark atingiu o alvo? a aceitação passou?) são feitas por código no lado do EVODA — o agente entrega dados, nunca vereditos.