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.
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.
Average 4.8/5 across 6 of 6 tools scored.
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.
check_statusCheck Deployment StatusARead 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: it reveals that the tool returns current step, list of completed steps (~44 total), and completion status. It also clarifies that the read is on-demand and one-time, and notes the deployment timeline, which annotations do not cover.
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 three sentences long with no waste. It front-loads the purpose, then provides usage guidance, then return information. Every sentence is informative and 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?
Given a simple tool with one parameter and no output schema, the description fully covers purpose, when to use, what it returns, and important context (deployment time, authoritative channels). There are no obvious gaps for an AI agent to misuse the 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 coverage is 100% and the description does not add additional meaning to the session_id parameter beyond what the schema already provides. Baseline score of 3 is appropriate since the schema carries the semantic burden.
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 that this tool reads the current installation progress on demand. It specifies the verb 'Read' and the resource 'installation progress', and distinguishes itself from sibling tools like register_and_deploy and retry_deploy by focusing on status checking.
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: only when the user explicitly asks about deployment status, and never on a timer or in a polling loop. Provides context about deployment duration (8-14 minutes) and authoritative status channels, giving clear guidance on appropriate 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 InformationAProject 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds critical behavioral details: the two-step process, token-economy advice, and that calling without section returns a lightweight list. 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?
The description is a single dense paragraph but front-loads purpose, then usage context, then token-economy and parameter guidance. Every sentence adds value; no wasted words. Length is justified by the amount of actionable information.
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 tool has 0 required params, no output schema. The description fully explains both calling modes (with/without section) and what to expect from each. It covers the main use case of answering user questions about Fractera, especially during deploy. No gaps noted.
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 for both parameters (lang and section). The description adds meaningful usage context: the default lang behavior, the two-step process for section, and that omitting section yields a table of contents. This enhances the schema but is not essential given schema clarity.
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 serves as a project reference for Fractera, answering any user question about it. It distinguishes from sibling tools like check_status or get_ai_development_loop_info by focusing on general Fractera info, especially during deployments.
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 when to use (during deployments when user wants to learn), provides a token-efficient two-step process (call with no args first, then with section), and warns against fetching everything at once. Also advises on language setting for Russian users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subdomainGet Workspace AddressAReturn 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), description adds detail about the URL format (IP:3002, no domain/cert) and the state of the server, enhancing transparency.
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, front-loaded with main purpose, then necessary details. No redundant information.
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?
Even without output schema, description explains return value (URL format) and workflow (phase-1 vs later), making it complete for the tool's purpose.
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 meaning beyond the schema for the session_id parameter. Baseline score 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, distinguishing it from sibling tools by specifying it is called after check_status reports 'done'.
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: after check_status reports status='done'. Also provides context about phase-1 vs custom domain later, offering clear usage guidance.
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 RecommendationAReturn 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint true and destructiveHint false. Description adds context that it returns a recommendation and that the user will buy a VPS, which aligns with read-only behavior.
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, front-loaded with purpose. Every sentence adds value with no repetition.
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 parameters, no output schema, and adequate annotations, the description is fully complete for the tool's simple purpose.
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?
No parameters exist, so description does not need to add param info. Baseline 4 applies.
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 it returns a single recommended VPS provider for users without a server. Distinguishes from sibling tools like get_project_info, which cover different resources.
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 specifies when to call: ONLY when user explicitly says they have no server. Also describes the post-call workflow, guiding the agent on what to expect.
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 WorkspaceARegister 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. | |
| 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. | |
| 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. |
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.
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.
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.
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.
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.
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.
retry_deployRetry Failed DeploymentARetry 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true. The description adds concrete behavioral context: 'Wipes the previous broken install' confirms destruction, and 'Returns a new session_id — poll with check_status' explains the lifecycle. No contradictions. Could mention permanence of wipe or failure modes, but sufficient for safe usage.
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 well-structured sentences. First states the action, second explains the effect and return value, third tells when to use. Every sentence earns its place with no redundancy or fluff.
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 retry tool with no output schema, the description covers the return value (session_id), follow-up action (poll with check_status), and sources for the required server_token. It is complete enough for an agent to use correctly. Minor improvement could be adding error handling hints for invalid tokens, but not essential.
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 good descriptions. The description adds value by clarifying the conditional semantics of optional parameters (ip/password only if user discovered errors) and reinforcing server_token as authorization. This context goes beyond the schema's static 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 'Retry a failed deployment' with specific actions: wipes previous broken install, runs fresh deploy on same server, returns new session_id. It distinguishes from sibling tools like register_and_deploy by focusing on retrying a failed deploy using a server_token.
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 tells the agent when to use this tool: 'Use this when the user reports a failed deploy or pastes a server_token.' It also provides conditional guidance for optional parameters (ip/password only if user discovered wrong credentials) and implies alternatives via sibling tools.
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.
No comments yet. Be the first to start the discussion!
