Mcp Server Redshift Setup

Running MCP against Redshift means provisioning a dedicated workload management (WLM) queue for agents, connecting through the Data API rather than JDBC, and enforcing a query timeout per statement. That setup keeps analyst dashboards fast while giving agents the access they need to ship answers.

Redshift is the most common AWS warehouse, and teams running it want agent access without risking the cluster. This guide covers authentication, WLM queues, Data API vs JDBC, query policies, and observability, so an MCP server can query Redshift the same way a BI tool would.

Use the Data API, Not JDBC

Redshift's Data API runs over IAM-authenticated HTTPS and returns results asynchronously. That is a much better fit for MCP than classic JDBC connections, which hold long-lived TCP sockets and require VPC networking. The Data API gives you IAM auth for free, eliminates connection pooling, and works from any environment the agent runs in.

If you already run JDBC for legacy BI tools, keep those connections and add the Data API on top for MCP. The two protocols do not conflict. For Redshift Serverless, the Data API is effectively the only sensible option.

Dedicated WLM Queue

Redshift's Workload Management lets you carve out a queue for agent traffic so it cannot starve the analyst queue. Create a queue called agents with a concurrency of 5, a memory share of 20%, and a query timeout of 120 seconds. Route MCP queries to that queue via a query group label, and the agent cannot block an analyst dashboard no matter how badly it misbehaves.

• •Dedicated queue — isolates agent traffic
• •Query group label — routes agent SQL to the right queue
• •Concurrency cap — 5 slots maximum
• •Memory share — 20% of cluster
• •Statement timeout — 120 seconds hard cap

IAM Roles and Least Privilege

The Data API authenticates via IAM, so the MCP server runs as a named IAM role (mcp-redshift-agent) with permissions to call redshift-data:ExecuteStatement, GetStatementResult, and DescribeStatement on a specific cluster. Inside Redshift, that role maps to a database user via IAM:GetClusterCredentials, scoped to a read-only schema.

Column-Level Security

Redshift supports column-level grants, so you can grant the agent SELECT on specific columns while excluding PII. A safer pattern is to expose a curated view that already redacts sensitive columns and grant the agent SELECT on the view. Either approach keeps the raw table invisible to the MCP server.

Observability with STL and SVV Tables

Redshift exposes query history via STL_QUERY (last 2-5 days) and SYS_QUERY_HISTORY (serverless). Join those against the MCP audit log using the query group label and you have a complete record of what the agent ran, how long it took, and how much spillage it caused. Ship the joined stream to CloudWatch for dashboards.

Data Workers on Redshift

Data Workers' Redshift connector uses the Data API, routes queries to the agent WLM queue, and tags every statement with the agent ID. The catalog agent discovers tables via SVV_COLUMNS, the cost agent watches for spillage, and the pipeline agent can trigger downstream transforms. See AI for data infrastructure for the full stack or compare with MCP server BigQuery production setup.

To see a Redshift MCP server running in production with WLM isolation and Data API auth, book a demo. We will walk through cluster setup, queue configuration, and query attribution.

Redshift Serverless deserves a special mention because it changes the MCP story. With classic Redshift you pay for cluster hours whether the agent is active or not, and WLM queues are the main isolation mechanism. Serverless charges per query based on RPU-seconds consumed, which makes agent workloads much cheaper — you pay only when the agent runs a query. For MCP that do not need round-the-clock availability, Serverless is often the right default.

The Data API also solves a long-standing pain point for Redshift: connection limits. Classic Redshift caps the number of concurrent connections per cluster, and a misbehaving MCP client can exhaust that pool. The Data API is stateless — every call is a short-lived HTTP request — so it sidesteps the connection limit entirely. Agents that poll frequently, or multiple agents sharing one cluster, see none of the connection pressure they would hit with JDBC.

One often-missed optimization is result set caching. Redshift caches query results automatically for 24 hours when the source tables have not changed, and cache hits are free. Agents that ask similar questions repeatedly get massive speedups from this cache, and the MCP server does not need to do anything special — Redshift handles it transparently. Make sure the agent's query tag does not inadvertently poison the cache by varying on every call.

Redshift MCP works once you give agents their own WLM queue, route through the Data API, and enforce a statement timeout. The rest is standard warehouse hygiene — column grants, curated views, and query history observability.