A PostgreSQL MCP server can work perfectly on Friday and become confidently wrong after Monday's migration.
The database is available.
The tool connects.
The SQL may even execute.
But a migration can still change:
- a view's grain
- a status enum
- a timestamp's business meaning
- a join's cardinality
- exposed permissions
- the authoritative metric source
Schema-change readiness therefore needs more than rediscovery.
Test renamed and removed objects, executable-but-semantic changes, permission drift, stale caches, multiple MCP replicas, representative query plans, in-flight conversations, and interrupted rollout states.
Bind every test to:
- database migration version
- exposed object and policy versions
- semantic definition
- MCP tool schema
- server build
- discovery timestamp
If context freshness cannot be proven, affected tools should fail with a structured stale-schema result instead of guessing.
And use expand-and-contract for tool contracts too: add the new version, run old and new against deterministic fixtures, migrate clients deliberately, observe the compatibility window, then remove the old contract.
“The new view exists” is not a production gate.
“The new meaning is tested, versioned, authorized, observable, and recoverable” is.
Full test guide: MCP server for Postgres: test schema-change readiness before production
Top comments (0)