Svensk marknadsplats för lokala tjänster från verifierade företag — sök, boka och begär offert.
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.2/5 across 8 of 8 tools scored. Lowest: 3.5/5.
Most tools have distinct purposes, but avropa_tjanst and skapa_offertforfragan overlap in sending requests, with the difference being specific vs. general targeting. lediga_tider is somewhat redundant as it merely explains the paused booking and directs to other tools.
The majority follow a verb_noun pattern (e.g., sok_tjanster, las_foretag, skapa_offertforfragan), but lediga_tider deviates as a noun phrase rather than an action. Swedish naming is consistent in style, though las and tjanst are reused in multiple contexts.
Eight tools is well-scoped for a service mediation platform, covering search, details, requests, and quote management without feeling bloated or sparse.
Core workflows for requesting a specific service or a general quote are covered with create/read/select actions. Minor gaps include no way to track a direct avropa_tjanst request and the paused direct booking creates a dead end, but the tool descriptions guide workarounds.
avropa_tjanstAvropa tjänstAInspectSkickar en FÖRFRÅGAN till en leverantör — Saightly förmedlar kontakten (gratis, avgift_kr är alltid 0). Direktbokning är pausad: bekraftad_tid/pass avvisas (409). Ange kundens behov i kontakt.meddelande och gärna onskad_tid, så återkommer företaget direkt till kunden.
| Name | Required | Description | Default |
|---|---|---|---|
| typ | No | Typ av avrop. Standard: forfragan. | |
| pass | No | DELAD bokning: flera tillfällen (även spridda över dagar, t.ex. mån 14–16 + ons 08–12) som EN bokning med samma status och kund. Varje pass: start (ledig tid enligt lediga_tider, ISO 8601) + langd_minuter. Ersätter bekraftad_tid/langd_minuter. | |
| slug | No | Tjänstens slug (från sok_tjanster/las_tjanst) — VÄLJ RÄTT tjänst när företaget har flera. Utelämnad: företagets första aktiva tjänst. | |
| orgnr | Yes | Leverantörens organisationsnummer. | |
| kontakt | No | Kundens kontaktuppgifter. Vid bokning krävs namn, epost och telefon; adress krävs dessutom när tjänstens platstyp är hos_kund (se lediga_tider). | |
| tillval | No | Id:n på tjänstens tillval som kunden vill boka till (t.ex. färgning, webbmaster). Extra tid läggs på bokningen; namn och pris snapshotas på avropet. | |
| onskad_tid | No | Önskad tid (ISO 8601) för en förfrågan. | |
| ordervarde | No | Ordervärde i kr (ger värdebaserad avgift för bokning/försäljning). | |
| bekraftad_tid | No | Vald ledig tid (ISO 8601) från lediga_tider → direktbokning som blockerar slotten. Kräver kontakt med namn, epost och telefon. | |
| langd_minuter | No | Bokningens längd i minuter — sätt till summan av flera INTILLIGGANDE pass för en längre bokning (annars ärvs tjänstens standardlängd). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses that the service is free (avgift_kr always 0), that Saightly mediates the contact, and that bekraftad_tid/pass are rejected with 409. These are meaningful behavioral details, but it doesn't describe response format or side effects beyond the request being sent.
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 two sentences, front-loaded with the main action, and includes critical caveats without excess.
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 rich schema descriptions, the tool lacks an output schema and the description doesn't mention what the response contains. There is also ambiguity about whether typ=bokning is functional given the 'direct booking paused' note.
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 complete descriptions for all 10 parameters, including nested objects and enums, so the description doesn't need to add much. It mentions onskad_tid and kontakt.meddelande but relies on the schema for the rest.
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 sends a request (FÖRFRÅGAN) to a supplier and notes the fee is zero. It distinguishes itself from direct booking by saying that is paused, but does not explicitly differentiate it from the sibling skapa_offertforfragan.
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 instructs the user to include the customer's needs in kontakt.meddelande and preferably onskad_tid, and explicitly warns that direct booking fields are rejected with 409. However, it does not mention when to use this over skapa_offertforfragan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
las_foretagLäs företagAInspectHämtar grunduppgifter för ett organisationsnummer (namn, status, adress, SNI) från Bolagsverket.
| Name | Required | Description | Default |
|---|---|---|---|
| orgnr | Yes | Organisationsnummer (10 siffror, med eller utan bindestreck). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states the action and data source, but lacks details on authentication, rate limits, or any side effects. As a read-only operation, no destructive behavior is implied, but more transparency is needed.
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 sentence, front-loaded with action and resource. No redundant words; every part 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?
Lists retrieved data fields (name, status, address, SNI) but no output format details. With no output schema, more information about the return structure would enhance completeness. Adequate for a simple retrieval 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?
Only one parameter 'orgnr' with schema description already specifying format (10 digits with/without hyphen). Description adds 'organisationsnummer' confirmation but no further semantics beyond schema. Schema coverage is 100%, baseline 3.
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 states verb 'Hämtar' (retrieves), resource 'grunduppgifter för ett organisationsnummer', and specific data fields (namn, status, adress, SNI). Clearly distinguishes from sibling tools which deal with services and procurements.
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?
No explicit when-to-use or when-not-to-use guidance. The description implies usage for retrieving company basics from Bolagsverket, but does not mention alternatives or exclusions among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
las_offertforfraganLäs offertförfråganAInspectStatus och inkomna offerter för en tidigare skapad offertförfrågan (token från skapa_offertforfragan). Varje offert bär företag, verifiering, betyg, summa och pristyp (fastpris = bindande; budget = riktpris som stäms av innan start). Använd valj_offert för att välja vinnare.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Förfrågningstoken (returnerades av skapa_offertforfragan). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains that offers include company, verification, rating, sum, and price type, distinguishing fixed price from budget. It does not disclose other behavioral traits like rate limits or idempotency, so it carries partial burden adequately.
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 two concise sentences, front-loading the purpose and adding essential details about offer structure and price types. 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?
For a simple read tool with one parameter and no output schema, the description adequately covers what the tool returns (status and offers with fields) and references a sibling for next steps. It lacks error conditions or output format details but is sufficient for basic usage.
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 schema covers 100% of the single parameter 'token', describing its origin from 'skapa_offertforfragan'. The description reiterates this but does not add new meaning beyond the schema, so baseline 3 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?
The description clearly states the tool reads status and offers for a previously created offer request, using specific verb 'läsa' and resource 'offertförfrågan'. It distinguishes from sibling tools like 'valj_offert' (select winner) and 'skapa_offertforfragan' (create).
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 specifies the prerequisite: a token from 'skapa_offertforfragan'. It also mentions 'valj_offert' for selecting a winner, providing clear context. However, it lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
las_tjanstLäs tjänstAInspectHämtar detaljer för en specifik tjänst via dess slug (från sok_tjanster).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tjänstens slug, t.ex. "koksrenovering-vara". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It correctly indicates a read operation (hämtar detaljer) but provides no additional details such as whether it is read-only, permissions needed, or what constitutes 'detaljer'. The description is adequate but not rich.
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?
A single, well-structured sentence that front-loads the action and includes the key context. Every word is necessary; no wasted space.
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 simplicity of the tool (one parameter, no output schema), the description covers the essential purpose and parameter source. However, it lacks details on return values or any limitations, which would be helpful since there is no output schema. It is minimally 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?
Schema coverage is 100% with a clear parameter description. The tool description adds value by stating that the slug comes from sok_tjanster, giving the agent a concrete source for the parameter beyond the schema's example. This contextual guidance improves semantics.
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 action (hämtar detaljer), the resource (tjänst), and the key (slug). It explicitly references the sibling tool sok_tjanster as the source of the slug, distinguishing it from other tools that operate on services differently (e.g., searching, ordering).
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 tells the agent to use the slug from sok_tjanster, implying the tool should be called after a search. It provides clear context for when to use it but does not explicitly state when not to use or mention alternatives beyond the implied sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lediga_tiderLediga tiderAInspectDirektbokning är PAUSAD — verktyget svarar med tom slots-lista och en förklaring. Förmedla i stället kontakt: las_foretag ger företagets uppgifter, och avropa_tjanst (utan bekraftad_tid) skickar en förfrågan som Saightly förmedlar. Bokningen sker sedan direkt hos företaget.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Tjänstens slug (styr passlängd och utförare). Utelämnad: företagets första aktiva tjänst. | |
| antal | No | Antal tider att returnera (standard 5, max 120). | |
| orgnr | Yes | Leverantörens organisationsnummer. | |
| resurs | No | Filtrera på en specifik utförare (resurs-id från ett tidigare svar). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure responsibility. It openly states the tool is paused, returns an empty slots list, and provides an explanation. This is a transparent disclosure of the tool's unusual behavior and how to work around it.
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 two sentences, front-loaded with the critical message about the pause and immediately followed by actionable alternatives. Every word contributes value, 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?
Given the tool's unusual paused state, the description is complete: it explains the behavior (empty slots list), the reason (paused), and the exact alternatives to use (las_foretag, avropa_tjanst). Even without an output schema, the agent knows what to expect and how to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for all four parameters, so the description doesn't need to add parameter details. It adds no parameter-specific information beyond the schema, warranting the baseline score of 3.
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's current behavior: 'Direktbokning är PAUSAD — verktyget svarar med tom slots-lista och en förklaring.' This clearly indicates that the tool is not for booking and returns an empty slots list, distinguishing it from siblings by signaling its inactive status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Förmedla i stället kontakt: las_foretag ger företagets uppgifter, och avropa_tjanst (utan bekraftad_tid) skickar en förfrågan.' It names alternative tools and explains when to use them, effectively telling the agent to avoid this tool for booking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
skapa_offertforfraganSkapa offertförfråganAInspectSkickar en GENERELL förfrågan (t.ex. "bygga ut altan i Skara"). AI strukturerar briefen; förfrågan tas emot av emils.design — företaget bakom Saightly — som återkommer till kunden med förslag eller kontakt till rätt verifierat bolag. För att nå ETT specifikt företag direkt, använd avropa_tjanst. Giltiga branscher (profil): bygg, stad, it, konsult, transport, gront, kreativt, vard, generisk.
| Name | Required | Description | Default |
|---|---|---|---|
| ort | No | Ort där jobbet ska utföras (styr geografisk matchning). | |
| plats | No | Var uppdraget ska utföras. Utelämnad: företagen får fråga kunden. | |
| profil | Yes | Bransch/profil för jobbet. | |
| kontakt | Yes | Kundens kontaktuppgifter. | |
| beskrivning | Yes | Kundens beskrivning av jobbet i naturligt språk (minst 15 tecken). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses the process: AI structures the brief, emils.design receives it, and they return with suggestions or contact to verified companies. It does not state immediate response or storage, but provides meaningful 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?
Four sentences front-load the purpose, include an example, an alternative, and the valid profiles. Every sentence is informative and there is 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?
The description explains the full workflow, including the recipient and customer follow-up, which is good for a tool with nested objects and no output schema. It lacks explicit success/return details but is otherwise adequate given the schema's completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters. The description only repeats the valid profile enum without adding extra meaning, keeping it at the baseline 3.
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 sends a general request ('Skickar en GENERELL förfrågan'), includes an example, and distinguishes from the sibling tool avropa_tjanst for direct requests. The verb and resource are specific.
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 provides an alternative: 'För att nå ETT specifikt företag direkt, använd avropa_tjanst.' This clearly indicates when to use this tool versus the alternative, and the general-purpose context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sok_tjansterSök tjänsterAInspectSök lokala tjänster i fritext (t.ex. "snickare i Vara asap"). Tolkar kategori, ort och brådska och returnerar rankade leverantörer. tips listar smarta alternativ utanför den exakta träffbilden (annan ort, högre omdöme eller lägre pris) med skälet i klartext — bra att vidarebefordra till användaren.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Sökfråga i naturligt språk. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: interprets query parameters, returns ranked providers, and includes tips with reasons. It explains additional 'tips' feature beyond basic search, ensuring the agent understands the output.
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 the main purpose, followed by valuable detail on tips. No fluff, 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?
Given a single parameter with 100% schema coverage and no output schema, the description adequately covers input interpretation and output format (ranked providers with tips). No gaps for this complexity level.
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 one string parameter. The description adds meaning by specifying that the query's natural language is interpreted for category, location, and urgency, and provides an example, going beyond the schema's brief 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 clearly states the tool searches local services in free text, interprets category, location, and urgency, and returns ranked providers with tips. This distinguishes it from siblings like avropa_tjanst (ordering) or las_foretag (reading company 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 implies usage for finding services via free-text query, providing an example. It does not explicitly state when not to use it or name alternatives, but the sibling tool names provide context for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
valj_offertVälj offertAInspectVäljer vinnande offert på en offertförfrågan (id från las_offertforfragan). Vald → accepterad och företaget får kundens kontaktuppgifter; övriga avböjs vänligt och förfrågan stängs. Idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Förfrågningstoken. | |
| offert_id | Yes | Offertens id (från las_offertforfragan). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: acceptance of the winning quote, polite declination of others, closure of the request, and idempotency. This is transparent for a mutation tool, though it does not cover permissions or side effects beyond what is stated.
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 yet complete, consisting of one compound sentence and a fragment. It conveys the purpose, behavior, and idempotency without unnecessary words, following a logical structure that front-loads the primary action.
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 only 2 parameters, no output schema, and simple behavior, the description fully explains the selection process, effects, and idempotency. It is complete for an agent to understand what the tool does and when to invoke it.
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 adds value by specifying that 'offert_id' comes from 'las_offertforfragan'. The schema already adequately defines the parameters, so the description provides marginal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Väljer' (selects) and the resource 'offert' within the context of a 'offertförfrågan' (quote request). This distinctly identifies the tool's purpose and differentiates it from siblings like 'skapa_offertforfragan' (create request) and 'las_offertforfragan' (read requests).
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 explains when to use the tool (after receiving quotes, to select a winner) and describes the consequences (selected quote accepted, others declined, request closed). It implies usage context but does not explicitly contrast with sibling tools; however, the sibling names provide sufficient distinction.
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!