Your agent closes the loop, scoped to a single project.

Connect your Claude Code (or another agent) to EVODA over MCP: it receives the investigations, runs them in your environment in read-only mode and returns the reports, with no copying and pasting. The key is valid for one project, and for nothing else.

Free assessment See it from the inside

The problem

Why this exists

How it works today

The back-and-forth between the analysis tool and the environment is manual: copy the query, run it, paste the result. It works once; as a routine, someone forgets, and the follow-up dies of friction.

How it works with EVODA

The agent on your side closes the loop alone: it lists pending investigations, runs them under the prompt’s rules and returns the report. And it sends periodic database snapshots, which feed the drift watch and the assumption checks.

How it works

Connected agent from the inside

1The connection

One key, one project, read-only.

The key is born scoped to one project and stored as a hash. Connecting is one command in Claude Code, and revoking is one click: the agent loses access on the spot.

EVODA still has no access to your environment: the executor is the agent on your side, with the credentials that were already yours.

Connected agentevodb_ak_7f3a…

Receives the investigations, runs them in your environment in read-only mode and returns the reports on its own.

Connect in Claude Code

claude mcp add EVODA --transport http …/api/mcp

Continuous watchactive

Frequencydailyweeklyfortnightlymonthly

drift

Index removed from public.pedidos: idx_pedidos_cliente
Anomalous growth in public.eventos: ~1,200,000 → ~2,400,000 rows (+100%)

Silence warns too: if the agent stops reporting, the watch flags the absence.

2The loop

Pending investigation, report on the way back.

The agent asks what is pending, executes and returns, file by file, with the scoreboard visible to you. The consultant reads and closes the loop.

The same channel carries the execution report and the month’s invoice: it is what turns a one-off engagement into a follow-up.

Real volumetry of the order tables

to run2 of 3 files

Goal: measure real volume and growth before closing the analytics layer recommendation.

Mandatory rules in the prompt

READ ONLY
SET default_transaction_read_only = on;
SET statement_timeout = '120s';

2 of 3 requested filesMissing: row count per table (csv)

Attach response

Attaching does not close the investigation: the consultant closes the loop, after reading what came back.

Under the hood

The security of the connection

The design assumes keys leak, and limits the damage.

hashThe key is shown once and stored as a hash; revocation takes effect immediately

scopeOne project per key: the agent does not see the rest of the organization

toolsTools for investigations, environment snapshots, benchmarks, acceptance and cost

silenceAn agent that stops reporting becomes a watch warning, because absence is also a signal

What comes next

How it fits the rest of the engagement

As-isA real as-is

Discovery happens through guided investigations: read-only scripts you execute, with the result coming back tied to the question.

See it from the inside →Track recordProject track record

Projected cost against the real invoice, assumptions with state, open objections and the environment’s drift, in one place.

See it from the inside →DeliveryExecution prompt

The deliverable that closes the engagement without touching your database: environment assumptions, verification and rollback, ready for your agent or your DBA.

See it from the inside →

Start with the schema you already have

Paste the structure, get the most serious findings in about two minutes, and decide later whether an engagement is worth opening. No account, no card.

Free assessment See examples of what it delivers