Agentic Data Plane

AWS Redshift Managed MCP Server

Give agents read-only SQL access to an Amazon Redshift data warehouse through a managed MCP server. On an environment hosted on Amazon Web Services (AWS), AI Gateway can query Redshift by assuming an AWS Identity and Access Management (IAM) role that you create, so you store no credentials.

After reading this page, you will be able to:

  • Grant an IAM role and a database user the access that the AWS Redshift tools need

  • Configure an AWS Redshift MCP server that stores no credentials

  • Troubleshoot AWS Redshift logins and queries that fail

Prerequisites

To set up the server with no stored credentials, you need:

What this MCP server does

The server works with one Amazon Redshift provisioned cluster or Redshift Serverless workgroup through the Amazon Redshift Data API. It offers these tools:

  • query: Runs one read-only SQL statement against the database that you configure, and returns the rows.

  • list_databases: Lists the databases that the connection can reach.

  • list_schemas: Lists the schemas in a database.

  • list_tables: Lists the tables and views in a database, optionally filtered by schema.

  • describe_table: Returns the columns of a table or view.

The list_schemas, list_tables, and describe_table tools use the database that you configure, unless an agent names another one.

Rules for the query tool

The query tool runs one statement per call. The statement must start with SELECT, WITH, SHOW, VALUES, or TABLE, or be an EXPLAIN of one of those. The tool rejects SELECT ... INTO and statements that change data. A query returns up to 1,000 rows by default, and an agent can ask for up to 100,000.

The database user’s grants still decide which data agents can read. See Grant database access.

Choose how the server authenticates to AWS

The server’s Auth section sets the AWS region and how the server authenticates to AWS. It offers the same three methods as the other AWS types: Gateway Assume Role, Assume Role, and Static Credentials. To learn how each one works, see Choose an authentication method in AWS Managed MCP Servers.

On an environment hosted on AWS, choose Gateway Assume Role so that Agentic Data Plane stores no AWS credentials. Before you rely on it, review its limits in AWS Managed MCP Servers.

Choose how the server logs in to the database

The server’s Database Auth section sets how the Amazon Redshift Data API logs in to the database. None of the three methods stores a database password in Agentic Data Plane.

Method How the Data API logs in Deployments

Iam Identity

As the database user that Redshift derives from the calling AWS identity. For a role, that’s IAMR: followed by the role name. For an IAM user, it’s IAM: followed by the user name.

Provisioned clusters and Redshift Serverless

Secrets Manager Secret

With the username and password in an AWS Secrets Manager secret that you name by its Amazon Resource Name (ARN).

Provisioned clusters and Redshift Serverless

Db User

As a database user that you name, with temporary credentials that Redshift issues through IAM.

Provisioned clusters only

Choose Iam Identity. It works on both provisioned clusters and Redshift Serverless, and it needs no password or secret, because Redshift derives the database user from the IAM identity. With Gateway Assume Role, the database user is IAMR: followed by the name of the role that you create, without its path. For example, the role arn:aws:iam::123456789012:role/redpanda-adp/orders-reader logs in as IAMR:orders-reader. To give that user access to data, see Grant database access.

Grant the permissions the tools need

Write a permissions policy that grants the actions the server’s tools need, and save it as permissions-policy.json. The role’s permissions policy decides what the server can do in AWS, so grant only the actions for the tools your agents use:

Tool IAM actions Resource

query

redshift-data:ExecuteStatement, plus redshift-data:DescribeStatement and redshift-data:GetStatementResult

The cluster or workgroup for ExecuteStatement. The other two actions don’t support resource-level permissions, so grant them on *.

list_databases, list_schemas, list_tables, and describe_table

redshift-data:ListDatabases, redshift-data:ListSchemas, redshift-data:ListTables, and redshift-data:DescribeTable

The cluster, arn:aws:redshift:<region>:<aws-account-id>:cluster:<cluster-name>, or the workgroup, arn:aws:redshift-serverless:<region>:<aws-account-id>:workgroup/<workgroup-id>

The server also needs the permissions that go with its database login method:

  • Iam Identity on Redshift Serverless: redshift-serverless:GetCredentials on the workgroup

  • Iam Identity on a provisioned cluster: redshift:GetClusterCredentialsWithIAM on the database, arn:aws:redshift:<region>:<aws-account-id>:dbname:<cluster-name>/<database>

  • Db User: redshift:GetClusterCredentials on the database user, arn:aws:redshift:<region>:<aws-account-id>:dbuser:<cluster-name>/<db-user>, and on the database’s dbname ARN

  • Secrets Manager Secret: secretsmanager:GetSecretValue on the secret, plus kms:Decrypt on its key if a customer managed key from AWS Key Management Service (AWS KMS) encrypts the secret

On a provisioned cluster, an agent that names another database in list_schemas, list_tables, or describe_table makes the server log in to that database. For Iam Identity and Db User, grant the login permission on each database that agents use, or on all of them with arn:aws:redshift:<region>:<aws-account-id>:dbname:<cluster-name>/*.

A workgroup’s ARN contains the workgroup’s ID, not its name. To look it up, run this command and read workgroupArn:

aws redshift-serverless get-workgroup --workgroup-name <workgroup-name>

For example, this permissions policy lets a server use every tool on a Redshift Serverless workgroup and log in with Iam Identity:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "redshift-data:ExecuteStatement",
        "redshift-data:ListDatabases",
        "redshift-data:ListSchemas",
        "redshift-data:ListTables",
        "redshift-data:DescribeTable",
        "redshift-serverless:GetCredentials"
      ],
      "Resource": "arn:aws:redshift-serverless:us-east-1:123456789012:workgroup/<workgroup-id>"
    },
    {
      "Effect": "Allow",
      "Action": [
        "redshift-data:DescribeStatement",
        "redshift-data:GetStatementResult"
      ],
      "Resource": "*"
    }
  ]
}

Replace the first statement’s Resource with your workgroup’s ARN, the workgroupArn value from aws redshift-serverless get-workgroup.

If a customer managed key in AWS KMS encrypts the cluster or workgroup, the Data API uses the same key for queries and results. Amazon Redshift creates a grant for the key on your behalf, so the key’s policy must allow principals in your account to call kms:CreateGrant through Amazon Redshift. For an example key policy, see the AWS guide to using AWS KMS with the Data API.

Create the IAM role

The role works the same way for every AWS type. Create it with the steps in AWS Managed MCP Servers:

  1. Collect the values that the role’s trust policy needs: the environment ID, the AWS account ID, the server name, AI Gateway’s role ARN, and the server’s external ID. See Gather the values the trust policy needs in AWS Managed MCP Servers.

  2. Create the role under the /redpanda-adp/ path, and add the permissions policy that you saved as permissions-policy.json. See Create the IAM role in AWS Managed MCP Servers.

Grant database access

The database user needs read access to the data that agents query. With Db User, grant that access to the user you name. With Secrets Manager Secret, grant it to the user in the secret. With Iam Identity, Redshift creates the IAMR: user the first time the role logs in. To grant access before the first query, create the user yourself with an admin account:

CREATE USER "IAMR:<role-name>" PASSWORD DISABLE;
GRANT USAGE ON SCHEMA <schema> TO "IAMR:<role-name>";
GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO "IAMR:<role-name>";

Replace <role-name> with the name of the role you created, without its path, and <schema> with a schema that agents query. Repeat the two GRANT statements for each schema that agents need.

Create the server

Create the server in the Agentic Data Plane UI:

  1. Open MCP servers in the sidebar.

  2. Click Add MCP server.

  3. Click the AWS Redshift card.

  4. Replace the suggested Name with the server name that you used in the role’s external ID, and optionally add a Description.

  5. Leave Enable code mode off. It’s off by default for database types.

  6. In the Auth section:

    1. Set Region to the AWS region of the cluster or workgroup, for example us-east-1.

    2. Leave Endpoint empty.

    3. In the Auth selector, choose Gateway Assume Role.

    4. Set Role Arn to the ARN of the role you created, for example arn:aws:iam::123456789012:role/redpanda-adp/orders-reader.

    5. Optional: Set Duration Seconds, the length of each AWS session. Keep 0 for the default of 900 seconds, or choose a value from 900 to 3600.

  7. Set Database to the name of the database that the query tool runs against, for example dev.

  8. In Connection, choose Provisioned Cluster and set Cluster Identifier, or choose Serverless Workgroup and set Workgroup Name.

  9. In Database Auth, under Method, choose Iam Identity. To use Secrets Manager Secret instead, choose it and enter the secret’s ARN. To use Db User on a provisioned cluster, choose it and enter the user’s name. See Choose how the server logs in to the database.

  10. Click Create server.

Create the server with rpk ai

Run rpk ai mcp-server create with an AWS Redshift --managed.config payload. This example creates the orders-warehouse server, which queries a Redshift Serverless workgroup and logs in with Iam Identity:

rpk ai mcp-server create orders-warehouse --enabled --managed.config '{
  "@type": "type.googleapis.com/redpanda.mcps.aws_redshift.v1.AWSRedshiftMCPConfig",
  "auth": {
    "region": "us-east-1",
    "gateway_assume_role": {
      "role_arn": "arn:aws:iam::123456789012:role/redpanda-adp/orders-reader"
    }
  },
  "database": "dev",
  "serverless_workgroup": { "workgroup_name": "analytics" },
  "database_auth": { "iam_identity": {} }
}'

For a provisioned cluster, replace serverless_workgroup with "provisioned_cluster": { "cluster_identifier": "<cluster-name>" }. For the other login methods, set database_auth to { "secrets_manager_secret": "<secret-arn>" } or, on a provisioned cluster, { "db_user": "<db-user>" }.

Verify the connection

Creating the server succeeds even if AI Gateway can’t assume the role, so check the connection before an agent uses the server:

  1. Open the server’s Inspector tab.

  2. Confirm that the tool list loads. If AI Gateway can’t assume the role, the tab shows the error instead. See Troubleshooting in AWS Managed MCP Servers.

  3. Optional: To check the permissions policy and the database user’s access too, run the query tool from the Inspector tab with a SELECT from a table that agents need. See Run a tool.

Troubleshooting

For errors about assuming the role, such as one containing AWS answered AccessDenied, see Troubleshooting in AWS Managed MCP Servers. This table covers the errors specific to AWS Redshift:

Symptom What to check

Saving the server fails with Redshift Serverless does not accept a database user. Use a Secrets Manager secret or the IAM identity instead.

The server can’t log in to a Redshift Serverless workgroup with Db User. Choose Iam Identity or Secrets Manager Secret.

Saving the server fails with Secret ARN must look like arn:aws:secretsmanager:us-east-1:123456789012:secret:my-secret.

Enter the secret’s full ARN, not its name.

Running rpk ai mcp-server create fails with invalid protojson for google.protobuf.Any, followed by unable to resolve and the AWS Redshift @type

Your rpk ai plugin predates the AWS Redshift type. Run rpk ai upgrade to update it.

The query tool fails with only read-only statements are allowed, multiple SQL statements are not allowed, or an error ending in this MCP is read-only

The tool runs one read-only statement per call. See Rules for the query tool.

A query fails with an error containing permission denied for

The database user lacks access to the schema or table. Grant the user USAGE on the schema and SELECT on the tables. With Iam Identity, the user is IAMR: followed by the role’s name for a role, or IAM: followed by the user’s name for an IAM user. See Grant database access.

A tool call fails with an AWS authorization error, such as AccessDenied

The role’s permissions policy doesn’t allow the action that the tool or the login method needs. See Grant the permissions the tools need.

Next steps