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.6/5 across 7 of 7 tools scored. Lowest: 3.6/5.
Each tool has a clearly distinct purpose: deployment status, architecture info, project reference, final address, VPS recommendation, deployment initiation, and retry. No overlap.
Most tools follow a 'verb_noun' pattern (get_, check_, retry_), but register_and_deploy uses 'and' and mixes verb types. Still largely predictable.
Seven tools is well-scoped for a deployment and info retrieval server, covering core actions without unnecessary bloat.
Covers the main deployment lifecycle and information needs. Minor gap: no tool for cancelling a deployment or viewing detailed logs, but status and retry cover common cases.
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?
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_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 declare readOnlyHint=true and destructiveHint=false, so safety is clear. Description adds useful behavioral context: no arguments returns diagram+overview+section list; section argument provides depth. 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?
Single dense paragraph that front-loads purpose but is verbose. Could be more structured with bullet points for clarity.
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 thoroughly explains return values: diagram URL, overview, section list, and depth with section id. Covers all use cases adequately.
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 greatly enriches parameter meaning: lists example section ids, explains default behavior when omitted, and clarifies return structure for both cases.
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 explains the Fractera development loop and returns a diagram image URL. It distinguishes from sibling tools by focusing on the development process, while siblings like check_status or get_project_info have different purposes.
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 users ask how Fractera builds software or how its agents work. Provides guidance on calling with no arguments vs with a section id. No explicit when-not-to-use or alternatives, 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.
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 indicate readOnlyHint=true, so the description adds behavioral context about returning a diagram URL and text, but no additional details like side effects or rate limits are disclosed.
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 verbose, including a lengthy explanation of the architecture that is not strictly necessary for tool selection, making it less concise than ideal.
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, the description partially explains the return (diagram URL, scenario, section list) but omits the exact data structure, which is acceptable but could be more precise for a 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%, baseline 3. The description adds context about the effect of omitting vs providing the parameter, but this is already present in the schema's parameter description.
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 that the tool returns architecture reference and a diagram URL for Fractera AI Workspace, clearly distinguishing it from sibling tools like get_project_info or check_status by focusing on the overall architecture.
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?
It provides clear instructions on when to call without arguments (for overview) and with a section id (for detail), but does not mention when not to use the tool or suggest 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. | |
| 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?
Description discloses all key behaviors: atomic registration and deployment, creating/reusing User row, creating Subscription and ServerToken, wiping previous installation, launching bootstrap, and deployment timeline. It also notes return values and polling restriction. Annotations (destructiveHint=true) are consistent and fully explained.
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 relatively long but well-structured: purpose, prerequisites, internal actions, deployment details, return values, and usage limit. Each sentence adds essential information. Could be slightly tightened but remains efficient given 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?
Despite no output schema, the description explains return values (session_id, server_token) and their purpose. It covers prerequisites, destructive nature, timeout, lifecycle (retry with retry_deploy, check with check_status), and typical user flow. Contextually complete for an agent.
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 adds significant value beyond schema types and descriptions. For example, it explains the rationale for 'email_confirmed' (typo protection via double entry), the legal requirement for 'terms_accepted', and the interaction between 'components_selected' and 'components'. Every parameter is contextualized for safe usage.
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 explicitly states the verb ('Register and deploy') and the resource ('Fractera user and server deployment'). It clearly distinguishes from siblings like 'retry_deploy' and 'check_status' by calling it an 'atomic call' and specifying prerequisites.
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?
Description clearly states when to use ('AFTER you have collected...') and provides a cardinality rule ('AT MOST ONCE per conversation'). While it does not explicitly list when NOT to use, it implies alternatives like 'retry_deploy' for recovery and 'check_status' for monitoring, giving sufficient guidance.
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!