MCP Spotlight: ThinAir Data — Read-Only PostgreSQL, MySQL & SQL Server for Your Agent, 23 Tools, 3 Safety Layers

Server: @thinairtelematics/data by ThinAir Telematics Tools: 23 · License: MIT · Dialects: PostgreSQL, MySQL, SQL Server · Mode: Read-only MCP Tracker: glama.ai/mcp/servers/ThinAirTelematics/ThinAir-Data Docs: data.thinair.co/docs

Most database MCP servers give your agent a single PostgreSQL or MySQL connection and call it done. ThinAir Data is built for the case that actually matters in production: your agent needs to talk to multiple database dialects in one session, and you need a hard guarantee it can never write to any of them.

23 tools, 4 capability tiers, three independent safety layers, and one design choice that changes the threat model: connections enter the session at runtime via the add_connection tool — never as env vars, never at install time.

The Three Safety Layers

Pointing an AI agent at a production database is terrifying. Most teams won't do it without a serious safety net. ThinAir Data gives you three:

1. SQL Guard — regex-based rejection of INSERT / UPDATE / DELETE / DROP / ALTER / TRUNCATE / MERGE / GRANT / REVOKE at the tool layer, before the query is sent
2. Session READ ONLY — opens every connection with a transaction-scoped read-only flag, enforced at the driver level
3. Per-connection query firewall — let your team write allowlists/denylists for specific tables or query patterns

Three independent enforcement paths mean a single bug can't take down your database. The agent has to bypass all three simultaneously to cause damage.

The 23 Tools Across 4 Tiers

Tier 1 — Discovery

Tool	What It Does
list_connections	Shows all connected databases with name + dialect
describe_schema	Tables, columns, indexes, foreign keys across any connection
query_sql	Parameterized read-only SQL execution
data_profile	Distributions, null rates, cardinality for a table

Tier 2 — Build

Tool	What It Does
query_history	Recent queries with timing, row counts, status
query_optimize	Suggestions to improve query performance
explain_query	Dialect-aware EXPLAIN output
suggest_queries	Natural-language query suggestions against the schema
saved_queries	Reusable parameterized queries
watch_table	Monitor a table for changes

Tier 3 — Architect

Tool	What It Does
cross_db_query	Run the same query across 2–4 connections (regional/dialect compare)
detect_anomalies	Statistical outliers in row growth, latency, value distributions
pii_scan	Scan a table for PII patterns (SSN, email, phone, credit card)
find_n_plus_one	Identify N+1 patterns in query_history
query_firewall	Per-connection custom rules (deny specific tables/queries)
impact_analysis	What breaks if I change this schema?

Tier 4 — Migrate

Tool	What It Does
generate_migration	Generate dialect-correct DDL migrations
add_connection	Add a DSN at runtime (tenant-scoped, reusable)

Multi-Dialect, One Session

The killer feature: your agent can talk to PostgreSQL, MySQL, and SQL Server in the same conversation, and the tools handle dialect translation automatically.

-- Same query, different syntax per connection:
SELECT TOP 10 * FROM customers;          -- SQL Server
SELECT * FROM customers LIMIT 10;        -- MySQL / PostgreSQL

describe_schema returns dialect-correct DDL, query_sql knows the difference between TOP and LIMIT, and cross_db_query runs the same logical query against 2–4 connections simultaneously and returns the results side-by-side. Useful for regional replication tests, blue/green deployment validation, or migration verification.

Connections Are Runtime, Not Config

Most MCP database servers put connection strings in environment variables or config files. ThinAir Data inverts this:

# Agent prompt after connection:
# "Connect to our production database at postgresql://user:pass@prod.db:5432/app
#  and run describe_schema on the customers table."

# Agent calls:
add_connection(name="prod-pg", dsn="postgresql://...")
describe_schema(connection="prod-pg", table="customers")

The DSN never sits in your MCP client config. Connections are tenant-scoped and reusable across sessions — add it once via add_connection, reuse the name forever. This means:

• No credentials in your MCP config (which often gets committed to git)
• Per-tenant isolation — different users see different connection sets
• Audit trail per connection — every query logs which connection it ran against
• No env-var sprawl in your dev / CI / prod environments

Facio Integration

OAuth-keyless default (recommended for Facio):

{
  "mcpServers": {
    "thinair-data": {
      "url": "https://data.thinair.co/mcp"
    }
  }
}

For non-OAuth clients, use an API key:

{
  "mcpServers": {
    "thinair-data": {
      "url": "https://data.thinair.co/mcp",
      "headers": {
        "Authorization": "Bearer ${credentials.THINAIR_API_KEY}"
      }
    }
  }
}

Facio's audit trail captures every query the agent runs, the connection name, the timing, and the result count. Combined with ThinAir's three-layer read-only enforcement, you get a complete safety story: the query path is logged, the query is sandboxed, and even the connection is revocable per-tenant.

For HITL workflows, the query_firewall tool is particularly interesting: a human can add rules like "deny any query that joins users.email with orders" and the agent physically cannot violate it.

Quickstart

# OAuth-keyless install
# Add to your MCP client config (Claude Desktop, Cursor, Windsurf, etc.):
{
  "mcpServers": {
    "thinair-data": {
      "url": "https://data.thinair.co/mcp"
    }
  }
}

# Sign in at first use → add your database connection:
add_connection(
  name="prod-postgres",
  dsn="postgresql://readonly_user:hunter2@prod.db:5432/app"
)

# First prompts:
# "Describe the schema of the customers table in prod-postgres"
# "Find the top 10 slowest queries this week"
# "Scan the customers table for PII patterns"
# "Run this query against prod-postgres and staging-postgres — compare row counts"
# "Find N+1 query patterns in last 24 hours of query_history"

CLI / scripts: npx -y @thinairtelematics/data prints a config block to stdout.

Use Cases

Safe production access: Point an agent at production read replicas. The three safety layers mean a hallucination that tries to DELETE FROM users gets rejected at the tool layer before it ever reaches the DB.

Cross-region validation: cross_db_query runs the same query against your US, EU, and APAC replicas and returns side-by-side results. Useful for testing that a migration applied consistently across regions.

Schema archaeology: "What does the orders table look like in MySQL vs PostgreSQL?" — describe_schema returns the schema in dialect-correct form, including indexes and foreign keys.

PII compliance: pii_scan finds columns matching SSN, email, phone, credit card patterns. Useful for GDPR / CCPA audits.

Performance debugging: query_history + find_n_plus_one + query_optimize give your agent a complete performance triage toolkit. "Find the slowest N+1 patterns in the last 24 hours and suggest indexes."

Migration generation: "Generate the DDL to add an archived_at column to the users table in PostgreSQL, MySQL, and SQL Server." — generate_migration returns three dialect-correct versions.

Bottom Line

ThinAir Data is what database access for AI agents should look like: multi-dialect, read-only by enforcement (not just convention), connection-managed at runtime, and 23 tools deep. If you're letting an agent touch any database, you want three safety layers, not one — and you want the DSNs to live in a tenant-scoped store, not in your MCP client config.

At https://data.thinair.co/mcp with OAuth-keyless install, your agent can describe schemas, run cross-database compares, scan for PII, and find N+1 patterns — all without a single write statement ever reaching your database.

---

MCP Spotlight is a series covering servers that give AI agents real capabilities. Every server is evaluated for tool quality, safety design, and integration fit with Facio's HITL-first agent runtime.