Provides tools for executing SQL queries against Amazon Athena, retrieving results in structured formats such as JSON, CSV, or tables. Supports authentication via AWS profiles and configuration of database, region, and output location.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AthenaMCPServer run SELECT * FROM orders LIMIT 10"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server for querying Amazon Athena. This server allows AI assistants to execute SQL queries against AWS Athena and retrieve results in a structured format.
Execute SQL queries against Amazon Athena
Authenticate to AWS account using profiles
Format results as JSON, CSV, or formatted tables
Configurable database, region, and output location
Related MCP server: NLSQL MCP Server
# Install dependencies
npm installThe server uses the following environment variables for configuration:
AWS_REGION: AWS region where Athena is located (default: "us-east-1")
ATHENA_WORKGROUP: Athena workgroup to use (default: "primary")
ATHENA_OUTPUT_LOCATION: S3 location for query results (default: "s3://aws-athena-query-results/")
ATHENA_DATABASE: Default database to query (default: "default")
ATHENA_CATALOG: Default catalog/data source to query (default: "AwsDataCatalog")
AWS_PROFILE: AWS Profile to use for authentication (default: undefined, and will fallback to using default AWS credentials provider chain)
You can set these environment variables before running the server:
export AWS_REGION=us-west-2
export ATHENA_WORKGROUP=my-workgroup
export ATHENA_OUTPUT_LOCATION=s3://my-bucket/athena-results/
export ATHENA_DATABASE=my_database
export ATHENA_CATALOG=AwsDataCatalog
export AWS_PROFILE=aws_profile_nameAlternatively, you can set these environment variables in the MCP Client configuration (see below).
{
"mcpServers": {
"athena-mcp": {
"command": "npm",
"args": [
"--prefix",
"/Users/<alias>/workplace/AthenaMCPServer/src/AthenaMCPServer",
"start"
],
"disabled": false,
"env": {
"AWS_PROFILE": "<aws-profile-for-account-with-athena>",
"ATHENA_OUTPUT_LOCATION": "s3://<your-athena-query-results-bucket>"
},
"autoApprove": []
}
}
}The server uses the AWS SDK's default credential provider chain. You can authenticate using any of the following methods:
Environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY)
Shared credentials file (~/.aws/credentials)
EC2 instance profile or ECS task role
AWS SSO
You can specify an AWS profile from your shared credentials config file (~/.aws/config) when executing queries:
{
"query": "SELECT * FROM my_table LIMIT 10",
"profile": "my-aws-profile"
}This is useful when you have multiple AWS accounts or roles configured in your credentials file.
For more information, see the AWS SDK documentation.
Type the following into the MCP Client Window
use the athena mcp server to run a basic query and return in csvResponse:
test
1You can pass it a query directly, or use other LLMs to generate the SQL for you and ask it to run it using the Athena MCP Server
# Start the server
npm startExecutes SQL queries against Amazon Athena and retrieves results.
Parameters:
query (required): SQL query to execute
database (optional): Database to query (uses default if not specified)
catalog (optional): Catalog (Data source) to query (uses AwsDataCatalog if not specified)
region (optional): AWS region (uses default if not specified)
format (optional): Result format (json, table, or csv)
profile (optional): AWS profile name to use from shared credentials file
Example:
{
"query": "SELECT * FROM my_table LIMIT 10",
"database": "my_database",
"catalog": "AwsDataCatalog",
"format": "table",
"profile": "my-aws-profile"
}athena-mcp/
├── src/
│ ├── core/
│ │ └── aws/
│ │ └── athena-client.ts
│ ├── tools/
│ │ └── query-athena/
│ │ └── tool.ts
│ ├── cli.ts
│ └── index.ts
├── package.json
├── tsconfig.json
└── README.md# Run in development mode with auto-reload
npm run watch# Run tests
npm testExecute SQL queries against Amazon Athena and retrieve results
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | SQL query to execute | |
| format | No | Result format (json, table, or csv) | |
| region | No | AWS region (optional, uses default if not specified) | |
| catalog | No | Catalog (Data source) to query (optional, uses AwsDataCatalog if not specified) | |
| profile | No | AWS profile name to use from shared credentials file (optional) | |
| database | No | Database to query (optional, uses default if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says queries are executed and results retrieved; it does not mention cost implications, async execution, credential/permission needs, or result-size limits. These are material behaviors for an Athena query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording. It front-loads the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotation, so the description should explain return behavior and operational caveats. It only says 'retrieve results,' leaving the agent without information about response format, synchronous vs. async execution, or potential error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all six parameters with 100% coverage, so the baseline is 3. The description adds no extra parameter-level meaning, but it doesn't need to because the schema provides adequate documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Execute SQL queries') and resource ('Amazon Athena'), and mentions the outcome 'retrieve results.' It is unambiguous even though it doesn't distinguish from siblings, because no siblings exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need to run SQL against Athena and get results. However, it doesn't provide explicit conditions, prerequisites, exclusions, or alternatives, and there are no sibling tools to contrast with.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0query_athenaWith only one tool, there is no possibility of overlap or confusion. The tool's purpose is clearly defined as executing SQL queries and retrieving results.
The name 'query_athena' follows a clear verb_noun pattern with snake_case. While there is only one tool, the name is consistent with common MCP naming conventions and unambiguous.
A single tool feels thin for a server dedicated to Athena, though the narrow purpose of querying makes it borderline acceptable. It falls short of the typical well-scoped 3-15 tool range.
The tool covers the core workflow of executing queries and retrieving results, but lacks explicit operations like query cancellation or schema listing. These can potentially be handled via SQL, representing minor gaps rather than fatal omissions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
An MCP server that integrates with Discord to provide AI-powered features.
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
The BigQuery remote MCP server is a fully managed service that uses the Model Context Protocol to connect AI applications and LLMs to BigQuery data sources. It provides secure, standardized tools for AI agents to list datasets and tables, retrieve schemas, generate and execute SQL queries through natural language, and analyze data—enabling direct access to enterprise analytics data without requiring manual SQL coding.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/markryanbotha/AthenaMCPServer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
