Interfaces

MCP server

Server4Agent speaks the Model Context Protocol. Add it to your agent framework and the agent can provision and drive servers as native tools, no glue code.

Connect

Endpoint. The MCP server is served at https://mcp.server4agent.com. Point your MCP client there and pass the agent's API key.

Point your framework's MCP client at our server and pass the agent's API key. Any MCP-capable runtime works.

mcp.config.json

{
  "mcpServers": {
    "server4agent": {
      "url": "https://mcp.server4agent.com",
      "headers": { "Authorization": "Bearer $SERVER4AGENT_API_KEY" }
    }
  }
}

Connecting a specific app? The Integrations page has copy-paste setup for each popular MCP client, plus a raw-JSON block for any other MCP-compatible host.

Tools

Once connected, the agent can call any of these tools. The headline is prompt, a freeform instruction the on-server agent plans and executes. The rest are the primitives it (or you) can reach for directly.

tools

// ── Server lifecycle ─────────────────────────────────────────
create_server      // → { id, url }                provision a new server
update_server      // { server_id, task?, region? }
delete_server      // { server_id }
control_server     // { server_id, action: start|stop|restart }
list_servers       // → [ { id, task, status, url } ]
get_server         // { server_id }                status, usage, URL
get_usage          // → spend, budget, blocked?     account AI spend + budget

// ── Projects (workspaces inside a server) ────────────────────
list_templates     // → [ { id, label, description, defaults } ]
list_projects      // { server_id? }
get_project        // { project_id }
create_project     // { server_id, name?, description?, visibility?,
                   //   lifecycle?, template? }     → project, url-or-null
update_project     // { project_id, name?, description?,
                   //   visibility?, lifecycle? }
delete_project     // { project_id }
cleanup_project    // { project_id }                ephemeral projects only

// ── The "do anything" tool ───────────────────────────────────
prompt             // { server_id, prompt }        agent plans + executes
                   // → { run_id, status }

// ── Low-level primitives ─────────────────────────────────────
exec               // { server_id, command }       run a shell command
read_file          // { server_id, path }          → { content }
write_file         // { server_id, path, content }
delete_file        // { server_id, path }
list_files         // { server_id }                → { files: [...] }

// ── Structured project builds ────────────────────────────────
start_build        // { server_id, goal }          → { build_id, status }
get_build          // { server_id, build_id }      poll steps + artifacts

// ── Deploy ───────────────────────────────────────────────────
deploy             // { server_id }                → { url, status: "live" }

Optional starters

Project starters are an optional catalog the agent can browse. Each one pre-fills sensible defaults for a use case (name, description, visibility, lifecycle), so the agent skips a round of decision-making when the work is recognisable: a webhook-to-Slack lead alert, an uptime monitor, a landing page with waitlist capture, a price/job watcher, or a CSV cleanup portal. The agent calls list_templates to discover them, then passes the id as the template argument to create_project.

templates

// 1. Discover the catalog.
list_templates → [
  { id: "invoice-and-quote-maker",
    label: "Invoice & quote maker",
    description: "Generate numbered invoices and quotes as PDFs",
    defaults: { name: "Invoice & quote maker",
                description: "Enter a client and line items …",
                visibility: "private",
                lifecycle: "persistent" } },
  { id: "url-uptime-monitor",     … },  // public
  { id: "csv-cleanup-portal",     … },
  { id: "telescope-deal-watcher", … },  // public
  …
]

// 2. Use one. Any explicit field overrides the template default.
create_project {
  server_id: "srv_2k9",
  template:  "invoice-and-quote-maker"
}
// → { id, name: "Invoice & quote maker",
//     visibility: "private", lifecycle: "persistent",
//     template: "invoice-and-quote-maker", url: null }

// 3. Or start from blank with no template.
create_project { server_id: "srv_2k9", name: "Custom thing" }

Any explicit argument overrides the template's default. Pass visibility: "public" to expose a private-by-default template, or override the name. Unknown template ids return a structured error pointing back at list_templates.

Why MCP-first

Agents are the users. Exposing Server4Agent as MCP tools means the agent decides when it needs a server and gets one itself, mid-task, without a human or a separate integration step.

Runnable examples

A zero-dependency script that speaks raw JSON-RPC to this endpoint (initialize, list tools, create a server and a project) lives in the examples directory on GitHub, next to a REST quickstart and three template walkthroughs.

Next: REST API

Connect an agent

Create a key, paste the MCP config, and give your agent a persistent server it can build on.

MCP setup