list_tables/describe_table surface soft-deleted table tombstones with no way to distinguish them from live tables

[jstirnaman]

What to change

Add tombstone detection to the MCP tools that list or describe tables so agents can distinguish a live table from a soft-deleted one. Specifically:

• list_tables / get_measurements (src/tools/categories/query.tools.ts:119,372 → InfluxService.query.getMeasurements() in src/services/query.service.ts:695,718 for Core/Enterprise, :634,666 for Cloud Dedicated/Clustered): the underlying query is a plain SELECT DISTINCT table_name FROM information_schema.columns WHERE table_schema = 'iox' (or SHOW MEASUREMENTS). Add a check for the deleted-at-timestamp suffix pattern (<name>-<YYYYMMDDTHHMMSS> or similar) and either exclude those rows or annotate them.
• describe_table / get_measurement_schema (query.tools.ts:153,424 → query.service.ts:952,1002): currently returns full schema for a tombstoned table as if it were live, with no indication it's a dead remnant.

Minimum viable fix: don't suppress rows (a legitimate user table could end in a timestamp-shaped string), but add a warnings entry in the response when a suffix-pattern name is detected, e.g. "warning: 'foo-20260723T173021' looks like a soft-deleted table tombstone, not a live table".

Why

InfluxDB3's DELETE /api/v3/configure/table performs a soft delete by renaming the table to <name>-<deleted_at_timestamp> rather than removing it. The renamed tombstone stays visible in information_schema.tables/SHOW TABLES indefinitely until a scheduled or immediate hard delete purges it — there is no API call that removes the tombstone directly (re-deleting it returns 409 Conflict).

Confirmed live against a running InfluxDB3 Enterprise instance during MCP testbench e2e testing (see influxdata/docs-tooling testbench runs from 2026-07-23): an agent using list_tables and describe_table saw and fully described a table named e2e_conditional_write_probe-20260723T173021 with no signal that it was a dead tombstone rather than a real table.

Impact

Any agent using this MCP server to enumerate or describe tables can be misled by dead tombstones:

• An agent asked "what tables exist in this database" will include tombstones in its answer, giving the user a wrong count or wrong list.
• An agent asked to inspect schema for troubleshooting may waste tool calls describing a table that no longer holds live, queryable data.
• Test harnesses or automation built on top of list_tables that assert on exact table counts/contents will intermittently fail after any table delete, since the tombstone persists across the whole soft-delete-to-hard-delete window (which can be indefinite if hard_delete_at is never scheduled).

Verification

1. Create a table, write a row, then DELETE /api/v3/configure/table?db=<db>&table=<table> (soft delete, default).
2. Call list_tables (or get_measurements) against that database — confirm the tombstoned name (<table>-<timestamp>) is present.
3. Call describe_table (or get_measurement_schema) against the tombstoned name — confirm it currently returns a full schema with no warning.
4. After the fix: confirm list_tables response includes a warnings entry flagging the tombstoned name (or the row is excluded, per whichever approach is chosen), and describe_table on a tombstoned name likewise carries a warning.
5. Confirm a legitimately named user table ending in a timestamp-shaped string (e.g. snapshot_20260101T000000, created directly, never deleted) is NOT excluded or misflagged as a false positive.