Fractera
Server Details
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.
- 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.8/5 across 6 of 6 tools scored.
Each tool serves a distinct purpose: status, info, address, VPS recommendation, deploy, retry. No ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_status, get_subdomain).
6 tools cover the deployment workflow without being too few or too many, fitting the domain perfectly.
The tool set covers the full lifecycle: prerequisites (VPS), start deploy, monitor status, retrieve final address, and retry on failure. No obvious gaps.
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?
Description adds value beyond annotations by detailing return values (current step, completed steps, done/failed) and noting the deployment takes 8-14 minutes. No contradiction with readOnlyHint=true.
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?
Single paragraph with purpose first, then usage constraints, then return details. Every sentence is essential and well-structured.
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?
For a simple read tool with one parameter, the description fully covers purpose, usage, and return values. No output schema needed as description provides sufficient information.
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% with a clear description of session_id. Description adds helpful context that session_id comes from register_and_deploy or retry_deploy, which aids agent 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?
The description clearly states the tool reads installation progress on demand, with a specific verb ('Read') and resource ('current installation progress'). It distinguishes from siblings like register_and_deploy by emphasizing it's a status read, not a deployment action.
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 states when to call: only on explicit user request, never on a timer or polling loop. Also directs to authoritative channels (email pipeline, dashboard), providing clear context and alternatives.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: the recommended two-step calling pattern and the warning against fetching everything at once, which are not conveyed by annotations alone.
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 but packed with actionable information. It front-loads the purpose, then covers scope and token-economy in a well-structured manner. Every sentence serves a clear function with no 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?
Despite lacking an output schema, the description adequately explains the return format: a lightweight list of section ids+titles when no argument is given, or a single section when provided. Combined with annotations, this makes the tool behavior fully understandable.
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% with descriptions for both parameters. The description enhances this by explaining that section is a section id from the initial list and suggesting lang='ru' for Russian users, adding practical usage guidance beyond the 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?
The description explicitly states the tool is for answering questions about Fractera, covering a wide range of topics. It uses a specific verb ('get') and resource ('project info'), and clearly distinguishes itself from sibling tools like check_status by focusing on informational queries.
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 on when to use (any user question about Fractera, especially during a deploy) and a detailed token-economy strategy: call with no arguments first, then with a specific section. Also advises on lang parameter for Russian users, though it doesn't list alternative tools for when not to use.
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 a read-only, non-destructive operation. Description adds value by detailing the returned URL format (http://<IP>:3002), absence of domain/HTTPS, and later custom domain option. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is efficient, front-loaded with purpose, and every sentence adds value. No extraneous content.
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 a simple tool with one parameter, clear annotations, and no output schema, the description covers all necessary aspects: return format, call timing, and server state context.
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% with a good description for session_id. The tool description does not provide additional parameter information beyond the schema, so baseline of 3 is appropriate.
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 returns the final entry address after installation, specifying the resource and condition. It distinguishes from siblings by explaining the IP-first phase and custom domain step.
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 states when to use: 'Call this once after check_status reports status="done".' It ties usage to a specific sibling condition, providing clear context and excluding premature use.
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 already declare readOnlyHint=true and destructiveHint=false, so the description adds complementary context: it explains that the tool returns a recommendation and that the user must follow up with credentials. No contradictions.
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, each providing distinct value: the first states purpose and condition, the second gives user guidance. No wasted words.
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?
For a simple tool with no parameters and no output schema, the description covers all necessary context: when to use, what it returns, and the follow-up action required. 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?
Tool has zero parameters, so schema coverage is 100%. Baseline 4 applies; no parameter details needed.
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 returns a single recommended VPS provider for users without a server. It specifies the exact resource ('recommended VPS provider') and the condition ('users who do not yet have a server'), differentiating it from sibling tools like check_status or register_and_deploy.
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 states when to call ('ONLY when the user explicitly says they have no server') and what the user should do next ('buys the VPS at this provider and comes back with IP + password'). Provides clear context and exclusions.
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides extensive behavioral details: creates/reattempts User, Subscription, ServerToken; wipes previous installation; launches bootstrap; deployment timeline 8-14 minutes; IP-first without domain/HTTPS; returns session_id for single check_status read and server_token for recovery. Annotations (destructiveHint=true) are consistent with 'wipes any previous installation'.
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 well-structured: purpose, prerequisites, actions, behavior, return values, and warnings. Every sentence adds necessary information without redundancy. Length is justified by complexity.
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?
Covers all essential aspects: purpose, prerequisites, atomic behavior, destructive nature, timeline, return values (no output schema but mentions session_id and server_token), and constraints (at most once, no polling). Also clarifies optional later steps.
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%, but description adds value: explains email double-entry for typo protection, defaults for login, and detailed behavior of components parameter (omission, empty array, full list). This goes beyond schema 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 registers a new user and deploys a server atomically, using specific verbs and resources. It distinguishes itself from siblings like retry_deploy and check_status by noting this is the initial deployment 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 says to use AFTER collecting user's email (with typo protection), server IP, and root password. It warns to call AT MOST ONCE per conversation, and implies alternatives for recovery (retry_deploy) and status checking (check_status, but only once).
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?
Discloses destructive behavior: 'wipes the previous broken install' (consistent with annotations destructiveHint=true). Provides context on authorization via server_token. 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 concise sentences, front-loaded with purpose. First sentence covers the action and token source; second covers effect and return. No filler.
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?
Covers purpose, when to use, parameter semantics, and return value. No output schema but mentions polling with check_status. Could add error handling for invalid tokens, but sufficient for a retry tool given other supports.
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% but description adds value beyond schema: explains where to find server_token, clarifies when to use optional params (ip, password) vs defaults, and gives guidance on components. Adds meaningful context.
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 specifies a clear verb+resource: 'Retry a failed deployment' using a server_token. It distinguishes from siblings by clarifying it works on the SAME server and returns a new session_id.
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 states when to use: when user reports a failed deploy or pastes a server_token. Mentions polling with check_status. Could be improved by explicitly excluding initial deployments, but context is clear.
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!