Server4Agent

Start or restart a project's app

start_app

DestructiveIdempotent

Start a project's app and keep it running: the step that puts a project online after its files are written. Runs command in the project folder as a background process with PORT set to the project's routed port (the app must listen on PORT), records it so it comes back after a restart, and waits up to about 10 seconds for the port to answer. Calling it again with the same name restarts it, which is how you pick up changed code. Returns whether the app is answering, its log tail, and the URL. A project's URL serves only while its visibility is public, so set that with update_project when the app should be reachable. For static files, put them under public/ and serve that folder, e.g. "python3 -m http.server $PORT --bind 0.0.0.0 --directory public". Never serve the project folder itself, which holds the project's secrets in .server4agent/env.

Input Schema

Name	Required	Description
`name`	No	Optional, default "web": the app the URL serves. Give a second process (a worker, a queue consumer) its own name so starting it leaves the web app alone. Lowercase letters, digits, - and _.
`command`	Yes	What starts the app, run from the project folder, e.g. `node server.js` or `npm start`. It must stay in the foreground (no trailing &) and listen on $PORT.
`project_id`	Yes	The project's id, as returned by create_project or list_projects.

Output Schema

Name	Required	Description
`url`	No	Public URL. null while the project is private.
`name`	No	The app's name. web is the one the URL serves.
`notes`	No	Anything worth acting on, e.g. the project is private.
`access`	No	Who may open the URL once it is public.
`status`	Yes	running = answering (or not a server). starting = not answering yet.
`log_tail`	No	The end of the app's log.
`listening`	Yes	Whether something answered on the port.
`project_id`	Yes	The project.
`visibility`	No	The project's visibility.
`listen_port`	No	The port the app has to listen on.
`restart_command`	No	The line recorded so the app comes back after a restart.
`replaced_previous`	No	Whether a running copy was stopped and replaced.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the annotations: background process execution with PORT injected, persistence across restarts, a ~10 second port-readiness wait, what is returned (answering state, log tail, URL), and the visibility prerequisite for the URL to serve. It also carries a genuine safety warning that serving the project folder would expose .server4agent/env secrets, which directly explains the destructive/open-world profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads what the tool does and how it behaves, then moves to caveats and the security warning at the end. It is dense but long; the static-file example and URL-visibility note are justified, though the paragraph could be broken into shorter units for faster scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers prerequisites (files written, visibility public via update_project), execution semantics, timing expectations, and restart behavior; an output schema exists so the description need not detail return values beyond its one-line mention. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3, but the description adds semantics the schema does not: the name field controls restart identity and isolating a worker from the web app, and the command must run in the foreground without a trailing & and bind to the injected PORT. It repeats the 'web' default rather than adding to it, keeping it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Start a project's app') plus its lifecycle meaning ('the step that puts a project online after its files are written') and that re-invocation restarts. An agent can distinguish it from write_file, exec, and deploy without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear sequencing cues (use after files are written; call again with the same name to pick up changed code) and a concrete static-file recipe. It does not explicitly say when to prefer this over sibling alternatives like exec or deploy, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Server4Agent tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.