Summary
A slow query stops being a dead end: you get an ID instead of a timeout.
The timeout is a parameter rather than a wall — run_query hands back rows when it can and a queryExecutionId when it cannot, and get_status and get_result pick it up from there, so an agent can start something expensive and come back to it. maxRows caps what lands in the conversation. The set is read-side: nothing here creates a table or saves a query, and results still land in the S3 path you configured.
What it is
A server over AWS Athena with 5 tools: run a query, poll it, read its result, and reach saved queries by ID.
What you get
- run_query against a named database with a timeoutMs and a maxRows cap, returning full results when the query finishes in time and a queryExecutionId when it does not
- get_status and get_result against that ID, with get_result returning an error while the query is still running rather than a partial answer
- list_saved_queries for the named queries already in the account, and run_saved_query by namedQueryId with an optional databaseOverride
Requirements
OUTPUT_S3_PATH for the S3 location Athena writes results to, and an AWS account with an Athena database the caller can query. MIT licensed.
Setup effort
One command plus a key — npx -y @lishenxydlgzs/aws-athena-mcp, then supply credentials