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.5/5 across 8 of 8 tools scored.
Most tools have distinct purposes (status, info about different aspects, address retrieval, recommendation, deploy, retry). However, get_ai_development_loop_info and get_ai_workspace_architect_info both return diagrams and explanations, which could cause minor confusion, but descriptions clarify their separate domains.
All tool names follow a consistent verb_noun snake_case pattern (e.g., check_status, get_project_info). No mixing of styles, predictable and clear.
With 8 tools, the set is well-scoped for a deployment and information server. Each tool addresses a necessary step or query without redundancy or bloat.
The tool surface covers the full deployment lifecycle (recommend, deploy, check status, retry, get address) plus comprehensive info. Minor gaps like cancellation or log streaming are absent but not critical for the server's stated purpose.
Available Tools
8 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_ai_development_loop_infoGet Fractera Development LoopARead-onlyInspect
Explains the Fractera development loop: how one admin request becomes tested, deployed, recorded code with no human writing it — Hermes orchestrates and loads its identity + project context, picks a ready coding agent (Claude Code, Codex, Gemini, Qwen, Kimi), the agent is enriched (SOUL.md / AGENTS.md / GLOSSARY.md / completed steps), generates a task then code, it is built and deployed, and the result branches (error feeds back; success updates the completed steps and the deployments tab) — all grounded by LightRAG memory at every step. RETURNS A DIAGRAM IMAGE URL you can show the user when they ask how Fractera builds software or how its agents work. Call with NO arguments to get the diagram URL + the "how the loop works" overview + the section list; call again with a single section id to read one stage in depth.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | A section id from the list (e.g. "hermes", "lightrag", "test-deploy", "the-record"). Omit to get the diagram, the overview and the section list. |
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 behavioral context: explains the loop, mentions it returns a diagram URL, and describes branching behavior (error feeds back, success updates). 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?
The description is upfront about the tool's purpose and then provides detailed usage. While informative, the extended explanation of the loop could be more concise. Nonetheless, it is well-structured and front-loaded.
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 one optional parameter and no output schema, the description is complete: it states purpose, usage modes, return types (diagram URL, overview, section list), and how the loop works. No missing 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?
The input schema has 100% coverage with a description for the section parameter. The tool description adds substantial usage semantics: omitting section yields diagram/overview/list; including section drills into one stage. This goes 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 clearly states the tool explains the Fractera development loop and returns a diagram URL. It distinguishes itself from sibling tools like get_ai_workspace_architect_info or check_status by focusing specifically on the development loop process.
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 to call with NO arguments for the overview and diagram, or with a section id for deeper detail. It mentions when to use (when user asks how software builds or agents work). However, it doesn't mention when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ai_workspace_architect_infoGet AI Workspace ArchitectureARead-onlyInspect
Architecture reference for Fractera AI Workspace: what it is made of and how it works (the admin drives it through Hermes — chat Web UI or Telegram — or directly through the five coding agents; a modal subscription sign-in layer + MCP keep work resilient when a subscription is limited; LightRAG is the central memory that slashes token use; Hermes is a light orchestrator while the coding agents do the heavy lifting; the result ships over HTTPS on a custom domain or plain HTTP on an IP). RETURNS A DIAGRAM IMAGE URL you can show the user when they ask what Fractera is or how it works. Call with NO arguments to get the wide illustration URL + the core "how it works" scenario + the section list; call again with a single section id to read one entity in depth.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | A section id from the list (e.g. "hermes", "lightrag", "coding-agents", "claude-code"). Omit to get the illustration, the overview scenario and the section list. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and non-destructive. The description adds that it returns a diagram URL, scenario, and section list, and explains the behavior of optional parameter. 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?
Paragraph is verbose with architectural details, but front-loads purpose and return value. Every sentence adds value, though some parenthetical content could be tightened.
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 details the return structure: diagram URL, overview scenario, section list, and depth info. Covers all needed information for a read-only tool with one optional parameter.
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 description for section. The tool description goes beyond by explaining the effect of omitting vs. providing the parameter, and lists example values ('hermes', 'lightrag'), adding significant meaning.
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 it retrieves architecture reference for Fractera AI Workspace, including a diagram URL, overview scenario, and section details. It distinguishes from sibling tools like check_status or get_project_info by being a non-transactional info tool.
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 call when user asks 'what Fractera is or how it works', and provides usage patterns: no arguments for illustration, section id for depth. Does not specify when not to use, but context suffices.
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?
The description discloses behavioral traits beyond annotations: it details destructive actions (wipes previous installation), creation of entities (User, Subscription, ServerToken), deployment timeline (8-14 minutes), return values (session_id, server_token), and warns against polling. This aligns with annotations (destructiveHint: true) and adds essential context.
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 (5 sentences), front-loaded with purpose, and each sentence provides distinct value. 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?
Given the tool's complexity (8 params, destructive action, no output schema), the description is comprehensive: it explains prerequisites, workflow, return values, constraints (AT MOST ONCE), and outcome. No gaps.
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 tool description adds workflow context for boolean parameters (e.g., email_confirmed, components_selected, terms_accepted) explaining when to set them. This adds meaning beyond the schema definitions.
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's purpose: registering a new user and deploying a server atomically. It lists specific actions (creates User, Subscription, ServerToken, wipes installation, launches bootstrap) and distinguishes from sibling tools like retry_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?
The description explicitly states when to use the tool: 'Use this AFTER you have collected the user's email...' and 'Call this AT MOST ONCE per conversation.' It implies prerequisites but doesn't explicitly mention when not to use or compare with alternatives.
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!