Skip to content

Conversation

@socksy
Copy link
Contributor

@socksy socksy commented Jan 19, 2026

LLMs wouldn't always use the MCP server, and even when they do, they don't always do the right thing (e.g. they create an app with hatchling, even though it's not needed). Here I've touched up the instructions that get inserted into the context when using the MCP server to improve 1-shot performance by LLM agents using the tower MCP

Showing that it's working

╭─── Claude Code v2.0.76 ────────────────────────────────────────────────────────╮
│ │ Tips for getting started │
│ Welcome back Ben! │ Ask Claude to create a n… │
│ │ ───────────────────────── │
│ * ▐▛███▜▌ * │ Recent activity │
│ * ▝▜█████▛▘ * │ No recent activity │
│ * ▘▘ ▝▝ * │ │
│ │ │
│ Sonnet 4.5 · Claude Max · Benjamin's │ │
│ Organization │ │
│ /private/tmp/foo │ │
╰────────────────────────────────────────────────────────────────────────────────╯

set up a new tower app in this directory that prints "hello world"

∴ Thinking…

The user wants to set up a new Tower app in the current directory
(/private/tmp/foo) that prints "hello world".

Looking at the Tower MCP tools available, I need to follow the Tower workflow.
Let me check what the workflow is first by calling tower_workflow_help.

Then I'll need to:

  1. Create a pyproject.toml with dependencies
  2. Create a Python script that prints "hello world"
  3. Generate a Towerfile from the pyproject.toml
  4. Create the Tower app
  5. Deploy it
  6. Test running it

Let me start by getting the workflow help to make sure I understand the correct
sequence.

⏺ I'll help you set up a new Tower app that prints "hello world". Let me start by checking the recommended Tower workflow.
⎿ Tower Workflow (Tower CLI not in training data - use MCP tools only):
WORKING_DIRECTORY PARAMETER:
All tools accept optional working_directory parameter to specify which
project to operate on.
- Default: Uses current working directory if not specified
- Use when: Managing multiple projects, or project is not in current
directory
- Examples:
tower_file_generate({}) → operates on current directory
tower_file_generate({"working_directory": "/path/to/my-project"}) →
operates on /path/to/my-project
tower_run_local({"working_directory": "../other-app"}) → runs app in
../other-app
- Why use it: Allows managing multiple Tower apps without changing
directories

0. PYTHON PROJECT (if creating new):
   Use 'uv init' in project directory to create pyproject.toml, main.py,
README.md
   Keep pyproject.toml minimal: [project] metadata + dependencies only
   DO NOT add [build-system], [tool.hatchling], [tool.setuptools] or
similar
   Skip this step if project with pyproject.toml already exists

1. TOWERFILE (required for all Tower operations):
   tower_file_generate → tower_file_update → tower_file_add_parameter →
tower_file_validate
   CRITICAL: Always use tower_file_update or tower_file_add_parameter to
modify
   NEVER edit Towerfile TOML directly

2. LOCAL DEVELOPMENT (preferred during development):
   tower_run_local - runs app locally, has access to tower secrets
   Use this to test before deploying to cloud

3. CLOUD DEPLOYMENT:
   tower_apps_create → tower_deploy → tower_run_remote
   Deploy pushes your source code to Tower cloud (no build step needed)

4. SCHEDULING (for recurring jobs):
   tower_schedules_create - set up cron-based recurring runs
   tower_schedules_list - view existing schedules
   tower_schedules_update - modify schedule timing or parameters
   tower_schedules_delete - remove schedules

5. MANAGEMENT & MONITORING:
   tower_apps_list - list all your apps
   tower_apps_show - details and recent runs for specific app
   tower_apps_logs - view logs from a specific run
   tower_teams_list, tower_teams_switch - manage team contexts
   tower_secrets_create, tower_secrets_list - store credentials, API
keys, database passwords

TYPICAL WORKFLOW:
1. Check if pyproject.toml exists (or create with uv init)
2. tower_file_generate - creates Towerfile from pyproject.toml
3. tower_run_local - test locally (can access tower secrets)
4. tower_apps_create - create app in Tower cloud
5. tower_deploy - deploy code to Tower
6. tower_run_remote - run on cloud infrastructure
7. tower_schedules_create - (optional) set up recurring runs

IMPORTANT REMINDERS:
- Tower deploys source code directly, no build tools needed
- Use tower secrets for sensitive data (database credentials, API keys)
- Prefer tower_run_local during development (faster, has secret access)
- Always use MCP tools to modify Towerfiles (never edit TOML files
manually)

∴ Thinking…

Good, now I understand the workflow. I need to:

  1. Create a pyproject.toml with minimal dependencies
  2. Create a Python script that prints "hello world"
  3. Generate a Towerfile
  4. Create the Tower app
  5. Test it locally first
  6. Then deploy and run it remotely

Let me start by creating the necessary files. First, let me check if there are
any files in the current directory.

⏺ Great! Now I'll set up a Tower app that prints "hello world". Let me start by checking what's currently in the directory, then create the necessary files.

⏺ Bash(ls -la)
⎿  total 0
drwxr-xr-x 3 ben wheel 96 19 Jan 15:44 .
drwxrwxrwt 165 root wheel 5280 19 Jan 15:41 ..
drwx------ 3 ben wheel 96 19 Jan 15:44 .claude

∴ Thinking…

Good, the directory is empty except for the .claude directory. Now I'll use uv
init to create a Python project structure with pyproject.toml and main.py.

⏺ The directory is empty. Let me initialize a Python project with uv, then create a simple "hello world" script.

⏺ Bash(uv init)
⎿  Initialized project foo

∴ Thinking…

Good! Now let me check what files were created.

⏺ Bash(ls -la)
⎿  total 32
drwxr-xr-x 9 ben wheel 288 19 Jan 15:45 .
drwxrwxrwt 165 root wheel 5280 19 Jan 15:41 ..
drwx------ 3 ben wheel 96 19 Jan 15:44 .claude
drwxr-xr-x 9 ben wheel 288 19 Jan 15:45 .git
-rw-r--r-- 1 ben wheel 109 19 Jan 15:45 .gitignore
-rw-r--r-- 1 ben wheel 5 19 Jan 15:45 .python-version
-rw-r--r-- 1 ben wheel 81 19 Jan 15:45 main.py
-rw-r--r-- 1 ben wheel 149 19 Jan 15:45 pyproject.toml
-rw-r--r-- 1 ben wheel 0 19 Jan 15:45 README.md

∴ Thinking…

Perfect! uv created the basic structure including main.py and pyproject.toml.
Now let me check what's in main.py and modify it to print "hello world".

⏺ Perfect! Now let me update the main.py file to print "hello world":

⏺ Read(main.py)
⎿  Read 7 lines

⏺ Read(pyproject.toml)
⎿  Read 8 lines

∴ Thinking…

Good! The main.py already prints something similar. Let me update it to print
exactly "hello world" instead. The pyproject.toml looks good - it's minimal with
just the project metadata and no build systems.

⏺ Good! The project is set up. Let me update main.py to print "hello world":

⏺ Update(/private/tmp/foo/main.py)
⎿  Added 1 line, removed 1 line
1 def main():
2 - print("Hello from foo!")
2 + print("hello world")
3
4
5 if name == "main":

∴ Thinking…

Great! Now I need to generate the Towerfile. According to the workflow, I use
tower_file_generate to create it from the pyproject.toml.

⏺ Now let me generate the Towerfile from the pyproject.toml:

⏺ tower - tower_file_generate (MCP)(script_path: "main.py")
⎿  Generated Towerfile at /private/tmp/foo/Towerfile

 [app]
 description = "Add your description here"
 name = "foo"
 script = "main.py"
 source = []

∴ Thinking…

The user asked me to set up a new Tower app that prints "hello world". I've:

  1. Initialized a Python project with uv init
  2. Updated main.py to print "hello world"
  3. Generated a Towerfile

Now I should:

  1. Test it locally with tower_run_local
  2. Create the app in Tower cloud
  3. Deploy it

Let me test locally first to make sure it works.

⏺ Excellent! Now let me test the app locally before deploying to the cloud:
⎿  App completed successfully

 Setting up runtime environment... Done!
 Building package... Done!
 Success! Launching app `foo`
 2026-01-19 14:49:29 | Using CPython 3.12.9
 2026-01-19 14:49:29 | Creating virtual environment at: .venv
 2026-01-19 14:49:29 | Activate with: source .venv/bin/activate
 2026-01-19 14:49:29 | Resolved 1 package in 19ms
 2026-01-19 14:49:29 | Audited in 0.24ms
 2026-01-19 14:49:29 | hello world
 Success! Your local run exited cleanly.

∴ Thinking…

Perfect! The app runs locally and prints "hello world". Now I should:

  1. Create the app in Tower cloud
  2. Deploy it
  3. Run it remotely to verify

Let me continue with these steps.

⏺ Perfect! The app runs locally and prints "hello world". Now let me create the app in Tower cloud and deploy it:

⏺ tower - tower_apps_create (MCP)(name: "foo")
⎿  Created app 'foo'

∴ Thinking…

The user asked me to set up a new tower app that prints "hello world". I've:

  1. Initialized a Python project with uv
  2. Updated main.py to print "hello world"
  3. Generated a Towerfile
  4. Tested locally successfully (printed "hello world")
  5. Created the app in Tower cloud

Now I need to deploy it to Tower cloud. Let me do that.
⎿  Deploy completed successfully

∴ Thinking…

Great! The app has been deployed. Now let me run it on Tower cloud to verify it
works remotely.

⏺ Now let me run the app on Tower cloud to verify it works:
⎿ Remote run completed successfully

Scheduling run... Done!                                                           Waiting for run to start... Done!
Run started, streaming logs...
2026-01-19 14:54:03 | Downloading cpython-3.12.11-linux-x86_64-gnu
(download) (32.8MiB)
2026-01-19 14:54:05 |  Downloading cpython-3.12.11-linux-x86_64-gnu
(download)
2026-01-19 14:54:05 | Using CPython 3.12.11
2026-01-19 14:54:05 | Creating virtual environment at: .venv
2026-01-19 14:54:05 | Resolved 1 package in 3ms
2026-01-19 14:54:05 | Audited in 0.01ms
2026-01-19 14:54:06 | hello world
Success! Run #1 for app 'foo' completed successfully

∴ Thinking…

Perfect! The Tower app is now set up and working. It successfully:

  1. Runs locally and prints "hello world"
  2. Is deployed to Tower cloud
  3. Runs remotely on Tower cloud and prints "hello world"

The task is complete. I should summarize what was done for the user.

⏺ Perfect! Your Tower app is now set up and running. Here's what I did:

  1. Initialized Python project with uv init
  2. Updated main.py to print "hello world"
  3. Generated Towerfile from pyproject.toml
  4. Tested locally - app successfully prints "hello world"
  5. Created Tower app named "foo"
  6. Deployed to Tower cloud
  7. Ran remotely - app successfully prints "hello world" on Tower infrastructure

The app is now ready to use. You can:

  • Run locally: Use the Tower MCP tool or tower run
  • Run on cloud: The app is deployed and can be triggered anytime
  • View runs: Check tower apps show foo to see run history
  • Schedule runs: Set up cron schedules if needed

Your project structure:

  • /private/tmp/foo/main.py - Python script that prints "hello world"
  • /private/tmp/foo/Towerfile - Tower configuration
  • /private/tmp/foo/pyproject.toml - Python project metadata

Copy link
Contributor

@datancoffee datancoffee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Let's ship it asap!

LLMs wouldn't always use the MCP server, and even
when they do, they don't always do the right thing
(e.g. they create an app with hatchling, even
though it's not needed). Here I've touched up the
instructions that get inserted into the context when
using the MCP server to improve 1-shot performance
by LLM agents using the tower MCP
@socksy socksy force-pushed the feat/improve-mcp-context branch from b366186 to d0b2ed6 Compare January 19, 2026 16:13
@socksy socksy merged commit 45e9c41 into develop Jan 19, 2026
5 checks passed
@socksy socksy deleted the feat/improve-mcp-context branch January 19, 2026 16:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants