Fractera

Deploy Fractera Workspace

register_and_deploy

Destructive

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.

Input Schema

TableJSON Schema

Name	Required	Description
`ip`	Yes	IPv4 address of the user's VPS, e.g. 185.10.20.30.
`lang`	No	Optional — the two-letter code of the language the user is talking to you in (e.g. "ru" if the conversation is in Russian). Their new app is built in English PLUS this language, and this language becomes its default; pass "en" or omit for an English-only app. Adding more languages later is a switch in the Admin panel, so this is not a permanent choice — it just means their site opens in their own language from the first minute.
`email`	Yes	The email the user typed (and confirmed by re-typing). Welcome / failure emails go here.
`login`	No	Optional — defaults to "root". Override only if the VPS provider gave a non-root username.
`password`	Yes	Root password for the VPS.
`terms_accepted`	Yes	REQUIRED, must be true. Set this ONLY after the user has explicitly confirmed in the chat that they (1) have read and agree to Fractera's Terms of Service (https://www.fractera.ai/en/terms) and Privacy Policy (https://www.fractera.ai/en/privacy), and (2) understand they MUST change their server root password immediately after installation — Fractera never stores it and has no way to access the server afterwards. If the user has not given this explicit agreement, do NOT call this tool: ask for it first (and offer to explain the documents right in the chat).
`email_confirmed`	Yes	REQUIRED, must be true. Set this ONLY after the user has typed their email a SECOND time (Q2) and the two entries match (case-insensitive, trimmed). Do not set it if you only asked once.
`components_selected`	Yes	REQUIRED, must be true. Nothing is selectable any more — every server gets the same set — so this only records that you TOLD the user what gets installed (Q5): the app, the database and file storage with vector memory, sign-in, and the control panel.

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare destructiveHint true, but the description adds rich context: it wipes previous installations, creates multiple resources (User, Subscription, ServerToken), specifies deployment time (8-14 minutes), and explains IP-first behavior without domain/HTTPS. No contradiction with annotations.

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

Conciseness5/5

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

The description is front-loaded with the core action, then provides step-by-step context, and ends with invocation constraints. Every sentence adds value—no filler.

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?

Despite lacking an output schema, the description fully explains return values (session_id, server_token) and their usage. The deployment flow is complete, including time estimates and follow-up actions.

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

Parameters5/5

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

Schema description coverage is 100%, and the description adds meaning by explaining the workflow behind each parameter (e.g., email_confirmed requires double-entry verification, terms_accepted requires explicit user consent in chat). This goes well beyond the schema's basic field descriptions.

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?

The description clearly states the tool registers a Fractera user and deploys a server in one atomic call. It distinguishes itself from siblings like check_status and retry_deploy by specifying this is the initial deploy call.

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

Usage Guidelines5/5

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

Explicitly says 'Use this AFTER you have collected the user's email...' and 'Call this AT MOST ONCE per conversation', providing clear when-to-call and when-not-to-call guidance.

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

All Fractera tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool serves a distinct, non-overlapping purpose: status checking, project info, subdomain retrieval, VPS recommendation, deployment registration, and retry. No two tools could be confused for the same task.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_status, get_project_info, register_and_deploy). The naming is predictable and clear.

Tool Count5/5

Six tools is appropriate for the server's scope—deploying and managing a single Fractera server. Each tool is essential and covers the core workflow without unnecessary bloat.

Completeness4/5

The tool set covers the main deployment lifecycle: recommendation, deploy, status check, subdomain retrieval, and retry. Minor gaps exist (e.g., no tool to update deployment configuration or list historical deployments), but the core user journey is complete.

Resources

Need Help?