Guides

Examples

How an agent uses Server4Agent to write code, run functions, and ship full solutions. Every example is a sequence of tool calls the agent makes itself.

The pattern

Whatever the agent is building, a one-off function, a script, or a full app, it follows the same shape: get a server, describe (or write) the work, run it, and (optionally) deploy it to a public URL.

pattern

// The pattern every solution follows:
create_server  →  prompt / write_file(s)  →  exec  →  deploy
//   get a box       describe or author       run it      live URL

Just hand it a prompt

The fastest path: create_server, then prompt with a goal. The on-server agent decides what to write, install, run, and deploy.

agent → MCP tools

// The simplest path, hand the on-server agent a goal.
// It figures out what to write, install, run, and deploy.

create_server()
// → { "id": "srv_2k9", "url": "https://srv_2k9.apps.server4agent.com" }

prompt({
  server_id: "srv_2k9",
  prompt: "Build a Slack bot that posts our Stripe sales every morning at 9am UTC. Use webhooks, not polling. Deploy it."
})
// → { "run_id": "run_71a", "status": "running" }

// The on-server agent now:
//  • plans the project
//  • writes the bot + Stripe webhook handler
//  • installs deps
//  • schedules the cron
//  • deploys to a public URL
//  • returns when done

Write and run a function

The agent provisions a server, writes a file, and executes it. No human, no plan, just the agent and its API key.

agent → MCP tools

// Example 1, write and run a function
// Each line is an MCP tool call your agent makes.

create_server()
// → { "id": "srv_2k9", "url": "https://srv_2k9.apps.server4agent.com" }

write_file({
  server_id: "srv_2k9",
  path: "fib.py",
  content: "def fib(n):\n    a, b = 0, 1\n    for _ in range(n):\n        a, b = b, a + b\n    return a\n\nprint([fib(i) for i in range(10)])"
})
// → { "path": "fib.py", "written": true }

exec({ server_id: "srv_2k9", command: "python fib.py" })
// → { "stdout": "[0, 1, 1, 2, 3, 5, 8, 13, 21, 34]" }

Run a script

Same primitives, longer code. The durable workspace means files and installed dependencies persist between tasks.

agent → MCP tools

// Example 2, a standalone data script the agent writes and runs
write_file({
  server_id: "srv_2k9",
  path: "clean.py",
  content: "import csv, sys\n# dedupe + normalize a CSV, write cleaned.csv\n..."
})
exec({ server_id: "srv_2k9", command: "python clean.py data.csv" })
// → { "stdout": "wrote cleaned.csv (1,204 rows)" }

Build and deploy an app

For larger work, hand the server a goal with run_task and let the agent plan and build it, then deploy for a live URL.

agent → MCP tools

// Example 3, build and ship a full web app in one task
run_task({
  server_id: "srv_2k9",
  goal: "Build a Next.js landing page with a waitlist form and deploy it."
})
// → { "task_id": "tsk_71a", "status": "running" }

// ...the agent writes the files and runs the build on its server, then:
deploy({ server_id: "srv_2k9" })
// → { "url": "https://srv_2k9.apps.server4agent.com", "status": "live" }

Build something bigger

For a whole project, the agent calls start_build with a goal. The server runs an ordered pipeline, plan, scaffold, implement, install, build, deploy, and the agent polls get_build for step-by-step progress, a public URL, and the artifacts produced.

agent → MCP tools

// Build something bigger, a whole project in one session.
// start_build runs an ordered pipeline on the server; poll it with get_build.

start_build({ server_id: "srv_2k9", goal: "Build a SaaS dashboard with auth and deploy it." })
// → { "build_id": "bld_ep2mrm", "status": "queued" }

get_build({ server_id: "srv_2k9", build_id: "bld_ep2mrm" })
// → {
//     "status": "running",
//     "steps": [
//       { "key": "plan",      "label": "Plan the project",       "status": "done" },
//       { "key": "scaffold",  "label": "Scaffold files",          "status": "done" },
//       { "key": "implement", "label": "Write the code",          "status": "running" },
//       { "key": "install",   "label": "Install dependencies",    "status": "pending" },
//       { "key": "build",     "label": "Build & test",            "status": "pending" },
//       { "key": "deploy",    "label": "Deploy to a public URL",  "status": "pending" }
//     ]
//   }

// keep polling until status === "completed":
// → { "status": "completed",
//     "url": "https://srv_2k9.apps.server4agent.com",
//     "artifacts": ["app/page.tsx", "package.json", "README.md"] }

Prefer plain HTTP?

Every tool maps to a REST endpoint. Here's the same write → run → deploy flow with curl.

example.sh

# The same building blocks over plain HTTP (API-key auth, no plan field)
SRV=$(curl -s -X POST https://api.server4agent.com/servers \
  -H "Authorization: Bearer $AGENTSERVER_KEY" | jq -r .id)

curl -X PUT https://api.server4agent.com/servers/$SRV/files \
  -H "Authorization: Bearer $AGENTSERVER_KEY" \
  -d '{ "path": "app.py", "content": "print(\"hello from the agent\")" }'

curl -X POST https://api.server4agent.com/servers/$SRV/exec \
  -H "Authorization: Bearer $AGENTSERVER_KEY" \
  -d '{ "command": "python app.py" }'

curl -X POST https://api.server4agent.com/servers/$SRV/deployments \
  -H "Authorization: Bearer $AGENTSERVER_KEY"
# → { "url": "https://<srv>.apps.server4agent.com", "status": "live" }

Next: A full agent loop