Claude reads a SQL Server summary, reasons about it, asks for a drill-down, then asks for the total again.
If rows changed between those calls, every result may be valid—and the combined answer may still be inconsistent.
The tempting fix is to keep one transaction open across the conversation.
Don’t.
Model turns can take seconds or minutes. A long transaction can retain row versions, increase tempdb pressure, extend locks, complicate pooling, and survive awkwardly through retries or disconnects.
Define consistency per MCP operation instead:
- live statement: each call sees committed data according to database configuration
- bounded transaction: multiple statements run inside one short tool invocation
- snapshot read: the operation gets a stable view with a documented start time
- materialized report: the tool reads a versioned result at a known cutoff
SQL Server’s READ COMMITTED behavior also depends on whether READ_COMMITTED_SNAPSHOT is enabled. Document the actual database option rather than assuming the name tells the whole story.
If a question needs several related values, expose one bounded operation that computes them together.
If a large result needs pagination, use deterministic ordering, a scope-bound opaque cursor, and a high-water mark or materialized result where necessary. Do not leave the original transaction open between pages.
Return evidence too: consistency class, snapshot start when relevant, reporting cutoff, source freshness, normalized parameters, row count, truncation, database or replica identity, and trace ID.
Then test under concurrent writes, cancellation, retries, pagination changes, and version-store pressure.
The goal is not perfect conversational stasis. It is an explicit promise that operators can understand and verify.
Full guide: Claude SQL Server MCP: define transaction isolation for repeatable answers
Top comments (0)