In an era where vibe-coded apps seem to fall apart at the slightest nudge, we wanted to make life easier for anyone looking to build robust apps—without giving up on the promise of AI. That’s why we created the Tower MCP server.
You can start using it right away in the CLI and go from nothing to a fully functional app in minutes. There’s a walkthrough on how to do it below, and if you want more details, feel free to check out our documentation. Or, vibe yourself through it in Tower now.
Why create an MCP server in Tower?
Our motivation is simple: we want you to use all the tools out there with Tower. Creating code with AI is the latest and greatest the world has to offer, but it also comes with significant risks. We know from public incidents that vibe coding can be dangerous.. By creating an MCP server, we’re enabling you to vibe engineer, instead of vibe coding.
AIs famously hallucinate. What that means for developing a data engineering app in Tower in particular is:
Towerfile generation—LLMs very confidently assert that they can write your Towerfile for you, allowing you to deploy on Tower. They are wrong. Here, an MCP server can provide the guardrails to reliably generate it.
Tower secrets—without guidance, an LLM can screw you over by disregarding best practices, e.g. by committing your API keys directly in a public repo. With the MCP server, the LLM is able to follow our best practices and keep your secrets secret.
Enable wider functionality—with an MCP server we’re able to guide and to reveal many things that an LLM might not even know were possible.
Our CLI docs explain how to start and add an MCP server to your client... but it may not be super obvious how to use the Tower MCP server to enhance your productivity. Starting is very easy - but it's even easier when you have an example of how it's done.
So, I’ll walk you through the whole process in a single Claude code session—vibe engineering an app from scratch, just like you might do it at home.
Prerequisites for using the MCP server at home
Claude code (obviously, you can use whatever client you like, but the setup can differ)
The Tower CLI
A tower account
A computer with the ability to open a terminal
You can install the Tower CLI with pip:
pip install tower
Or you can run the Tower CLI without installing with uvx:
uvx tower --help
In this walkthrough, I'm using uvx.
1. MCP init
First things first, we need to start the MCP server and set up Claude to see it. We start the mcp-server with:
tower mcp-server --port 34567 &
This will run the MCP server in the background (n.b., it's important to keep the server running in a terminal window while using it, but it's not necessary to start it more than once, as the LLM can specify its own working directories).
Next, we add the MCP server to our Claude project configuration with:
claude mcp add tower "http://127.0.0.1/sse" --transport sse
Here's how that looks:
2. Getting started with the MCP server
To kick things off with an agentic coding tool like Claude, it helps to start with a clear, detailed prompt. My idea for this walkthrough: a weather forecast app that’ll tell me what to wear in the morning.
Bullet points work well for LLMs (pro tip: you can get newlines in the Claude code CLI by typing \ before hitting enter). I also like to keep the project scope small at first—complexity can always come later. For now, I just want the app to print the recommendation. If I want to use the Tower MCP server, I’ll make sure to say so. MCP servers do a great job of keeping LLMs from drifting off, even though they could just use an external tool instead.
Here’s our first classic AI mix-up: Claude suggests using hatchling. But for deploying to Tower, there’s no need for hatchling—all you need is a pyproject.toml and a Towerfile. Luckily, we already have the former!
3. Starting to vibe engineer
Now Claude will start generating some code. It's good at Python, so it can easily solve almost any problem you throw at it... But not necessarily in the best possible way.
One trick with agentic coding: if your gut tells you there’s way too much code, or it’s just too much to read in one go, don’t be afraid to ask for something simpler. You’ll end up with code that’s much easier to understand.
4. Starting to use the Tower MCP tools
To use Tower, we’ll need a Towerfile. If the MCP server isn’t running, Claude might make up some impressive-looking YAML that only sort of resembles a real Towerfile. But with the MCP server on, it’ll generate the right syntax straight from your pyproject.toml, and tweak it as needed.
Next, it tries to create a Tower app... and fails. Oops! I forgot to log in to Tower before starting the MCP server. No biggie - we can quit Claude, run tower login to log into your Tower account in a browser window, then continue the Claude conversation with claude --continue:
5. First MCP tools integration
Since I paused to check how the Tower workflow actually works, I’ll prompt Claude to pick up where it left off. The workflow MCP tool tells Claude how to use the other Tower MCP tools, and in what order. Sure, we could bake this into the MCP server’s docs, but that would hog your context window even when you’re not using the server. Instead, it’s better to let the model ask for details only when it needs them.
As usual, I keep asking it to simplify the code—makes it so much easier to review. Until you’ve really read and understood what was generated, the bus factor is zero, so always make your own life easier!
Now Claude is starting to get the hang of Tower! It's able to:
Deploy your app.
Run the app locally.
Run the app remotely.
When it can deploy and run things on its own, the power of agentic coding can come into play. Claude can make a change, run it, and use the result as feedback.
6. ETL phone home?
Tower apps are useful if they can get data from the outside world. Previously, it was mocking data, and now we can fetch it. I ask it to get its data from https://open-meteo.com/, an excellent free API for weather forecasts.
7. Parameters
A very useful feature of Tower is the ability to parameterize an app, providing different inputs for different runs. For example, this could mean you can run multiple ETL jobs on different schedules for different tasks.
Let's use this feature to change the location we're checking the weather at.
Parameters are passed into Tower apps directly as environment variables. However, Claude doesn't necessarily know that, and some gentle probing can point it in the right direction.
It's able to fetch these docs to work out how to use the tool. After looking it up, I see that they're passed in as env vars.
But now it doesn't know what those env vars look like - at the time of writing, we don't modify these environment variable names at all; they're exactly the same as the parameter names. However, Claude will try to work this out on its own:
And... It's actually successful! Yes, it hallucinated a bunch of ways to get Tower parameters, but the agentic workflow meant that in the end, it worked out on its own what they should look like.
So here's it actually using those parameters:
8. Verify verify verify
If you want to avoid LLM hallucinations, a healthy dose of skepticism goes a long way. When it generates code that fetches data from an API, always double-check that it actually works!
9. Crafting the app
Now it’s just a matter of getting the LLM to tweak the app until it fits your needs. For example, I’m not American, so Fahrenheit doesn’t mean much to me (and I definitely don’t know how many football fields per second that is). So, I asked Claude to Europeanize it all for me 😉
It then generated a list of longitudes and latitudes for a bunch of EU cities. Maybe they’re correct, but I’m not about to memorize all those numbers. Since spitting out exact coordinates isn’t really a language model’s strong suit, I wanted to double-check if they were real.
Turns out, when I asked Claude, we figured out we don’t even need those coordinates—we can just pass the city name to Open Meteo directly. 😅
10. Tower secrets
Using an open API is sort of cheating—most APIs require secret keys and authorization. Luckily, Tower supports that too!
Let's bring in Twilio notifications. I have an API key that Claude can read and use to create a Tower secret, which is accessible in our Python app via environment variables, similar to the parameters.
11. Scheduling and Automation
Now the most important part of it all - running it on a schedule! Now I can f
You’re ready to use the Tower MCP server!
And that’s it! We’ve gone from zero to a fully automated weather app that texts me every morning—all in a single Claude session, with the Tower MCP server doing the heavy lifting. The real magic here is that Claude can now deploy, test, and iterate on real infrastructure, turning your ideas into running applications without forcing you to jump between coding and ops work.
Stop vibe coding; start vibe engineering yourself into success—log in to Tower and test it out for free!
Want to learn more about what we’re developing and how it is all progressing? Join our Discord server and speak directly to the team.
Happy hacking!