ThunderHawk Stat MCP

Cover Image for the Project

Inspiration

I work at Tucson Federal Credit Union. I deal with transactional databases with a time series component. We receive around 30000 to 50000 transactions per day. We use Snowflake for data warehouse and have been building AI solutions with it. There was a Medium Article written by Avni Jain on using Cortex to build a Statistical Agent because teams need to know if a lift in conversion is real or just noise, but answering that requires picking the right test and tedious context switching between SQL and Python, which creates tool friction and an expertise gap that makes a simple question take hours. The other friction I noticed was her article was specific to Snowflake. I wanted to create something that was data warehouse agnostic (i.e. you can use Snowflake, Databricks, PostgreSQL, etc)

What it does

ThunderHawk Stat MCP is a secure, read-only statistical analysis server that allows GPT-5.6 to inspect database data, select validated statistical tools, execute deterministic calculations, and explain structured results in natural language.

How we built it

I built a Python-based Model Context Protocol (MCP) server that gives LLMs deterministic statistical analysis capabilities. The server exposes tools like list_tables, profile_table, and run_test through the official MCP SDK. Instead of having the LLM perform statistical calculations itself, it delegates those computations to Python libraries such as pandas, SciPy, and statsmodels. The server currently uses a deterministic SQLite database for reproducible demos, is packaged as an installable Python application, secured with bearer authentication, tested with over 100 automated tests, and deployed publicly on Railway using Streamable HTTP.

Challenges we ran into

The biggest challenge was deployment. The MCP server worked locally and passed over 100 automated tests, but deploying it to Railway exposed packaging issues where the application wasn't being installed into the runtime environment correctly. I had to diagnose the difference between the build environment and the runtime environment, ultimately switching from Railpack to a Docker-based deployment so the application and its dependencies were installed and executed in the same image.

Accomplishments that we're proud of

Building my second MCP server and deploying it.

What we learned

Building an MCP server is much more than exposing a few tools—it requires designing a reliable orchestration between an LLM, deterministic Python code, and external data sources. One of the biggest lessons was recognizing where the LLM should stop and where deterministic software should take over. Instead of allowing the model to perform statistical calculations directly, we delegated those computations to validated Python libraries (pandas, SciPy, and statsmodels) through a structured MCP interface, allowing the LLM to focus on understanding user intent and explaining the results.

Throughout development, Codex served as an engineering partner by helping design the architecture, review implementations, and troubleshoot complex deployment challenges. The project was built iteratively through milestones: defining the MCP interface, implementing statistical tools, creating a database abstraction layer, writing over 100 automated tests, adding authentication, and deploying the server to Railway. Each milestone reinforced the importance of testing, reproducible builds, and incremental validation.