Connect your agent to EVODA (MCP)

The security model, before anything else

• One key per project: the AgentKey grants access to ONE project, nothing more. It is shown exactly once, stored as a hash (SHA-256) and revocable from the project screen.
• Read-only by design: investigation scripts ship with SET default_transaction_read_only = on and statement_timeout in the preamble — and a deterministic lint blocks inline credentials and server-side writes before the script even exists.
• The agent reports, it never decides: it can mark an attention item as in progress or resolved (with mandatory evidence) — discarding one or accepting it as a risk is a human decision, and the route refuses.
• Per-IP traffic ceiling and a block with an audit event on repeated authentication failure.

How to connect

1. In EVODA, open the project and generate a key under Connected agent (an account is required — the Free plan is enough). Copy it right away: it is not shown again.
2. In Claude Code, add the MCP server:

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

3. Ask your agent: “check EVODA's pending investigations and run them”. It lists them, runs them in your environment and returns the reports — the consultant reads them and brings the conclusions into the conversation.

Any MCP client works: the transport is HTTP with Authorization: Bearer <key> at https://app.evoda.ai/api/mcp.

In the pull request, with no agent at all

Migration review also answers over plain HTTP, so it can run in CI: it checks the PR's DDL against the approved model, the per-column personal-data classification and the recorded assumptions — with no AI, so it runs on every push at no cost and always with the same verdict. The response carries blocked: true|false already decided, so the job can fail on its own.

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

jobs:
  revisar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - name: Review the PR migrations
        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

Keep the project key in secrets.EVODA_AGENT_KEY. Only a BLOCK fails the PR (the DDL contradicts the recorded design); warnings go to the log and do not break the build — an alarm that breaks the build for taste is an alarm the team turns off.

What the agent can do

20 tools, all scoped to the key's project. The evaluations (did the benchmark hit its target? did acceptance pass?) are done in code on EVODA's side — the agent delivers data, never verdicts.