Integrating AWS MCP Servers with Quick - Data Processing Example

This article provides a comprehensive guide for extending Amazon Quick capabilities by integrating custom action connectors using the Model Context Protocol (MCP) with Amazon Agent Core Runtime. It explains how to connect Quick to custom or third-party systems, using the AWS Data Processing MCP Server as a reference implementation. The solution enables natural language SQL queries over LakeHouse data and Glue Catalog awareness for autonomous schema introspection.

Enrique_S

Published May 5, 2026

Last modified May 5, 2026

Introduction and purpose

This document provides architectural guidance and a step-by-step implementation reference for customers who want to extend the native capabilities of Amazon Quick Suite by integrating custom action connectors built on the Model Context Protocol (MCP). It is intended to help customers who have developed their own MCP server — or have access to an existing one — deploy it to the Amazon Agent Core runtime and connect it seamlessly to Quick Suite, enabling agents, flows, and automations to leverage custom tools and integrations beyond the platform's built-in connector catalog.

To illustrate the end-to-end process with a concrete and reproducible example, this guide uses the AWS Data Processing MCP Server, an open-source MCP server developed and maintained by AWS Labs and available in the awslabs GitHub repository . While this specific server is used as the reference implementation throughout the guide, the architecture pattern, deployment steps, and integration procedures described here are broadly applicable to any MCP-compliant server— including other AWS MCP servers, third-party MCP implementations, or custom-built solutions developed in-house.

After following this guide, you will be able to:

Understand the architectural components involved in connecting a custom MCP server to Quick Suite via Agent Core.
Deploy an MCP server to the Agent Core runtime in a secure, scalable, and production-ready manner.
Register the deployed MCP server as a custom action connector within Quick Suite.
Validate the integration end-to-end and make custom actions available to Quick Suite agents, flows, and automations.

Pre-requisites and assumptions

Before proceeding with this guide, we encourage the reader to meet the following pre-requisites and be aware of the assumptions under which this document has been written.

Knowledge Pre-requisites

Familiarity with Generative AI Agents: Readers should have a basic understanding of what a generative AI agent is, including how agents use tools and actions to fulfil user requests, how they are configured, and how they interact with external systems.

Familiarity with the Model Context Protocol (MCP): Readers should understand the MCP standard and what it is used for, e.g. concepts of MCP servers, tools, resources, and the client-server communication model. Deep expertise in MCP is not required but understanding what an MCP server exposes and how it is consumed by an MCP client is assumed. Readers unfamiliar with MCP can review the MCP specification before proceeding.

Infrastructure and Access Pre-requisites

AWS Account: An active AWS account is required to deploy and operate the components described in this guide, including the Agent Core runtime and any associated AWS services.

Amazon Quick Suite (with an enterprise subscription): This guide applies to customers with an active Amazon Quick Suite subscription. All the steps mentioned in this guide should be performed using a Quick enterprise (refer to this documentation to understand the different license types).

Supported AWS Region: The AWS account must be configured to operate in one of the AWS regions where Amazon Quick Suite is available with full capabilities enabled. Please refer to the Amazon Quick Suite Regional Availability page to get the most up to date list of regions supporting all Quick features before proceeding.

Assumptions

The reader has access to the MCP server source code they intend to deploy or is using the reference implementation (AWS Data Processing MCP Server) provided in this guide.
The reader has sufficient AWS IAM permissions to create and manage the resources required throughout this guide (e.g., IAM roles, container registries, Agent Core endpoints).
The Quick Suite environment has already been provisioned and is operational. This guide does not cover the initial setup or provisioning of Amazon Quick Suite.
All examples and procedures in this guide have been validated against the AWS Data Processing MCP Server available in the awslabs GitHub repository . The procedure should be valid for other MCP server implementations.

Foundational components

Amazon Quick Suite

Amazon Quick is an enterprise AI platform that combines business intelligence, generative AI, and workplace productivity into a unified environment. At its core, Quick Suite enables organizations to connect their data, automate workflows, and deploy AI-powered agents that can interact with both internal systems and external services using actions. Amazon Quick ships with a wide set of bundled connectors, however there are many real-world scenarios where organizations need to go beyond what the native catalog provides. Custom MCP-based connectors are the best path forward.

Model Context Protocol (MCP)

The Model Context Protocol (MCP) is an open standard that defines a uniform way for AI applications and agents to connect with external tools, data sources, and services. Developed to address the fragmentation problem in AI integrations — where every application historically required bespoke connectors for every external system — MCP provides a common language and communication model that any AI client can use to discover and invoke capabilities exposed by any MCP-compliant server.

Agent Core Platform

Amazon Agent Core is a fully managed AWS service designed to simplify the deployment, hosting, and operation of AI agent components and their dependencies. It provides the foundational infrastructure layer that allows organisations to build and run production-grade AI agents without managing the underlying compute, scaling, or networking concerns themselves.

For the purposes of this guide, we will be using one of its features, Agent Core Runtime . Agent Core Runtime is a managed container execution environment purpose-built for hosting MCP servers and other agent tool backend as secure, scalable, and accessible HTTPS endpoints. It is the component responsible for receiving the MCP server container image, running it in a managed environment, and exposing it over a stable endpoint that external clients — such as Amazon Quick Suite — can invoke at runtime.

Architecture overview

The diagram shown below illustrates the high-level architecture and how all the components integrate with each other. The tools provided by the MCP server (Data Processing MCP in this case) are packaged and deployed to a container that is then fronted by a public endpoint in Agent Core runtime.

In order to ensure authorised access Cognito is configured as authentication layer where a user pool and a custom domain with a resource server provide secure access to protected resources implementing an OAuth 2.0 API server providing M2M access grants to resources with an specific access level (scopes in the token claims).

Once request is authorised the logic implemented on the tools defined on the MCP server allows perform operations on the underlying resources (in this example Data Analytics services) that are executed using the existing APIs (via the boto3 python SDK in this case).

Quick acts as the front-end where its agents powered by LLMs provide the reasoning logic that decides what tool -or set of tools- (from those offered by the server) needs to be used to solve a particular problem, decomposing it into small task if needed. The tools are not only available to Quick AI agents but also to flows , automation and even research as the custom action connector is added to a Quick space that then is used to make this resources available to all Quick assets.

Solution Architecture Diagram — High Level Archiecture Diagram

Data Flow

The AWS Data Processing MCP Server data flow begins when a Quick agent (or entity using the custom action connector) sends an authenticated request through HTTPS to the Amazon Bedrock AgentCore Runtime (1). AgentCore validates the OAuth token (2) and routes the request to a containerised MCP server instance (3), automatically scaling containers based on demand. The MCP server processes the tool invocation by translating it into appropriate AWS SDK calls using boto3 (4), which interact with services like AWS Glue for ETL operations, Amazon EMR for distributed data processing, or Amazon Athena for SQL analytics. These services execute the requested operations on data stored in Amazon S3 (5) or other data sources, returning results back through the chain (6). For long-running operations, the server can leverage AgentCore Memory (not included on this example) to persist intermediate results and final outputs, enabling asynchronous processing that survives container restarts and allows users to retrieve results across different sessions. Throughout this flow, CloudWatch can be configured to capture logs and metrics for monitoring, while IAM roles enforce fine-grained security policies at each integration point.

Implementation Guide

Pre-requisites

Before continuing, please ensure that the system meets the following requirements.

Python 3.10 or higher installed
AWS account with appropriate permissions
AWS CLI configured with valid credentials
AgentCore starter toolkit installed:

1
pip install bedrock-agentcore-starter-toolkit

MCP project following this structure

1
2
3
4
5
6
7
8
9
aws-dataprocessing-mcp-server/
├── awslabs/
│   └── aws_dataprocessing_mcp_server/
│       ├── server.py              # Main MCP server
│       ├── handlers/              # Tool handlers
│       ├── models/                # Data models
│       └── utils/                 # Utilities
├── requirements.txt               # Python dependencies
└── __init__.py                    # Package marker

Step-by-Step Implementation

Step 1: Setup Authentication

Create a Cognito user pool for authentication:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
# Set environment variables
export REGION=us-east-1  # Change to your preferred region
export USERNAME=your-username
export PASSWORD=your-secure-password

# Step 1: Create User Pool
export POOL_ID=$(aws cognito-idp create-user-pool \
  --pool-name "DataProcessingMCPUserPool" \
  --policies '{"PasswordPolicy":{"MinimumLength":8}}' \
  --region $REGION | jq -r '.UserPool.Id')

echo "✅ User pool created: $POOL_ID"

# Step 2: Create Cognito Domain for OAuth endpoints
DOMAIN_NAME="mcp-runtime-$(echo $POOL_ID | tr '_' '-' | tr '[:upper:]' '[:lower:]')"
aws cognito-idp create-user-pool-domain \
  --domain "$DOMAIN_NAME" \
  --user-pool-id $POOL_ID \
  --region $REGION

export COGNITO_DOMAIN="$DOMAIN_NAME"
echo "✅ Cognito domain: https://$COGNITO_DOMAIN.auth.$REGION.amazoncognito.com"

# Step 3: Create Resource Server for M2M authentication
aws cognito-idp create-resource-server \
  --user-pool-id $POOL_ID \
  --identifier "mcp" \
  --name "MCPRuntimeResourceServer" \
  --scopes ScopeName=stream,ScopeDescription="MCP Stream Access" \
  --region $REGION

echo "✅ Resource server created"

# Step 4: Create App Client WITH SECRET for OAuth authentication
CLIENT_RESPONSE=$(aws cognito-idp create-user-pool-client \
  --user-pool-id $POOL_ID \
  --client-name "QuickSuiteMCPServerClient" \
  --generate-secret \
  --allowed-o-auth-flows "code" \
  --callback-urls "https://$REGION.quicksight.aws.amazon.com/sn/oauthcallback" \
  --allowed-o-auth-scopes "openid" "mcp/stream" \
  --allowed-o-auth-flows-user-pool-client \
  --supported-identity-providers COGNITO \
  --explicit-auth-flows ALLOW_USER_PASSWORD_AUTH ALLOW_REFRESH_TOKEN_AUTH \
  --region $REGION)

export CLIENT_ID=$(echo $CLIENT_RESPONSE | jq -r '.UserPoolClient.ClientId')
export CLIENT_SECRET=$(echo $CLIENT_RESPONSE | jq -r '.UserPoolClient.ClientSecret')

echo "✅ App client created: $CLIENT_ID"

# Step 5: Create Test User
aws cognito-idp admin-create-user \
  --user-pool-id $POOL_ID \
  --username $USERNAME \
  --region $REGION \
  --message-action SUPPRESS

# Step 6: Set Permanent Password
aws cognito-idp admin-set-user-password \
  --user-pool-id $POOL_ID \
  --username $USERNAME \
  --password $PASSWORD \
  --region $REGION \
  --permanent

echo "✅ User created: $USERNAME"

# Step 7: Get Bearer Token for testing
SECRET_HASH=$(echo -n "${USERNAME}${CLIENT_ID}" | openssl dgst -sha256 -hmac "${CLIENT_SECRET}" -binary | base64)

export BEARER_TOKEN=$(aws cognito-idp initiate-auth \
  --client-id "$CLIENT_ID" \
  --auth-flow USER_PASSWORD_AUTH \
  --auth-parameters USERNAME=$USERNAME,PASSWORD=$PASSWORD,SECRET_HASH=$SECRET_HASH \
  --region $REGION | jq -r '.AuthenticationResult.AccessToken')

# Step 8: Get OAuth endpoints
DISCOVERY_URL="https://cognito-idp.${REGION}.amazonaws.com/${POOL_ID}/.well-known/openid-configuration"
OIDC_CONFIG=$(curl -s $DISCOVERY_URL)
AUTH_URL=$(echo $OIDC_CONFIG | jq -r '.authorization_endpoint')
TOKEN_URL=$(echo $OIDC_CONFIG | jq -r '.token_endpoint')

# Output all configuration values
echo ""
echo "=== Runtime Deployment Configuration ==="
echo "Pool ID: $POOL_ID"
echo "Discovery URL: $DISCOVERY_URL"
echo "Client ID: $CLIENT_ID"
echo "Client Secret: $CLIENT_SECRET"
echo "Bearer Token: $BEARER_TOKEN"
echo ""
echo "=== OAuth Configuration (for QuickSight/Gateway) ==="
echo "Auth URL: $AUTH_URL"
echo "Token URL: $TOKEN_URL"
echo "Scopes: openid mcp/stream"
echo "Cognito Domain: https://$COGNITO_DOMAIN.auth.$REGION.amazoncognito.com"

Save these output values - you'll need them for deployment and testing.

(optional) Step 2: Run MCP Server for local test

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#!/bin/bash

# Simple script to start the AWS Data Processing MCP Server locally
# Handles the Python module path correctly

echo "🚀 Starting AWS Data Processing MCP Server"
echo ""

# Check if dependencies are installed
if ! python -c "import mcp" 2>/dev/null; then
    echo "⚠️  MCP package not found. Installing dependencies..."
    pip install -r requirements.txt
    echo ""
fi

# Parse arguments
ARGS=""
if [[ "$*" == *"--allow-write"* ]]; then
    ARGS="$ARGS --allow-write"
    echo "✅ Write operations enabled"
fi

if [[ "$*" == *"--allow-sensitive-data-access"* ]]; then
    ARGS="$ARGS --allow-sensitive-data-access"
    echo "✅ Sensitive data access enabled"
fi

if [ -z "$ARGS" ]; then
    echo "ℹ️  Running in read-only mode"
    echo "   Use --allow-write to enable write operations"
    echo "   Use --allow-sensitive-data-access to enable sensitive data access"
fi

echo ""
echo "Server will start on http://localhost:8000"
echo "Press Ctrl+C to stop"
echo ""
echo "To test the server, run in another terminal:"
echo "  python local_test_client.py"
echo ""

# Start the server using Python module syntax
python -m awslabs.aws_dataprocessing_mcp_server.server $ARGS

(optional) Step 3: Test local connection

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
#!/bin/bash

# Quick local testing script for AWS Data Processing MCP Server
# This script helps you test the server locally before deploying to AgentCore

set -e

echo "🧪 AWS Data Processing MCP Server - Local Testing"
echo "=================================================="
echo ""

# Check if server is already running
if lsof -Pi :8000 -sTCP:LISTEN -t >/dev/null 2>&1 ; then
    echo "✅ Server is already running on port 8000"
    echo ""
    SERVER_RUNNING=true
else
    echo "⚠️  Server is not running on port 8000"
    echo ""
    SERVER_RUNNING=false
fi

# Show menu
echo "What would you like to do?"
echo ""
echo "  1) Start the server (read-only mode)"
echo "  2) Start the server (with write operations)"
echo "  3) Start the server (all features enabled)"
echo "  4) Test the server (basic tests)"
echo "  5) Test the server (interactive mode)"
echo "  6) Open MCP Inspector"
echo "  7) Stop the server"
echo "  8) View server logs"
echo "  9) Check AWS credentials"
echo "  0) Exit"
echo ""

read -p "Enter choice [0-9]: " choice

case $choice in
    1)
        echo ""
        echo "🚀 Starting server in read-only mode..."
        echo "   Press Ctrl+C to stop"
        echo ""
        python -m awslabs.aws_dataprocessing_mcp_server.server
        ;;
    
    2)
        echo ""
        echo "🚀 Starting server with write operations enabled..."
        echo "   Press Ctrl+C to stop"
        echo ""
        python -m awslabs.aws_dataprocessing_mcp_server.server --allow-write
        ;;
    
    3)
        echo ""
        echo "🚀 Starting server with all features enabled..."
        echo "   Press Ctrl+C to stop"
        echo ""
        python -m awslabs.aws_dataprocessing_mcp_server.server --allow-write --allow-sensitive-data-access
        ;;
    
    4)
        if [ "$SERVER_RUNNING" = false ]; then
            echo ""
            echo "❌ Server is not running!"
            echo ""
            echo "Start the server first:"
            echo "  Option 1: ./test_local.sh (choose option 1, 2, or 3)"
            echo "  Option 2: python -m awslabs.aws_dataprocessing_mcp_server.server"
            echo ""
            exit 1
        fi
        
        echo ""
        echo "🧪 Running basic tests..."
        echo ""
        python local_test_client.py
        ;;
    
    5)
        if [ "$SERVER_RUNNING" = false ]; then
            echo ""
            echo "❌ Server is not running!"
            echo ""
            echo "Start the server first:"
            echo "  Option 1: ./test_local.sh (choose option 1, 2, or 3)"
            echo "  Option 2: python -m awslabs.aws_dataprocessing_mcp_server.server"
            echo ""
            exit 1
        fi
        
        echo ""
        echo "🎯 Starting interactive mode..."
        echo ""
        python local_test_client.py --interactive
        ;;
    
    6)
        echo ""
        echo "🔍 Opening MCP Inspector..."
        echo ""
        echo "The inspector will open at http://localhost:6274"
        echo ""
        echo "To connect to your local server:"
        echo "  1. Select 'Streamable HTTP' transport"
        echo "  2. Enter URL: http://localhost:8000/mcp"
        echo "  3. Leave authentication empty"
        echo "  4. Click 'Connect'"
        echo ""
        echo "Press Ctrl+C to stop the inspector"
        echo ""
        npx @modelcontextprotocol/inspector
        ;;
    
    7)
        echo ""
        echo "🛑 Stopping server..."
        
        if lsof -Pi :8000 -sTCP:LISTEN -t >/dev/null 2>&1 ; then
            PID=$(lsof -Pi :8000 -sTCP:LISTEN -t)
            kill -9 $PID
            echo "✅ Server stopped (PID: $PID)"
        else
            echo "⚠️  No server running on port 8000"
        fi
        echo ""
        ;;
    
    8)
        echo ""
        echo "📋 Server logs:"
        echo ""
        echo "If you started the server in another terminal, check that terminal for logs."
        echo ""
        echo "To start server with verbose logging:"
        echo "  FASTMCP_LOG_LEVEL=DEBUG python -m awslabs.aws_dataprocessing_mcp_server.server"
        echo ""
        ;;
    
    9)
        echo ""
        echo "🔐 Checking AWS credentials..."
        echo ""
        
        if ! command -v aws &> /dev/null; then
            echo "❌ AWS CLI is not installed"
            echo "   Install from: https://aws.amazon.com/cli/"
            exit 1
        fi
        
        echo "Current AWS identity:"
        aws sts get-caller-identity || {
            echo ""
            echo "❌ AWS credentials not configured!"
            echo ""
            echo "Configure with:"
            echo "  aws configure"
            echo ""
            echo "Or set environment variables:"
            echo "  export AWS_ACCESS_KEY_ID=your-key"
            echo "  export AWS_SECRET_ACCESS_KEY=your-secret"
            echo "  export AWS_REGION=us-east-1"
            exit 1
        }
        
        echo ""
        echo "✅ AWS credentials are configured"
        echo ""
        
        # Check region
        REGION=$(aws configure get region)
        if [ -z "$REGION" ]; then
            echo "⚠️  AWS region not set"
            echo "   Set with: aws configure set region us-east-1"
        else
            echo "Region: $REGION"
        fi
        echo ""
        ;;
    
    0)
        echo ""
        echo "👋 Goodbye!"
        echo ""
        exit 0
        ;;
    
    *)
        echo ""
        echo "❌ Invalid choice"
        echo ""
        exit 1
        ;;
esac

Step 4: Configure deployment

In order to deploy to AgentCore Amazon Bedrock AgentCore starter toolkit in Python will be used. The starter toolkit is a Command Line Interface (CLI) toolkit that you can use to deploy AI agents to an Amazon Bedrock AgentCore Runtime easily.

As a first step Run the configuration wizard:

1
agentcore configure -e awslabs/aws_dataprocessing_mcp_server/server.py --protocol MCP

The wizard will prompt you for the following info, provide values as instructed on the table below:

Option	Value
Agent Name	Name for the agent you want to create (e.g. awslabs_aws_dataprocessing_mcp_server_server)
Detected dependency file	If you have a requirements.txt file on the project root this will be automatically identified as default option.
Deployment Configuration	Select 1 to directly package and upload your project as a zip
Python runtime version	Select the appropriate version for your code. For Data Processing you can keep the default 1. PYTHON_3_10
Execution Role	An existing IAM execution role with permissions to perform operations needed by the agent. For Data Processing MCP refer to the setup section on the documentation. Press enter to auto create one
S3 URI/path	The S3 bucket and prefix where your code will be uploaded to, press enter to automatically create a bucket for this purpose.
Authorization Configuration	Enter yes
Authorization Configuration (OAuth discovery URL)	Enter the Discovery URL value you got from the execution of the script in Step 1. Format: https://cognito-idp.<your_region>.amazonaws.com/<POOL_ID>/.well-known/openid-configuration
Authorization Configuration (OAuth client ID)	Enter the Client ID value you got from the execution of the script in Step 1.
Authorization Configuration (allowed OAuth audience)	Empty
Authorization Configuration (allowed scopes)	Empty
Authorization Configuration (custom claims)	Empty
Request Header Allowlist	No
Memory Configuration	S (skip)

Step 5: Deploy to Agent Core

To deploy your MCP server simply execute:

1
agentcore launch

This command will take the previously configured parameter values:

Build a Docker container with your server
Push it to Amazon ECR
Create an AgentCore Runtime
Deploy your server to AWS

After deployment, you'll receive an Agent Runtime ARN:

arn:aws:bedrock-agentcore:eu-west-1:123456789012:runtime/aws-dataprocessing-mcp-server-xyz123

Note down this ARN as you will need it later in the process.

(optional) Step 7: Test Agent Core client

Prerequisites:

Export the following variables as they are needed by the script, refer to Appendix A to get more details about how to calculate the bearer token.

1
2
export AGENT_ARN="your-agent-runtime-arn"
export BEARER_TOKEN="your-bearer-token"

You can test your deployment using the python script you can find below, not that the script is prepared to work with the AWS Data Processing MCP server, you will need to tweak it to make it work if you are using a different AWS MCP server or your custom MCP server.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
import asyncio
import os
import sys
from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client

async def main():
    agent_arn = os.getenv('AGENT_ARN')
    bearer_token = os.getenv('BEARER_TOKEN')
    
    if not agent_arn or not bearer_token:
        print("Error: AGENT_ARN or BEARER_TOKEN environment variable is not set")
        sys.exit(1)
    
    # Encode ARN for URL
    encoded_arn = agent_arn.replace(':', '%3A').replace('/', '%2F')
    mcp_url = f"https://bedrock-agentcore.eu-west-1.amazonaws.com/runtimes/{encoded_arn}/invocations?qualifier=DEFAULT"
    
    headers = {
        "authorization": f"Bearer {bearer_token}",
        "Content-Type": "application/json"
    }
    
    print(f"Connecting to: {mcp_url}\n")
    
    async with streamablehttp_client(mcp_url, headers, timeout=120, terminate_on_close=False) as (
        read_stream,
        write_stream,
        _,
    ):
        async with ClientSession(read_stream, write_stream) as session:
            await session.initialize()
            
            # List available tools
            tools = await session.list_tools()
            print("Available tools:")
            for tool in tools.tools:
                print(f"  - {tool.name}: {tool.description}")
            
            # Example: List Glue databases
            result = await session.call_tool(
                "manage_aws_glue_databases",
                {"operation": "list-databases"}
            )
            print(f"\nResult: {result}")

if __name__ == "__main__":
    asyncio.run(main())

Step 6: Register with Quick Suite

Before continuing make sure you have ready the values for the following variables:

Variable	Value
RUNTIME_ARN	ARN of the runtime deployed on Step 5
RUNTIME_ENDPOINT	URL for the runtime calculated following the process outlined in Appendix B
USER_CLIENT_ID	Client id gathered from Step 1
CLIENT_SECRET	Client secret generated in Step 1
CALLBACK_URL	CALLBACK URL for Quick: https://<region>.quicksight.aws.amazon.com/sn/oauthcallback
AUTH_URL	Refer to Appendix C for the procedure to extract this value from the Discovery URL generated in Step 1
TOKEN_URL	Refer to Appendix C for the procedure to extract this value from the Discovery URL generated in Step 1
USERNAME	Username configured in Step 1
PASSWORD	Password configured in Step 1

Once you have all the values ready navigate to the QuickSuite console in your region (e.g. eu-west-1) to perform the following steps:

1. In the left side pane click on Integrations (under Connect apps and data section)

Click on actions and then under Set up a new app integration for Actions click on Model Context Protocol, you will see a connection wizard with four steps like the following

3. Provide a name and a description (provide as many details as possible as this will be used by agent, and flow builder to select the action whenever it is appropriate)

4. For MCP server endpoint provide the value you calculated for RUNTIME_ENDPOINT, refer to Appendix B for more details.

5. On the Authenticate section, select User authentication (default) and enter the following values:

1. Client ID: USER_CLIENT_ID value from table at the beginning of this step.

2. Client secret: CLIENT_SECRET value from table at the beginning of this step.

3. Token URL: TOKEN_URL value from table at the beginning of this step.

4. Authorization URL: AUTH_URL value from table at the beginning of this step.

6. Click on next and a pop-up will appear so you can enter the USERNAME and PASSWORD you configured for your Cognito user pool, once this information is provided you should see a list of the tools provided by the MCP server (e.g. for the mcp data processing server):

Once you have reviewed the tools click on Next and Done in the next step (share) to have the action connector added. This may take some minutes to complete.
(optional but recommended) Create a space and add the action to it

Step 7: Test End-to-End

Option A: Validate via a Custom Agent Connected to the LakeHouse Space

Step 1 – Create a Custom Agent

In the Quick Suite web app, go to the navigation side panel and click on Agents, then click Create.
Provide a name, description, and custom instructions for the agent (e.g., "You are a data processing assistant with access to AWS data services via the LakeHouse connector").
Under Knowledge & Actions, make sure that the LakeHouse Space created in Step 6 is added. This grants the agent access to the MCP tools.
Save and publish the agent.

Step 2 – Test the Agent End-to-End

Open a chat session with the newly created agent.
Send a test prompt that exercises one of the MCP server tools for example:
- List the available Glue databases
- Run a query on Athena for table X
- Ask the agent to run more complex queries on normalized table data; Give me the sales grouped by country (the tool should be able to create a SQL query that joins sales and country table data)
Confirm the agent:
- Correctly identify the appropriate tool from the MCP server.
- Successfully authenticates via Cognito and invokes the Agent Core endpoint (the first time it will ask you to provide the user/password credentials)
- Returns a valid, expected result from the underlying AWS data service (Glue, Athena, S3, etc.).

Option B: Validate Directly from the Quick Chat Agent Window (LakeHouse Space in Focus)

Step 1 – Open the Quick Chat Agent Window

Open Amazon Quick Suite (web app or Word add-in side panel).
Open a chat session with any available chat agent (e.g., My Assistant).

Step 2 – Select the LakeHouse Space

In the chat footer, click on the Knowledge setting.
From the list of available Spaces, select the LakeHouse Space (the one containing the MCP action connector).
This scopes the agent's knowledge and available actions to the LakeHouse Space.

Step 3 – Invoke a Tool via Natural Language

Send a test prompt that maps to one of the tools exposed by the MCP for example:
- List the available Glue databases
- Run a query on Athena for table X
- Ask the agent to run more complex queries on normalized table data; Give me the sales grouped by country (the tool should be able to create a SQL query that joins sales and country table data)
Confirm the agent:
- Correctly identify the appropriate tool from the MCP server.
- Successfully authenticates via Cognito and invokes the Agent Core endpoint (the first time it will ask you to provide the user/password credentials)
- Returns a valid, expected result from the underlying AWS data service (Glue, Athena, S3, etc.).

Troubleshooting

Authentication & Authorization Failures (HTTP 401 / 403)

These errors typically indicate a problem with the Cognito token or OAuth configuration. Confirm that the Cognito App Client is configured with the correct allowed OAuth scopes (openid and mcp/stream) and that the resource server identifier (mcp) matches what is referenced in the token claims. If the error occurs specifically when Quick Suite invokes the Agent Core endpoint, verify that the CLIENT_ID, CLIENT_SECRET, AUTH_URL, and TOKEN_URL values entered during connector registration in Quick Suite (Step 6) are correct and match the outputs from the Cognito setup script (Step 1).

A mismatch in the callback URL — which must be set to https://<region>.quicksight.aws.amazon.com/sn/oauthcallback — is also a frequent cause of OAuth flow failures.

MCP Tools Not Appearing in Quick Suite Connector

If the tool list is empty or incomplete after registering the connector, the most likely cause is that the Agent Core Runtime endpoint is not reachable or is returning an error before the MCP handshake completes. Verify that the RUNTIME_ENDPOINT was correctly calculated following the URL-encoding procedure in Appendix B, and that the runtime is in a healthy running state (check the Agent Core console or CloudWatch logs for container startup errors). Also confirm that the MCP server process inside the container is listening on the expected port and path (/mcp) and that the container image was built and pushed to ECR successfully using agentcore launch.

Insufficient IAM Permissions

If tool invocations fail with errors such as "AccessDeniedException" or "User is not authorized to perform" at the AWS service level, the root cause is typically that the IAM role used by the Agent Core execution role is missing one or more required managed policies. Unlike Lake Formation permission errors — which occur after IAM access is granted — these errors are returned directly by the AWS service before any data-level access is attempted. To resolve this, navigate to the IAM console, locate the execution role associated with your Agent Core runtime, and verify that the following policies are attached:

AWSGlueServiceRole — required for Glue operations (listing databases, tables, crawlers, etc.)
AmazonAthenaFullAccess — required for Athena operations (running queries, managing workgroups)
A custom S3 policy — required for S3 operations (reading input data and writing Athena query results); at minimum, this policy should grant s3:GetObject , s3:PutObject , and s3:ListBucket on the relevant buckets and prefixes

After attaching the missing policies, allow a few seconds for the changes to propagate and then retry the tool invocation. If the error persists, use AWS CloudTrail to identify the exact API call that was denied and the specific resource ARN involved, which will help you scope any additional permissions that may be required.

AWS Lake Formation Permission Denied or unable to see certain databases/tables

If tool invocations against Glue or Athena succeed at the IAM level but return access denied errors on specific databases or tables, the root cause is typically a missing Lake Formation permission grant. AWS Lake Formation enforces a second layer of access control on top of IAM — even if the Agent Core execution role has the necessary IAM policies, it must also be explicitly granted permissions in Lake Formation to access the relevant databases, tables, and columns. To resolve this, navigate to the AWS Lake Formation console, go to Data permissions, and add a new grant for the IAM role used by the Agent Core runtime. Grant the appropriate permissions (e.g., SELECT on the target tables, DESCRIBE on the database) and ensure the role is also granted DESCRIBE on the Data Catalog itself. Once the Lake Formation grants are in place, retry the tool invocation.

Athena Query Output Location Not Configured

Athena requires a designated S3 location to write query results before they can be returned to the caller. If Athena queries fail with an error such as Query result location not set or No output location provided, there are two ways to resolve this. The recommended approach is to create a dedicated Athena workgroup (e.g., mcp-workgroup) with a pre-configured S3 output location (e.g., s3://<your-bucket>/athena-results/) — this ensures all queries submitted through that workgroup automatically use the defined location without requiring the caller to specify it each time.

Alternatively, if you prefer not to use a dedicated workgroup, you can instruct the agent to include the output location explicitly when invoking Athena queries by providing the S3 path as a parameter in the tool call. In either case, ensure that the Agent Core execution role has s3:PutObject and s3:GetObject permissions on the target S3 bucket and prefix, otherwise the query will fail even if the output location is correctly specified.

Quick Suite Agent Not Selecting the Correct MCP Tool

If the agent consistently selects the wrong tool or fails to invoke any tool at all, the issue is typically related to the tool descriptions registered in Quick Suite. The LLM powering the agent relies on the tool name and description to determine when and how to invoke it — if these are vague or ambiguous, tool selection will be unreliable. Review the connector registration in Quick Suite and ensure the connector name and description (entered in Step 6) are specific and informative. First-

Cost Management

Understanding the cost profile of this integration is important for budgeting and ongoing optimisation. The two primary cost drivers directly associated with this guide are Amazon Quick Suite and Amazon Agent Core Runtime; costs incurred by the underlying AWS data services invoked by the MCP server tools (such as AWS Glue, Amazon Athena, Amazon EMR, and Amazon S3) will vary significantly depending on usage patterns and are not included in the estimates below — refer to the respective AWS pricing pages for those services.

Amazon Quick Suite is priced on a per-user, per-month subscription basis, with costs varying depending on the license tier (Reader, Author, or Admin). The steps outlined in this guide should be performed by an enterprise user which has a monthly cost of $40/month. The configured integration can be leveraged by other users (including professional users) which are priced $20/month.

Amazon Agent Core Runtime charges are based on the compute resources consumed by the containerized MCP server while it is running and processing requests. Costs are typically measured in terms of vCPU-hours and memory-hours consumed by the runtime container, plus any data transfer costs associated with inbound and outbound HTTPS traffic to the Agent Core endpoint (applicable only if you perform cross-region traffic).

To track and attribute costs effectively, it is strongly recommended to attach cost allocation tags to all AWS resources created as part of this guide — including the Agent Core runtime, the Cognito User Pool, the ECR repository, and any associated S3 buckets. Once tags are applied and activated in the AWS Billing console, costs can be monitored and broken down by tag using AWS Cost Explorer , which provides visual cost trend analysis and filtering by service, tag, and time period. For more granular or automated cost reporting, AWS Cost and Usage Report (CUR) data exports can be configured to deliver detailed billing data to an S3 bucket, enabling custom analysis or integration with third-party FinOps tooling.

Conclusion

This article provides a comprehensive architectural pattern and step-by-step implementation guide for extending the native capabilities of Amazon Quick Suite by integrating custom action connectors built on the Model Context Protocol (MCP). Using the AWS Data Processing MCP Server — an open-source implementation maintained by AWS Labs — as a concrete reference, the guide walks through every stage of the integration lifecycle, from initial infrastructure setup to production validation.

The solution is built around four core components that work together to deliver a secure, scalable, and enterprise-ready integration: a containerized MCP server that encapsulates custom tool logic; Amazon Agent Core Runtime, which hosts the server as a managed HTTPS endpoint without requiring customers to provision or operate their own infrastructure; Amazon Cognito, which enforces OAuth 2.0-based user authentication to ensure that only authorized identities can invoke the MCP endpoint; and Amazon Quick Suite, which consumes the registered connector and makes its tools available to agents, flows, and automations through a natural language interface.

While this guide used the AWS Data Processing MCP Server as its reference implementation, the architecture pattern, deployment steps, and integration procedures described throughout are broadly applicable to any MCP-compliant server — including other AWS MCP servers, third-party implementations, or custom-built solutions developed in-house — making this a reusable foundation for extending Quick Suite's integration capabilities to virtually any system or service an organization requires.

Appendices

Appendix A: Calculate bearer token

Follow these steps if you need to calculate a bearer token (used for local testing only):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# Set your Cognito configuration
export REGION="us-east-1"  # Your AWS region
export POOL_ID="your-pool-id"
export CLIENT_ID="your-client-id"
export CLIENT_SECRET="your-client-secret"
export USERNAME="your-username"
export PASSWORD="your-password"

# Compute SECRET_HASH for authentication
SECRET_HASH=$(echo -n "${USERNAME}${CLIENT_ID}" | openssl dgst -sha256 -hmac "${CLIENT_SECRET}" -binary | base64)

# Get Bearer Token
export BEARER_TOKEN=$(aws cognito-idp initiate-auth \
  --client-id "$CLIENT_ID" \
  --auth-flow USER_PASSWORD_AUTH \
  --auth-parameters USERNAME=$USERNAME,PASSWORD=$PASSWORD,SECRET_HASH=$SECRET_HASH \
  --region $REGION | jq -r '.AuthenticationResult.AccessToken')

echo "Bearer Token: $BEARER_TOKEN"

Appendix B: Calculate Agent Core Runtime Endpoint

Follow this procedure to generate the endpoint for the Agent Core runtime based on its ARN (as endpoint is not available either on the console nor via de CLI)

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/bin/bash

AWS_REGION=<your_region>
AWS_ACCOUNT=<your_aws_account>

RUNTIME_ARN="arn:aws:bedrock-agentcore:${AWS_REGION}:${AWS_ACCOUNT}:runtime/<runtime_name>"

# URL-encode the ARN for the endpoint
ENCODED_ARN=$(echo -n "$RUNTIME_ARN" | jq -sRr '@uri')
# Result: arn%3Aaws%3Abedrock-agentcore%3A<your_region>%3A<your_account>%3Aruntime%2F<runtime_name>

# Construct the runtime endpoint
RUNTIME_ENDPOINT="https://bedrock-agentcore.${AWS_REGION}.amazonaws.com/runtimes/${ENCODED_ARN}/invocations?qualifier=DEFAULT"

Appendix C: Generate OAuth endpoints from discovery URL

Follow this procedure to generate the AUTH_URL and TOKEN_URL pointing to the authentication server and token server respectively.

1
2
3
4
5
6
7
8
9
#!/bin/bash

# Extract OAuth endpoints from the well-known configuration generated on Step 1
DISCOVERY_URL="https://cognito-idp.<your_region>.amazonaws.com/eu-<your_user_pool_id>/.well-known/openid-configuration"

OIDC_CONFIG=$(curl -s $DISCOVERY_URL)
AUTH_URL=$(echo $OIDC_CONFIG | jq -r '.authorization_endpoint')
TOKEN_URL=$(echo $OIDC_CONFIG | jq -r '.token_endpoint')
CALLBACK_URLS=$(echo $CLIENT_OUTPUT | jq -r '.UserPoolClient.CallbackURLs | join(", ")')

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Integrating AWS MCP Servers with Quick - Data Processing Example

Enrique_S

Introduction and purpose

Pre-requisites and assumptions

Knowledge Pre-requisites

Infrastructure and Access Pre-requisites

Assumptions

Foundational components

Amazon Quick Suite

Model Context Protocol (MCP)

Agent Core Platform

Architecture overview

Data Flow

Implementation Guide

Pre-requisites

Step-by-Step Implementation

Step 1: Setup Authentication

(optional) Step 2: Run MCP Server for local test

Step 5: Deploy to Agent Core

(optional) Step 7: Test Agent Core client

Step 6: Register with Quick Suite

Step 7: Test End-to-End

Option A: Validate via a Custom Agent Connected to the LakeHouse Space

Step 1 – Create a Custom Agent

Step 2 – Test the Agent End-to-End

Option B: Validate Directly from the Quick Chat Agent Window (LakeHouse Space in Focus)

Step 1 – Open the Quick Chat Agent Window

Step 2 – Select the LakeHouse Space

Step 3 – Invoke a Tool via Natural Language

Troubleshooting

Authentication & Authorization Failures (HTTP 401 / 403)

MCP Tools Not Appearing in Quick Suite Connector

Insufficient IAM Permissions

AWS Lake Formation Permission Denied or unable to see certain databases/tables

Athena Query Output Location Not Configured

Quick Suite Agent Not Selecting the Correct MCP Tool

Cost Management

Conclusion

Appendices

Appendix A: Calculate bearer token

Appendix B: Calculate Agent Core Runtime Endpoint

Appendix C: Generate OAuth endpoints from discovery URL