Fractera
Server Details
Zero-Ops deploy of a private AI workspace to your own VPS — from your AI chat. Free and open-source.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: checking status, providing project info, retrieving the subdomain, recommending a VPS, registering/deploying, and retrying failed deployments. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_status, get_project_info, register_and_deploy), making them predictable and easy to understand.
With 6 tools, the server is well-scoped for its purpose of deploying Fractera servers. Each tool serves a necessary role without redundancy, and the count is appropriate for the domain.
The tool surface covers the core deployment workflow: VPS recommendation, registration/deployment, status checking, subdomain retrieval, and retry on failure. Minor gaps exist for post-deployment actions like updates or uninstallation, but these are outside the stated scope.
Available Tools
6 toolscheck_statusCheck Deployment StatusARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session_id returned by register_and_deploy or retry_deploy. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond readOnlyHint annotation by disclosing deployment takes 8-14 minutes, return content (current step, completed steps, done/failed), and warning against polling. Adds valuable 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, well-structured sentences. Front-loaded with purpose, each sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description fully explains return values (current step, completed steps, status) and provides critical context (deployment time, not to poll). Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description does not add new parameter-specific details beyond what the schema provides. Adequate baseline per rubric for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool reads current installation progress on demand, with a specific verb ('read') and resource ('installation progress'). Differentiates from sibling tools like register_and_deploy by specifying when to call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call only when user asks about status, never on timer or in polling loop. Provides context about deployment duration and authoritative channels, clearly guiding usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_project_infoGet Project InformationARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the returned content. Defaults to "en". Use "ru" for Russian-speaking users. | |
| section | No | A section id from the list returned when called with no section. Omit to get the list (table of contents) first. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds important behavioral context: the token-economy two-step retrieval pattern, the lightweight list vs. full section content, and the language parameter usage. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is fairly dense but front-loaded with the purpose. Every sentence adds value, though the token-economy instruction could be slightly more concise. Still, it's well-structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately describes return values (lightweight list of section ids+titles, or a single section's content). It covers the language option and the two-step retrieval. Complete for an info tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but the description adds significant value by explaining the intended usage pattern: omit section for list, then use a specific section id. It also clarifies the lang parameter's intended audience.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a project reference/help desk for Fractera, specifying it answers any user question about Fractera. It distinguishes itself from sibling tools like check_status, deploy, etc., which are operational rather than informational.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use especially during a deploy, call with no arguments first to get table of contents, then with a section id. Clearly states to never fetch everything at once and to use lang:"ru" for Russian speakers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subdomainGet Workspace AddressARead-onlyInspect
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".
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session_id used during installation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, descriptive context added about no domain/HTTPS and return format, no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff, first sentence clearly states purpose, second provides necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter, no output schema, and annotations, description adequately covers return value, timing, and format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with schema coverage 100%, description adds no additional semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns the final entry address after installation, with specific format and phase context, distinguishing it from sibling tools like check_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to call (after check_status reports done) and provides context for phase-1 usage, but no explicit alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vps_recommendationGet VPS RecommendationARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context: the tool returns a single recommendation, and the user is expected to buy a VPS and return with IP+password. This explains the workflow beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. The first sentence states the core purpose, followed by a usage condition and a note on user action. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage condition, and user workflow (buy VPS, return with IP+password). It does not describe the output format, but given no output schema and a simple return value ('single recommended VPS provider'), the agent likely infers it. For a tool with no parameters and clear annotations, this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. Baseline for no parameters is 4. The description does not need to add parameter details, as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose clearly: 'Return a single recommended VPS provider for users who do not yet have a server.' The verb 'return' and specific resource 'recommended VPS provider' make the action unambiguous. This tool is distinct from siblings like 'check_status' or 'get_project_info', and the description reinforces its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit condition provided: 'Call this ONLY when the user explicitly says they have no server.' This directs the agent on when to use the tool. However, it does not explicitly mention alternative tools or when not to use it, though the context of siblings and the condition itself provide sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_and_deployDeploy Fractera WorkspaceADestructiveInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IPv4 address of the user's VPS, e.g. 185.10.20.30. | |
| 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. | |
| components | No | Optional — which AI tools to install (lets the user save money on a smaller server). OMIT this to install the full recommended set (5 coding agents + Memory + Brain). Pass a subset of ["claude-code","codex","gemini-cli","qwen-code","kimi-code","memory","brain"] to install only those. Pass an empty array [] for a plain server with NO AI at all (just database + sign-in). The server, database, storage, sign-in and Admin panel are always installed regardless. | |
| 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. Set this ONLY after you have actually asked the component question (Q5) — told the user the full set is the default and asked, in three short steps, whether to keep all five coding assistants, Memory, and Brain. Pass it together with `components` (omit `components` or pass the full array = everything, [] = none, a subset = those). Do not set it if you skipped Q5. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes all side effects: creates User/Subscription/ServerToken, wipes previous installation, launches bootstrap. Matches destructiveHint=true. Explains return values and polling restriction, exceeding annotation information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Packed with useful details, but slightly dense as a single paragraph. Could be broken into lists for clarity, but no redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully explains return values (session_id, server_token), timing (8-14 min), limitation (no domain), and usage constraints. No output schema, but description compensates completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: email typo protection, login defaults to root, components default behavior, and effect of empty array. Schema coverage is 100% but description enriches understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool registers a new user and deploys a server atomically. Differentiates from sibling tools like retry_deploy by mentioning the one-time nature and recovery use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this AFTER you have collected...' and 'Call this AT MOST ONCE per conversation.' Provides context on the deployment phase (IP-first) and what the user should not do (poll repeatedly).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
retry_deployRetry Failed DeploymentADestructiveInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | No | Optional — only pass if the user discovered the original IP was wrong (e.g. typo). Otherwise the stored IP is used. | |
| login | No | Optional — Linux user, defaults to root. | |
| password | No | Optional — only pass if the user discovered the original password was wrong. Otherwise the stored password is used. | |
| components | No | Optional — same meaning as in register_and_deploy. OMIT to reinstall the full recommended toolset. Pass a subset (or [] for none) only if the user wants to change which AI tools are installed on this retry. | |
| server_token | Yes | The unique server token the user received in the deploy-failure email, the active deploy UI, or the dashboard. Acts as the authorisation for this retry. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: 'Wipes the previous broken install' details the destructive action, and it clarifies the return value (session_id) and polling with check_status. Annotations already indicate destructiveHint=true, so the description complements well without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each serving a distinct purpose: action+method, effect, and usage guidance. No unnecessary words, front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions the return of a session_id and directs polling with check_status, which is adequate. It covers optional parameter behavior but could mention what happens on success/failure or rate limits. Still, it is sufficiently complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by explaining usage nuances: 'only pass if the user discovered the original IP was wrong' for ip/password, and 'OMIT to reinstall the full recommended toolset' for components. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retries a failed deployment using a server_token, wipes the previous broken install, and runs a fresh deploy. It distinguishes from the sibling 'register_and_deploy' by focusing on retry versus initial deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when the user reports a failed deploy or pastes a server_token,' providing clear usage context. It also advises on when to pass optional parameters (e.g., only if original IP/password was wrong), but does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!