Your agent needs to read from Amazon Redshift, and often write back to it: query last quarter's revenue, refresh a rollup table, cancel a runaway statement for an analyst. Redshift has two obvious front doors for that work. AWS Labs ships an official Amazon Redshift MCP server, and the Amazon Redshift Data API has been production-ready for years. From a distance they look interchangeable. They are not. They differ on what your agent can do, how it authenticates, and how far either one carries you in a multi-tenant product. Here is how to choose.
This is a comparison of two specific objects, not a general MCP primer. You have almost certainly called an AWS API before; you may not have run the Redshift MCP server yet.
The Amazon Redshift MCP server is the AWS Labs implementation that lets an AI assistant discover, explore, and query Redshift clusters and serverless workgroups. It runs as a local stdio process launched with uvx awslabs.redshift-mcp-server@latest or from a Docker image, and it is configured inside an MCP host such as Kiro, Cursor, VS Code, or Claude Desktop. It exposes seven tools: list_clusters, list_databases, list_schemas, list_tables, list_columns, execute_query, and review_cluster. Query execution is deliberately constrained to a single read-only statement, with writes rejected by a SQL parser. You can read the full tool reference on the official Amazon Redshift MCP server documentation.
The Amazon Redshift Data API is the HTTP interface for running SQL against provisioned clusters and serverless workgroups without managing a persistent JDBC or ODBC connection. It is asynchronous: ExecuteStatement returns a statement ID, you poll DescribeStatement for status, then fetch rows with GetStatementResult. It supports full DML and DDL, parameterized statements, result formats in JSON or CSV, statement cancellation, and BatchExecuteStatement for up to 40 statements run as one transaction. Because it needs no VPC wiring, it is a common choice for AWS Lambda and scheduled jobs. The reference lives in the official Amazon Redshift Data API documentation.
This is the detail that trips up teams porting an agent from a SaaS connector. For most tools, the MCP path means a browser-based OAuth consent and the API path means an API key. Redshift is not that. Both paths authenticate through AWS IAM using SigV4. The MCP server reads a standard AWS credential from the host environment; the Data API accepts IAM temporary credentials, an AWS Secrets Manager secret, or IAM Identity Center. The credential you need to isolate per tenant is an AWS identity, not an OAuth token, and that changes the whole isolation story.
The gap between these two paths is not subtle, and it is not primarily about auth. It is about what SQL your agent is allowed to run.
The table below covers the actions that matter for agent use cases, not the full surface of either path.
The official MCP server was built for safe exploration and question answering, so its ceiling is deliberate rather than accidental. It runs one statement per call, parses that statement, and refuses anything that is not a read. That is exactly right for an analyst asking questions in an IDE. It is a hard blocker the moment your agent needs to load data, maintain a table, or run a migration, because those actions do not exist in the server at all.
The Data API is the full read and write surface. Beyond DML and DDL, it gives your agent explicit control over the statement lifecycle: submit with ExecuteStatement, batch with BatchExecuteStatement, describe, fetch, and cancel. Parameterized statements let you separate SQL from values, which matters when a model is composing the query. If your agent does anything beyond reading, this is the path that can express it.
Because both paths run on AWS IAM, the real auth question is not "OAuth or API key." It is "whose AWS identity does each query run under, and can that identity be scoped to a single tenant." Understanding API access patterns for AI agents helps clarify why identity architecture matters so much at this layer.
The MCP server picks up its credential from the host: an AWS_PROFILE, environment variables, or an instance role. That credential is the identity for every query the server runs, regardless of which end user prompted the agent. On a developer's laptop that is fine; the credential is the developer. In a shared backend serving many customers, one process means one AWS identity, and the server has no concept of per-user credentials to draw on.
The Data API can absolutely run each tenant's queries under a distinct AWS identity. You assume a per-tenant IAM role, or reference a per-tenant Secrets Manager secret, or map the caller to a database user derived from the IAM identity, where arn:aws:iam::123456789012:user/foo becomes the database user IAM:foo. Every one of those options is real. Every one of them is code you write and infrastructure you operate.
For a B2B agent serving analysts across many customer warehouses, per-tenant isolation is not optional; a query for one customer must never run under another customer's access. The MCP server's single shared credential cannot express that. The Data API can, but it hands you the mechanism, not the management: role assumption, secret storage, credential rotation, and revocation are yours to build. The path changes the token type. It does not change the fact that you owe every tenant an isolated, revocable identity. This is the same challenge covered in depth for access control for multi-tenant AI agents.
The question that decides your on-call load is simple: what breaks, what needs attention, and who owns the fix.
You run the process, which means you own the host, the uv or Docker runtime, and version drift, since @latest pulls server updates on its own cadence. AWS maintains the tool schemas in the open-source repository, and the read-only guard is built in. What you do not get is per-user isolation, a credential vault, or any record of which end user ran which query, because the AWS identity is shared and the process is local.
You own the AWS SDK client, the asynchronous poll loop, pagination, retries, and error handling. More importantly, you own the credential lifecycle described above: mapping each user to an AWS identity, storing secrets, rotating them, and revoking access on offboarding. The Data API is stable and versioned, which suits deterministic pipelines, but the credential machinery around it is the part that decides whether the agent survives a security review. Teams that have gone through this often find that secure token management for AI agents at scale is the most underestimated engineering surface.
Both choices are legitimate for the right agent. The split is about who the agent serves and whether it writes.
Here is the practitioner observation that survives past the comparison table, and it is where most Redshift agents actually get stuck.
AWS gives you strong primitives. IAM roles, Secrets Manager, temporary credentials derived from IAM identity, and CloudTrail are all first-class. Redshift itself enforces database-level grants, so a least-privilege, read-only role stays read-only. These are the right building blocks for a secure agent.
AWS gives you primitives, not a credential management layer for agents. In a multi-tenant agent, every tenant needs its own AWS identity into Redshift: that is N roles or secrets to provision, store encrypted, rotate on schedule, and revoke when a customer churns or an employee leaves. Neither the MCP server nor the Data API stores, refreshes, or revokes those credentials for you. The problem is identical whichever path you chose; only the token type differs.
Recommended reading: the same credential pattern shows up across data warehouses. See Snowflake MCP vs Snowflake API, Google BigQuery MCP vs BigQuery API, and Databricks MCP vs Databricks API.
The Scalekit AWS Redshift connector is built on the Data API and holds each tenant's Redshift access as a per-tenant connected account. Credentials are encrypted, isolated per connected account, and never exposed to the agent runtime; the agent calls tools against a scoped identifier instead of touching AWS credentials directly. The MCP vs API decision no longer changes your auth infrastructure, because Scalekit owns storage, rotation, and revocation on both fronts.
The connector exposes ten Data-API-backed tools, including redshift_list_tables, redshift_describe_table, redshift_execute_sql, redshift_batch_execute_sql, redshift_get_query_result, and redshift_cancel_query. Because it uses the Data API directly, it supports writes, unlike the read-only official MCP server. The example below uses Python and the Claude SDK; a TypeScript path exists with the same method names.
Install the Scalekit SDK alongside your model client, then create the client and grab the actions interface.
For Redshift, the tenant supplies their warehouse access — an IAM role or credentials plus the target cluster or serverless workgroup — through Scalekit's hosted connect flow rather than a browser OAuth consent screen. In code, you confirm the connected account is active before the agent runs. The connection_name must match the connection you configured in the dashboard.
See Authorize a user for production connection handling, and Manage connected accounts for lifecycle details.
Before the agent loop starts, one call decides the tool surface. This is not loading a flat connector catalog; it is loading the Redshift tools this specific tenant's connected account is authorized to call. A summarizing agent that only reads sees the read tools; it never sees a write tool it was never granted. That per-user scoping is what keeps a multi-tenant agent correct and keeps token overhead down. This pattern is a direct answer to how tool calling auth changes when you move from single-tenant to multi-tenant.
With the scoped tools in hand, run the standard Claude tool-use loop. Each tool call routes through execute_tool, which runs against the tenant's connected account. The model chains the Redshift tools on its own: list tables, describe a table, run the query, fetch the result.
If you would rather hand the agent an MCP endpoint than native tools, point your MCP host at a Scalekit-generated URL. This is Scalekit's own scoped endpoint over the Data-API-backed Redshift tools, not the AWS Labs server; it carries per-user scoping and credential isolation with nothing to host.
Setup and the URL are covered in the Virtual MCP servers guide.
The connector solves the parts of a Redshift agent that the two native paths leave to you, and it does so without forcing an MCP versus API choice.
A shared service account gives every user the same access to the same cluster; it cannot express what one tenant is allowed to touch. Connected accounts invert that: scope is a function of identity, so what the user cannot do, the agent cannot do. That is the isolation the read-only MCP server cannot provide and the isolation the Data API makes you build by hand.
Handing a model every tool a connector exposes degrades tool selection and burns tokens before the agent does any work. list_scoped_tools returns only the tools the current tenant is authorized to call, so a read-only reporting agent is not carrying write tools in context. Surface reduction, not sharper prompting, is what improves selection accuracy and lowers cost. The broader challenge of credential ownership across agent tool-calling patterns explains why this scoping matters structurally.
Most real agents are not Redshift-only. A revenue agent might read Redshift, then post to Slack; a briefing agent might join warehouse metrics with CRM data. A virtual MCP server gives that agent one scoped endpoint across every connection it needs, with a short-lived session token minted per user before each run. One server definition serves all tenants; the endpoint is static, the identity is not. Teams use this to ship agents like a revenue-forecast commentary agent or a competitive-intelligence briefing agent without standing up an MCP server per tool.
Because every execute_tool call runs through Scalekit, you get a record of which connected account ran which Redshift tool, when, and whether it succeeded. That downstream tool-calling log is the audit trail a shared local MCP process cannot produce, and it is what a security reviewer asks for first. Teams working through audit trails for agent auth in B2B SaaS will recognize this as a first-class requirement, not an afterthought.
If your Redshift agent is a single analyst exploring a warehouse in their IDE, and it only reads, the official MCP server is a reasonable choice; a shared AWS credential and a read-only guard are enough. If your agent writes, runs on a schedule, or serves more than one customer, use the Data API, because per-tenant identity and write access are requirements the MCP server does not meet. Most production Redshift agents land in the second group, and there the credential problem is the same whichever front door you pick. That is the part that needs infrastructure, and it is the part Scalekit owns for you.
Explore the connector, then wire it into your agent.
Building a Redshift agent and want a second set of eyes on the auth model? Join the Scalekit Slack community, or talk to us for help wiring per-tenant Redshift access into production.
