What the agent can do & limits

The coding agent works through a broad tool set — the same shape as a coding agent in your editor (read files, edit files, navigate code, run commands), plus a set of tools specific to building, testing, inspecting and deploying a live app. Knowing what it can and can't do helps you ask for the right thing.

Files

Tool	What it does
write_file	Create or fully overwrite a file (content taken verbatim).
edit_file	Surgical find-and-replace in an existing file.
multi_edit	Several edits to one file, applied atomically — if one fails to match, none are applied.
read_file	Read a file with line numbers (supports offset + limit).
list_files	List the app's file tree, with optional glob filtering.
rename_file	Move or rename a file, preserving its content exactly.
delete_file	Remove a file.

Code navigation

The agent doesn't only grep text — it has a real language service for the app's JS/TS, so it can tell two same-named functions apart:

Tool	What it does
grep	Search the app source for a string or regex, returning file:line: content.
app_map	The live map of the app: every /api route and which frontend file calls it, the import graph, database tables and columns, KV keys, and DOM ids.
get_symbols	Outline one file's functions/classes/types with line numbers, without reading it.
get_workspace_symbols	Fuzzy search for a symbol name across every file (type-aware).
find_symbol	Fast text fallback — every line mentioning a name.
go_to_definition	Jump to where a symbol is actually declared, following imports.
find_references	Every real usage of a symbol — run before renaming or changing a signature.
get_hover	A symbol's inferred type, signature and docs.

Checking the build before it deploys

Tool	What it does
check_backend	Compiles server.js and its relative imports without deploying, and cross-checks frontend fetch() calls against real routes and queried DOM ids against real elements.
lint_frontend	The frontend-only half of the above — faster, since it skips bundling the backend.

Running & testing

Tool	What it does
bash	Run a shell command in a sandbox — navigation, linting, type-checking.
bash_output / kill_shell	Poll or stop a background shell started with bash (for a dev server or watcher).
run_js	Run a self-contained JS snippet in an isolated sandbox to verify pure logic fast, without deploying.
verify	Deploy the current files and smoke-test them in Cloudflare's runtime.
run_api_tests	Run real HTTP requests (create → read-back → update → delete) against every /api route.
run_ui_tests	A real browser clicks through the main screens and checks elements update.
run_test_script	Write custom JS (WebSocket, SSE, uploads, multi-step flows) to test what the other runners can't.

Inspecting the live app

Tool	What it does
http_get / http_post	Call a path of the deployed app and see its real status + body (plus this request's server logs).
query_db	Run a read-only SQL query against the live database.
db_write	Run a write SQL statement (seed data, a migration you forgot, a repair).
read_logs	See the app's recent server errors — including real user traffic.
render_screen	Screenshot a page in a real browser at phone / tablet / desktop widths.

Reaching the outside world

Tool	What it does
http_request	Call any external HTTPS API to learn a vendor's real contract before coding against it. Stored secrets are injected as placeholders, so the agent never sees the value.
web_fetch	Fetch a public page and return its static text (no JavaScript executed).
web_search	Look up current facts (e.g. a service's real API).

Images & media

Tool	What it does
generate_image	Generate an image for the app.
stock_photo	Fetch a free stock photo (no charge).
fetch_image	Pull a specific image from a URL so the agent can actually see it, re-hosted to permanent storage.
edit_image	Derive a new image from one or more reference images plus an instruction.

App management

Tool	What it does
list_secrets / request_secret	See which secrets are configured (names only) or ask the user for one.
set_app_meta	Set the app's info (name, icon, description, category, features).
set_app_preview	Set the app's preview/cover image.

GitHub & checkpoints

Tool	What it does
git_log / git_diff / git_status	Read commit history and see what the current files changed versus the last commit (requires a connected GitHub repo).
git_revert	Restore one or more files to their last committed version.
list_checkpoints / rewind_to_checkpoint	Snapshots of the whole file tree, taken before every mutation — rewind the entire build to an earlier point. Works with or without GitHub.

MCP & remote ops

Tool	What it does
mcp_list_tools / mcp_call	Discover and call tools on the owner's connected MCP server — so the agent can ground a build in real internal data (a real schema, real projects, internal docs). MCP is build-time only; the finished app doesn't use it.
run_remote	Run a shell command on the owner's own server, when explicitly asked — for ops on their infrastructure, never on Nexrall's. Requires stored server credentials.

Planning, memory & delegation

Tool	What it does
todo_write / todo_read	Plan multi-step work and track progress visibly.
dispatch_subagent	Delegate a focused read-only investigation to a separate agent in its own context window, keeping the main build's context clean.
memory_write / memory_read	Persist preferences and conventions across your apps.
use_skill	Load a skill playbook.

Connectors

Instead of hard-coding API keys, the agent can wire a connector — a pre-built integration whose credentials are stored as app secrets, never in source. Built-in connectors include Supabase, Firebase, Notion, Figma, Cloudinary, VNPay, PayOS, and MoMo; for anything else, the agent can research the service's real API and guide you through connecting it.

Limits and guardrails

These are the boundaries the agent works inside:

• Bare imports are not allowed in the backend — the Worker is a single self-contained script, so the agent uses relative imports of files it includes, and calls external APIs with fetch().
• Worker size budget — all static assets are inlined into one Worker script; the deploy enforces a compressed ceiling (by default ~9 MB), and the agent is warned as it approaches it. Large embedded data belongs in the database, KV, or R2, not inline in source.
• bash is sandboxed — no network access, destructive commands blocked, secret access blocked. Ordinary commands get a short timeout; heavy tooling (type-check, lint, build) gets a longer floor automatically.
• No open internet from test scripts — run_test_script runs against your app's own origin only.
• Test writes are non-destructive — http_post won't charge real money or send real bulk email while testing; a destructive db_write is not refused but comes back with an explicit warning.
• No silent success — the agent is expected to verify a change worked (tests, a build, a lint) before calling a turn done, and to flag flaky tests rather than claim a win on one green run.

Next steps

• How it works — the runtime behind these tools.
• Security & sandboxing — how isolation and secrets are enforced.
• Troubleshooting.