Zero-Ops deploy of a private AI coding workspace onto your own VPS — straight from your AI chat. Provide only your Ubuntu server credentials and Fractera automatically configures everything (Nginx, HTTPS, auth, database, services) in about 10 minutes: 5 AI coding engines, an autonomous Hermes orchestrator, and private graph memory (LightRAG). No terminal, no DevOps. IP-first and free; a custom domain with HTTPS is an optional later step.
Scored across 6 tools
Most tools have clearly distinct purposes: deployment, status, project info, etc. Minor potential confusion between `check_status` and `get_subdomain` since both return status-related information, but their descriptions differentiate them adequately.
Tool names follow a consistent verb_noun pattern (e.g., `check_status`, `get_subdomain`, `register_and_deploy`). The `get_vps_recommendation` name is slightly different but still clear. Overall, the naming is predictable and readable.
With exactly 6 tools, the server is well-scoped for deployment management. Each tool fills a necessary role without redundancy, making the set appropriate for the complex task of deploying and managing Fractera installations.
The toolset covers the full deployment lifecycle: registration, deployment, status checking, error recovery, and project information. Minor gaps exist, such as no tool for custom domain setup or user profile management, but the core workflow is complete.
Read the current installation progress ONCE, on demand. Call this only when the user explicitly asks how the deploy is going (e.g. "what is the status", "did it finish") — never on a timer and never in a polling loop. The deploy takes 8-14 minutes and the authoritative status channels are the email pipeline + the dashboard; one read on request is enough. Returns the current step, the list of completed steps (~44 total in a full bootstrap), and whether installation is done or failed.
Inputs: session_id (required).
Project reference / help desk about Fractera. Use this to answer ANY user question about what Fractera is, how it works, its architecture, components, modes, data ownership, pricing, use cases, partner program, etc. — especially while a deploy is running and the user wants to learn more. TOKEN-ECONOMY: call with NO arguments first to get the lightweight list of section ids+titles, then call again with a single section id to fetch just that section. NEVER try to fetch everything at once; pull only the section(s) relevant to the user question. Set lang:"ru" for Russian-speaking users.
Inputs: lang, section.
Return the final entry address of the server once installation is complete. In phase-1 (IP-first) this is a plain-HTTP Admin URL of the form http://:3002 — the server has NO domain and NO HTTPS cert yet (attaching a custom domain with HTTPS is an optional later step the user does inside Admin -> Personal Domain). Call this once after check_status reports status="done".
Inputs: session_id (required).
Return a single recommended VPS provider for users who do not yet have a server. Call this ONLY when the user explicitly says they have no server. The user buys the VPS at this provider and comes back with IP + password.
Inputs: no named parameters.
Register a new Fractera user and start the deployment of their server in one atomic call. Use this AFTER you have collected the user's email (entered twice for typo protection), server IP, and root password. Creates the User row (or reuses an existing one with the same email), creates a free Subscription, creates a ServerToken, wipes any previous installation on the target server, and launches bootstrap. The deploy is IP-first (phase-1): the server comes up on plain HTTP at http://:3002 in 8-14 minutes; it does NOT get a domain or HTTPS cert here (that is an optional later step inside the workspace). Returns session_id (for a single on-demand check_status read — do not poll) and server_token (so the user can recover via retry_deploy if anything breaks). Call this AT MOST ONCE per conversation.
Inputs: ip (required), email (required), password (required), terms_accepted (required), +4 more.
Retry a failed deployment using a server_token (from the failure email, the deploy-progress UI, or the dashboard). Wipes the previous broken install and runs a fresh deploy on the SAME server. Returns a new session_id — poll with check_status. Use this when the user reports a failed deploy or pastes a server_token.
Inputs: server_token (required), ip, login, password.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Add one secure layer between your agents and this server.