The agent queries a table and reports data that is minutes or hours old — with no error and no warning. What is happening?
The silent failure of replica architectures: replication lag. You correctly pointed the agent at a read replica, but the replica is lagging behind the primary, and Postgres serves stale rows as perfectly valid results. The agent then diagnoses a production bug using state that no longer exists. The engineering fix: before analysis sessions, have the agent check lag explicitly (SELECT now() - pg_last_xact_replay_timestamp()) and treat any lag beyond your tolerance as a hard stop. For debugging workflows where freshness matters more than safety, maintain a second config entry pointed at the primary with a 10-second statement_timeout and use it deliberately, not by default.
Does EXPLAIN ANALYZE actually run my queries?
Yes — ANALYZE executes the statement for real, including its I/O and lock footprint. On a read replica this is safe; on a primary under load it can worsen the very incident you are debugging. Plain EXPLAIN (no ANALYZE) is plan-only and always safe.
Can it write or migrate data?
Only in --access-mode=unrestricted, and only if the database role allows it. In restricted mode both layers block writes: the server refuses and the session runs in a read-only transaction. Defense in depth is the design, not an accident.
How does it handle connection pooling with PgBouncer?
Transaction-mode pooling breaks prepared statements between transactions, producing prepared statement does not exist errors mid-session. Use session mode for the MCP connection, or route the agent through a direct connection and keep PgBouncer for your application.