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

A4.7/5.0

Behavior5/5

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

Annotations already set destructiveHint=true, but the description goes far beyond: it details the atomic operations (creates User row, subscription, ServerToken, wipes previous installation, launches bootstrap), and explains the deployment lifecycle (IP-first, no domain/HTTPS yet, 8-14 min). It also discloses that Fractera does not store the root password. This provides rich behavioral context beyond annotations.

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?

The description is comprehensive yet well-structured: it front-loads the purpose, then prerequisites, then internal actions, then deployment timeline with limitations, then returned fields with usage notes, and ends with a critical constraint. Every sentence earns its place. It is slightly longer than minimal, but the length is justified by the complexity of the operation. It remains clear and scannable.

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?

For a tool with 8 parameters (6 required), no output schema, and complex behavior, the description covers everything: prerequisites, exact sequence of actions, deployment timeline and constraints, return values (session_id, server_token) with proper usage instructions ('do not poll'), error recovery via retry_deploy, and the once-per-conversation rule. No gaps are apparent given the complexity and available structured information.

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%, but the description adds significant meaning to several parameters: it explains the 'lang' parameter's purpose and temporary nature, and for 'terms_accepted', 'email_confirmed', 'components_selected' it gives detailed conditions under which to set them true, including what to verify with the user. The description also clarifies the default for 'login'. This adds value beyond the schema's own 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 opens with a clear verb+resource statement: 'Register a new Fractera user and start the deployment of their server in one atomic call.' It distinguishes itself from siblings like check_status, retry_deploy, etc., by being the only tool that combines registration and deployment. The scope and atomicity are explicitly stated.

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?

The description explicitly states prerequisites: 'Use this AFTER you have collected the user's email (entered twice for typo protection), server IP, and root password.' It also imposes a strong constraint: 'Call this AT MOST ONCE per conversation.' It references an alternative tool (retry_deploy) for recovery, and hints not to poll by telling the agent to use check_status for a single read. However, it does not explicitly enumerate all when-not-to-use scenarios, but the prerequisites and constraints serve that purpose well enough.

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

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources

Need Help?