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.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.
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_ai_development_loop_infoGet Fractera Development LoopAExplains 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, and the description confirms a read-only operation returning a diagram URL and text. It adds rich behavioral context beyond annotations, detailing the internal orchestration and agent enrichment process, without contradicting any annotation.
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 somewhat lengthy (two sentences) but front-loads the purpose and packs essential details. Each part contributes value, though it could be slightly more streamlined without losing 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 one parameter and no output schema. The description compensates fully by explaining the return content (diagram URL, overview, sections), the internal process, and usage patterns. It provides everything an agent needs to invoke the tool correctly.
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 description for the optional 'section' parameter. The description adds significant value by specifying that omitting the parameter yields the diagram, overview, and section list, while providing a section id reads one stage in depth. This greatly aids the agent in correctly using the parameter.
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, overview, and section details. It distinguishes from sibling tools like get_project_info or get_vps_recommendation 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 this tool when the user asks how Fractera builds software or how its agents work. It also explains two usage patterns: no arguments for overview or with a section id for depth. However, it does not explicitly exclude other contexts or compare to siblings.
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 ArchitectureAArchitecture 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations (readOnlyHint=true, destructiveHint=false) by explaining the return format: diagram URL, scenario, and section list. It reinforces the safe, read-only nature. 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 verbose but informative. It front-loads the main purpose and then provides a parenthetical overview that is somewhat run-on. While every sentence adds value, the structure could be tighter.
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 adequately explains return types (diagram URL, scenario, section list). It covers the main use cases and parameter behavior. Minor gaps (e.g., error handling for invalid section IDs) but sufficient 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%. The description adds meaning beyond the schema by explaining the effect of omitting vs. including the section parameter, and listing example section IDs like 'hermes'. This helps the agent understand parameter 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?
The description clearly states the tool retrieves architecture reference for Fractera AI Workspace, specifying it returns a diagram image URL, overview scenario, and section list. The verb+resource is specific, and it distinguishes from sibling tools focused on other aspects like development loop or project info.
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 advises calling with no arguments for the big picture and with a section id for deep dives. It mentions the trigger 'when they ask what Fractera is or how it works,' providing clear context for use. However, it does not explicitly state when not to use 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 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true; the description adds context about creating User, Subscription, ServerToken, wiping previous installation, and bootstrap. It also explains deployment phases and returns, without contradicting 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 paragraph but front-loads purpose and prerequisites. While dense, it efficiently conveys all necessary information without redundant sentences. Slightly long but acceptable for the 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?
Given 8 params, destructive nature, and no output schema, the description covers prerequisites, behavioral steps, return values, and constraints (e.g., IP-first phase). It explains everything an agent needs to invoke this tool safely and correctly.
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%, so baseline is 3. The description adds meaningful semantics beyond schema for params like 'email_confirmed' (requires double entry) and 'terms_accepted' (requires explicit user agreement), justifying a 4.
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 'Register a new Fractera user and start the deployment of their server in one atomic call,' specifying the verb (register/deploy), resource (Fractera user/server), and scope (atomic call). It distinguishes from siblings like 'retry_deploy' and 'check_status' by mentioning them as separate steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this AFTER you have collected the user's email...', lists prerequisites, and warns 'Call this AT MOST ONCE per conversation.' It also mentions an alternative (retry_deploy) for recovery, providing clear when/when-not/alternatives 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 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true. The description adds that it 'wipes the previous broken install' and returns a session_id for polling, providing behavioral detail beyond the annotation.
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 that are front-loaded with purpose and key behavior. No wasted words; every sentence adds value.
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 return value (session_id) and polling method. With 5 parameters and destructive nature, it is adequately complete. No output schema, but the description compensates by explaining what to do with the result.
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 parameter descriptions. The description adds value by explaining the source of server_token, default behavior for components (OMIT for full toolset), and context for optional parameters like ip and password.
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 verb 'retry' and resource 'deployment' with specificity about using a server_token. Distinguishes from sibling tools like register_and_deploy by focusing on retrying a failed deployment on the same server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when user reports failed deploy or pastes a server_token. While it does not explicitly exclude initial deployments, the context of 'retry' and reference to sibling register_and_deploy provides sufficient guidance.
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!
