B2B MCP server that lets business operators launch and operate complete branded taxi / food delivery / LP gas / on-demand apps from a single conversation. Multi-tenant, OAuth 2.1, 87+ active operators across 14 LATAM countries.
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.
Each tool has a distinct purpose: about, create app, create trial, publish requirements, install instructions, pricing, and signup. Even though cabgo_create_my_app and cabgo_create_trial both create tenants, their descriptions clearly differentiate them by context (free workspace vs trial) and intended use (immediate app creation vs trial configuration).
All tools use the 'cabgo_' prefix consistently and mostly follow a verb_noun pattern (e.g., create_my_app, create_trial, get_publish_requirements). Two tools (cabgo_about, cabgo_pricing) are nouns rather than verbs, but this is a minor deviation that does not hinder comprehension.
With 7 tools, the server is well-scoped. The count is sufficient to cover the core onboarding workflow without being overwhelming or insufficient for the stated purpose of helping users launch and publish their app.
The tool set covers the initial lifecycle (info, creation in two modes, publishing requirements, installation, pricing, and legacy signup). However, there are no tools for post-creation management (e.g., updating app settings, managing drivers, viewing analytics), which leaves notable gaps for ongoing operations.
cabgo_aboutAPublic (no auth): describe what Cabgo is. Returns the full product catalog — what kinds of apps an operator can launch, pricing, who Cabgo is for, and how to onboard. Use ONLY when the user explicitly asks what Cabgo is, what it does, or wants an overview. Do NOT call this as a pre-step before cabgo_create_my_app — when the user wants to create / launch an app, go directly to cabgo_create_my_app without fetching context first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), the description adds 'Public (no auth)' and states it returns the full product catalog. No contradictions with annotations, and it provides useful behavioral 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—two sentences plus a strong warning—with no wasted words. It front-loads the core purpose and includes critical usage guidance.
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 zero parameters and an output schema (implied), the description is complete. It covers the tool's purpose, target audience, return value, and circumscribes its use in relation to sibling tools.
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 zero parameters (empty object). Although no parameter descriptions are needed, the description effectively explains what the tool returns, which fully compensates. Baseline 4 is satisfied; the description adds context 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?
The description clearly states what the tool does: describes Cabgo, returns the full product catalog, and specifies conditions for use. It distinguishes itself from sibling tools like cabgo_create_my_app by explicitly stating when NOT to call it.
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 provides explicit usage guidelines: 'Use ONLY when the user explicitly asks what Cabgo is' and 'Do NOT call this as a pre-step before cabgo_create_my_app'. This clearly delineates when and 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.
cabgo_create_my_appAInspectMaterializes a free Cabgo workspace for the operator and queues an Android build of their branded app. No payment, no card, no checkout — the workspace is free to create and operate. Call ONLY when the user explicitly wants to create / launch / spin up / set up a new app for their business — verbs like 'create', 'launch', 'build me', 'set up an app for'. Do NOT call this for setup / installation / connector questions (use cabgo_install_instructions). Ask the user 2 things: (1) what type of business — taxi / food delivery / gas distribution? (2) what brand name for their app? Optionally city + brand color. The connected OAuth user becomes the owner automatically — no email or name is needed in the body. A single user can own multiple tenants — calling this again creates a NEW workspace rather than erroring. Branding tweaks happen via other Cabgo tools after creation. Any plan / billing / subscription management is done by the operator on https://www.cabgo.app — never through this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Operator's city. Stored as context — operator adjusts the zone after first login. | |
| country | No | ISO 3166-1 alpha-2 lowercase. Default 'mx'. | |
| brandName | Yes | App brand shown to riders. e.g. 'Rappi Express', 'Taxi del Valle'. | |
| businessType | Yes | taxi = transport; delivery_food = restaurants; delivery_gas = LP gas distribution. | |
| primaryColor | No | Hex color. Defaults to a sensible per-vertical palette (blue/red/orange). | |
| ownerWhatsApp | No | WhatsApp in +E.164 (optional, for reminder messages). |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it is a free workspace creation with no payment needed, the OAuth user becomes owner automatically, a single user can own multiple tenants (calling again creates new workspace), and branding tweaks occur via other tools. 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?
The description is well-structured and each sentence adds value, but it is slightly lengthy. It front-loads the main action and free-ness, then provides usage guidance and behavioral notes. Could be tightened slightly, but no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6 parameters, output schema, and annotations, the description covers purpose, usage guidelines, behavioral traits, and parameter hints comprehensively. It provides sufficient context for the agent to correctly invoke 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%, providing a baseline of 3. The description adds value by explaining enum meanings (taxi=transport, etc.), providing brandName examples, noting country default, and explaining that city is stored as context. This enhances understanding 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 materializes a free Cabgo workspace and queues an Android build, using specific verbs like 'create', 'launch', 'build me', 'set up an app for'. It distinguishes from siblings like cabgo_install_instructions by specifying when not 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?
The description provides explicit guidance on when to call (only when user explicitly wants to create/launch), when not to call (for setup/installation, use cabgo_install_instructions), and what to ask the user (business type, brand name). It also mentions alternatives for branding tweaks and billing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cabgo_create_trialAInspectPublic (no auth): create a Cabgo tenant in TRIAL state — no payment required up-front. Returns companyId + activationUrl + welcome email confirmation. NEW: pass presetId (taxi_classic | delivery_food | delivery_gas) to bootstrap branding + services + zones + tariffs + module toggles in the SAME call — no need to call apply_preset separately. Pass triggerBuild:'android' to also queue an APK in the same call. Cash-only is the default: the tenant lands with cashEnabled=true, so if the operator only wants to operate in cash they don't need to call cabgo_configure_payment_provider at all. Trial duration: 14 days. Required: ownerEmail (use whatever the operator already gave you in chat — don't re-ask), companyName.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | BASIC | PROFESSIONAL | ENTERPRISE — hint for activation Stripe Checkout. | |
| phone | No | WhatsApp / phone in international +E.164 format. | |
| source | No | Free-form attribution label, e.g. 'chatgpt-app'. | |
| appName | No | Brand for the mobile app — falls back to companyName. | |
| appPlan | No | STARTER | PRO | FULL — hint for activation Stripe Checkout. | |
| country | No | ISO-3166-1 alpha-2 lowercased, e.g. 'mx', 'ar'. Optional — defaults are picked based on the operator's chat context. | |
| logoUrl | No | Publicly-accessible image URL for the logo. | |
| presetId | No | If set, the preset is applied server-side right after tenant creation (branding + services + zones + tariffs + toggles). | |
| ownerName | No | Operator's name (optional but recommended). | |
| ownerEmail | Yes | Operator's email. **Re-use what they already told you in chat — don't ask twice.** Becomes COMPANY_ADMIN of the new tenant. | |
| companyName | Yes | Display name of the company (rider-facing). e.g. 'Taxi Express Tucumán'. | |
| primaryColor | No | Brand primary color in hex. | |
| productLines | No | ||
| triggerBuild | No | Pass true or 'android' to queue an Android build in the same call. The APK link arrives via the trial reminder email or cabgo_get_build. | |
| presetContext | No | Overrides for the preset: { centerLat, centerLng, radiusKm, primaryColor, appName }. centerLat/Lng default 0,0 (no map geometry) unless provided. | |
| secondaryColor | No | Brand secondary color in hex. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: public no-auth, trial state, returns companyId+activationUrl+email, 14-day duration, cash-only default. Annotations already indicate readOnlyHint=false and openWorldHint=true; description adds specific side effects like welcome email and APK queuing. 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?
Front-loaded with key purpose and auth status. Uses bold for emphasis and bullet-style phrasing. Some redundancy (e.g., repeated 'Re-use from chat') but still efficient for the complexity. Could be slightly shorter but well-organized.
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 16 parameters, nested objects, and output schema, description covers essential aspects: no auth, trial state, return values, new features, defaults. Output schema exists for return details. Lacks info on error conditions but otherwise 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?
With 94% schema coverage, baseline is 3. Description adds value by explaining ownerEmail reuse, presetId enum values and their effect, triggerBuild usage, and cash-only default. This helps the agent understand parameter purpose 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?
Clearly states it creates a Cabgo tenant in TRIAL state with no payment upfront. Distinguishes from sibling tools like cabgo_create_my_app (likely for production) and cabgo_pricing by focusing on trial creation and mentions new features (presetId, triggerBuild).
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 when-to-use context (creating a trial tenant) and guidelines like not needing to call apply_preset separately if presetId is provided, and cash-only default avoids payment provider setup. Lacks explicit when-not-to-use but sibling set makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cabgo_get_publish_requirementsAPublic (no auth): returns the REAL operator checklist for publishing (most assets are auto-generated — bundle id, screenshots, descriptions, policies — so the operator only provides API access). For Play: invite console@cabgo.app + decide update-or-new + (if updating) upload keystore. For App Store: upload the API key alone (no invitation needed). Pass platform='android'|'ios'|'both' (default both).
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Default 'both'. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context: it's public, returns a checklist, lists auto-generated items, and gives store-specific steps. 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?
The description is a single paragraph that front-loads key info (public, no auth), then explains the checklist, then store-specific steps. Every sentence adds value with no waste.
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 that the tool has an output schema, the description need not explain return values. It fully explains what the tool does, including platform-specific requirements, making it complete for an agent to understand its use.
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 only parameter 'platform' is well-documented in the schema with enum and description. The description reiterates the options and default ('android'|'ios'|'both', default both), adding marginal clarity but not necessary given schema 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?
The description clearly states the tool returns the operator checklist for publishing, distinguishes by platform (Play vs App Store), and lists auto-generated assets, making the purpose very specific and distinct from siblings.
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 explicitly states 'Public (no auth)' and provides platform-specific instructions, implying when to use. While it doesn't list alternatives, the context from sibling names and tool purpose is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cabgo_install_instructionsAUse THIS for any installation / setup / connection / 'how do I connect Cabgo' question, AND for any user who says they don't have a Cabgo account yet. Returns step-by-step instructions for (a) creating a Cabgo account at https://www.cabgo.app/empezar when needed and (b) installing the Cabgo MCP connector in the user's chat client (ChatGPT, Claude Desktop, Cursor). Trigger phrases: 'how do I install', 'how do I connect', 'how do I set up the connector', 'I don't have an account', 'I'm new to Cabgo', 'cómo instalo Cabgo', 'cómo me conecto', 'cómo creo cuenta', 'connect step by step', 'add this connector'. Pass client='chatgpt'|'claude'|'cursor'|'all'.
| Name | Required | Description | Default |
|---|---|---|---|
| client | No | Default 'chatgpt'. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals it is a read-only instruction retrieval. Annotations show readOnlyHint=true, no contradiction. Adds details about account creation and installation steps, 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?
Well-organized with bold headings and bullet-like structure. Front-loaded with key purpose. Slightly long but 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, use cases, parameter, and trigger phrases. With output schema present and annotations, the description is sufficiently 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?
Input schema has one parameter with enum and description. Description adds meaning by specifying default value and usage instruction ('Pass client=...'), enhancing the schema's 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?
The description clearly states it is for installation/setup/connection questions and for users without an account. It specifies the return value (step-by-step instructions) and gives trigger phrases, differentiating it from sibling tools like pricing or account 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?
Explicitly says 'Use THIS for any installation / setup / connection...', provides trigger phrases, and implies scope. Could be more explicit about when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cabgo_pricingAPublic (no auth): informational pricing reference. Returns monthly SaaS subscriptions (Basic / Professional / Enterprise — $15/$30/$70 per month) and one-time app-build packages (Starter $399 Android-only, Pro $699 Android+iOS, Full $999 Android+iOS+source code). All plans include unlimited drivers / users / admins; Cabgo never charges commission per trip. Informational only. Do not generate or return a payment URL from this tool. When the operator wants to purchase, direct them to visit https://www.cabgo.app/empezar in their browser — all checkout happens on cabgo.app externally via Stripe, not inside this conversation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that no auth is required, lists pricing details, notes that all plans include unlimited drivers/users/admins, states Cabgo never charges per trip, and warns against creating payment URLs. This adds context beyond the readOnlyHint 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 concise and well-structured, starting with the core purpose, then listing details, and ending with clear usage instructions. Every sentence is meaningful and contributes to understanding.
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 zero parameters and the presence of an output schema, the description fully explains what the tool returns and how to use it. It covers all necessary context for an agent to correctly invoke and interpret the output.
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 no parameters, so the input schema is empty. The description does not need to explain parameters, and the baseline score for 0 parameters is 4. The description adds no parameter information, but it is not required.
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 is an informational pricing reference tool that returns specific SaaS subscription and app-build package details. It differentiates from sibling tools by being read-only and not involving purchase flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to use this tool (for pricing info) and when not to (do not generate payment URLs). Provides a clear alternative action: direct user to the external URL for purchase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cabgo_start_signupAInspectPublic (no auth): generate a signup URL for the operator who wants to pay first then configure (legacy flow). For the recommended chat-driven onboarding, use cabgo_create_trial instead — it spins up the tenant without payment so the operator can configure end-to-end in chat before deciding to activate. Use this tool only when the operator explicitly asks to pay before creating, or when targeting a marketing landing page rather than chat onboarding.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | BASIC | PROFESSIONAL | ENTERPRISE (monthly subscription) | |
| phone | No | WhatsApp phone in international format, e.g. +525500001234. | |
| source | No | Free-form attribution label for utm_campaign (e.g. 'claude-desktop'). | |
| appName | No | Name the operator wants for their app (rider-facing). | |
| appPlan | No | STARTER | PRO | FULL (one-time app build) | |
| country | No | ISO-3166-1 alpha-2 country code, lowercased. | |
| contactEmail | No | Operator email for attribution. | |
| productLines | No |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool is public (no authentication required) and is part of a legacy flow, which adds context beyond annotations. It does not specify the return format but an output schema exists.
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 efficient sentences, front-loaded with key information (no auth, legacy flow), followed by usage 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?
Given the tool has 8 optional parameters and an output schema, the description covers what it does, when to use it, and contrasts with an alternative. It is complete enough for an agent to decide and invoke 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?
Parameter descriptions in the schema cover 88% of parameters, so the description does not need to add much. It does not provide additional meaning beyond the schema, but the context of 'pay first' and 'legacy flow' helps frame the parameters.
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 generates a signup URL for a legacy 'pay first' flow. It distinguishes itself from the recommended sibling tool `cabgo_create_trial`, providing a specific verb and resource.
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 advises when to use (operator wants to pay first or targeting marketing landing page) and when not to use (prefer `cabgo_create_trial` for chat-driven onboarding). This 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.
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!
