GDPR-compliant calendar access for AI assistants. Google, Microsoft 365, Apple & more. EU-hosted.
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 targets a distinct operation (create, delete, update, list, search, availability, feedback) with no overlapping responsibilities. Even the similar create/update/delete trio is clearly separated by action, and the two read tools (get_availability vs search_events) measure different things (busy times vs text matching).
All tool names follow a consistent lowercase verb_noun pattern (e.g., create_event, list_calendars, get_availability). No deviations in casing, verb style, or word order.
Seven tools is a well-scoped size for a calendar sync server, covering the core lifecycle and utility actions without bloat. Each tool has a clear purpose and the count sits comfortably in the ideal 3-15 range.
The set covers create/update/delete for events, calendar listing, availability, and search, but lacks a direct get_event or list_events tool, and events not created by this access cannot be modified. This creates a gap for common read-modify workflows, though search_events and get_availability partially compensate.
create_eventCreate eventAInspectCreates an event in one of the calendars this access may write to.
Availability in the requested slot is checked LIVE (not from cache). An overlapping event does NOT prevent creation — the event is created regardless and the overlap comes back as a warning. Pass that warning on to the user instead of silently double-booking; whether the overlap is intended is the user's call.
calendar_id is only needed when several calendars are writable; with exactly one, that one is used. list_calendars shows the writable calendars. title is required.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End, ISO 8601 with timezone | |
| start | Yes | Start, ISO 8601 WITH timezone — e.g. 2026-07-28T10:00:00+02:00 or …Z. Rejected without a zone. | |
| title | Yes | Event title (required) | |
| location | No | ||
| calendar_id | No | Target calendar; only needed when several are writable | |
| description | No |
| Name | Required | Description |
|---|---|---|
| warning | No | |
| event_id | Yes | |
| calendar_id | Yes | |
| calendar_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the annotations: availability is checked live, an overlapping event does not prevent creation and instead returns a warning, and the warning should be passed to the user to decide. It also clarifies that the access may write to specific calendars. This is valuable context not available from 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 concise and well-structured in three paragraphs: purpose, booking behavior, and parameter guidance. Every sentence earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description correctly focuses on behavior and edge cases. It covers the live availability check, overlap behavior, warning handling, and calendar_id logic, making it complete for a create tool with these nuances.
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 already covers required title, start, and end, and describes calendar_id. The description adds a useful behavioral rule for calendar_id: with exactly one writable calendar, that one is used, and points to list_calendars for discovering writable calendars. This adds meaning beyond the schema, though location and description are left self-explanatory.
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 opens with a specific verb and resource: 'Creates an event in one of the calendars this access may write to.' This clearly states the action and scope, and distinguishes it from sibling tools like delete_event, update_event, and search_events.
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 context on when to use the tool and related helper usage: 'list_calendars shows the writable calendars' and 'calendar_id is only needed when several calendars are writable; with exactly one, that one is used.' It does not explicitly name alternatives or exclusions, 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.
delete_eventDelete eventADeletes an event that THIS access created itself (via event_id from create_event). Events created by anyone else are not addressable. The deletion is executed at the provider and propagates into any mirrored calendars through the normal sync.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Identifier from create_event | |
| calendar_id | No |
| Name | Required | Description |
|---|---|---|
| deleted | Yes | |
| event_id | Yes | |
| calendar_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true. The description adds valuable behavioral context: the deletion is executed at the provider and propagates to mirrored calendars via sync, and only self-created events are addressable. This goes beyond the generic destructive hint.
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 that front-load the core purpose, then add a constraint and a behavioral detail. Every sentence earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering destructive intent, the description covers the essential aspects: what is deleted, the self-created scope, and sync behavior. It does not mention error cases or the role of calendar_id, but the core usage is fully explained.
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 50% — event_id has a description ('Identifier from create_event'), but calendar_id is undocumented. The description reinforces the event_id semantics by linking it to create_event and self-created events, but provides no clarification for calendar_id, leaving a meaningful gap.
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 ('Deletes an event') and specifies the exact resource scope (events that THIS access created itself). It distinguishes itself from sibling tools like update_event and create_event by emphasizing the self-created constraint.
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 clear context for when to use the tool: only for events created by the same access via create_event. It also states an exclusion ('Events created by anyone else are not addressable'), but does not explicitly name alternative tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_availabilityGet availabilityAReturns the user's busy times in a given range, across all calendars shared with this access.
How the answer is produced: every shared calendar is read directly at the provider and the results are merged. There is no detour through a copy. as_of per calendar says when it was read — reads are reused for up to 60 seconds, so an event created moments ago may briefly be missing.
What busy contains: every event that blocks time — including all-day events and ones marked "tentative". NOT included are cancelled events and events explicitly marked "free" in the calendar. An empty busy therefore means "nothing blocks this time", not "no events exist".
Completeness: the answer covers exactly the calendars the user shared — not necessarily all calendars they own. If one of them could not be read, it appears with read: false in sources and additionally in warnings. These limitations belong in your answer to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End of the range, ISO 8601 | |
| from | Yes | Start of the range, ISO 8601 (e.g. 2026-07-21T00:00:00Z) |
| Name | Required | Description |
|---|---|---|
| busy | Yes | |
| range | Yes | |
| sources | Yes | |
| warnings | Yes | |
| range_clamped | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, the description richly discloses behavioral traits: direct reads from provider (no copy), cached reads with 60-second reuse, what counts as busy (including tentative and all-day, excluding free/cancelled), and reporting unreadable calendars via sources and warnings. This far exceeds what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with its main purpose and then organized into three thematic paragraphs (production, busy semantics, completeness). Each sentence adds essential behavioral context without redundancy, balancing detail with readability.
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 presence of an output schema (which covers return values), the description is complete: it explains freshness, busy interpretation, scope limitations, and error reporting. No significant operational context is missing for an agent to use 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?
The input schema already provides 100% coverage of both parameters (from and to) with ISO 8601 format descriptions and an example. The description does not add parameter-specific semantics beyond referring to 'a given range,' so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Returns the user's busy times in a given range, across all calendars shared with this access.' This is a specific verb+resource+scope, and it distinguishes itself from siblings like list_calendars (which lists calendars) and search_events (which searches events).
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 clear context that this tool is for availability queries and explicitly defines its scope ('across all calendars shared with this access'), but it does not explicitly say when to use this tool instead of alternatives like search_events or list_calendars.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_calendarsList calendarsALists the calendars shared with this access, each with the detail level the user allowed.
readable: false means this calendar cannot be read right now — its events are also missing from get_availability. Such calendars are deliberately listed rather than omitted.
writable: true means this access may create events there. When more than one calendar is writable, create_event requires the calendar_id of one of them.
notice, when present, describes something the USER can change — either about this access or about their Kalender Sync setup. Pass it on rather than concluding the product cannot do what was asked. When it reads as an offer rather than an answer to what was asked, use your judgement about whether it fits the moment.
sync_health describes Kalender Sync's OWN synchronisation of this calendar, if it takes part in one. It does not affect availability answers (those read the provider directly), but a broken sync is something the user can fix.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| notice | No | |
| calendars | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint and destructiveHint annotations. It details the semantics of 'readable: false' (events missing from get_availability, deliberately listed), 'writable: true' (create_event implications), 'notice' (user-changeable items, pass on), and 'sync_health' (does not affect availability reads). This is rich behavioral context that helps the agent interpret result fields correctly.
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 front-loaded with the main purpose, then systematically explains each returned field in its own paragraph. Every sentence adds operational value, and the use of inline code formatting makes field names easy to scan. Despite being longer than average, it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple list tool with no parameters and an output schema, the description fully covers the meaningful context: what the output fields mean, how they affect other tools, and how the agent should handle notice and sync_health. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so schema coverage is effectively 100%. With no parameters to document, the baseline of 4 is appropriate; the description correctly focuses on output semantics rather than parameter syntax.
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 opens with 'Lists the calendars shared with this access, each with the detail level the user allowed,' which is a specific verb+resource statement. It clearly distinguishes the tool from siblings like get_availability and create_event by focusing on calendar metadata rather than events or mutations.
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 strong contextual guidance by explaining how readable/writable flags influence other tools (e.g., events missing from get_availability, create_event requiring calendar_id). However, it does not explicitly state when not to use this tool or name alternative tools, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_eventsSearch eventsAFinds events by text across the calendars shared with this access — case-insensitive substring match on title, location and description.
The search only sees what this access may see: it filters the same visibility-rendered data get_availability returns. Calendars limited to free/busy expose no text and therefore can never match — when such calendars are part of this access, a warning says so. "No match" is thus NOT proof that no such event exists.
The range works like get_availability (single span of at most 92 days, lookback bounded to one year). Without from/to the search covers the last 7 days plus the next 85. Cancelled events and events explicitly marked "free" are not searchable.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of the range, ISO 8601. Default: 85 days ahead. | |
| from | No | Start of the range, ISO 8601. Default: 7 days ago. | |
| query | Yes | Text to look for (case-insensitive substring) |
| Name | Required | Description |
|---|---|---|
| range | Yes | |
| matches | Yes | |
| sources | Yes | |
| warnings | Yes | |
| truncated | Yes | |
| range_clamped | Yes | |
| unsearchable_calendars | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, openWorldHint=false, destructiveHint=false), the description discloses critical behaviors: case-insensitive substring matching, free/busy calendar limitations, the warning about restricted calendars, range bounds (92-day span, 1-year lookback), and that cancelled/free events are not searched. This adds substantial context not available from annotations or schema.
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 dense sentences, each earning its place. It front-loads the core purpose, then adds caveats and range details without redundancy. No filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's complexity is high (visibility filtering, range constraints, search limitations), and the description covers all essential aspects: what it searches, what it cannot see, the no-match caveat, defaults, and exclusions. Since an output schema exists, not detailing return values is acceptable. The description is complete for an AI agent to select 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?
While the input schema already describes all three parameters (100% coverage), the description enriches them by explaining the default range (last 7 days plus next 85), the case-insensitive substring behavior, and the boundary conditions. It adds meaning to 'from' and 'to' by linking to get_availability's range semantics, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Finds events by text across the calendars shared with this access' and specifies the match targets (title, location, description), making the verb+resource+scope explicit. It clearly distinguishes from sibling tools like get_availability and list_calendars by emphasizing text search semantics.
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 context: it explains visibility filtering, warns that no-match is not proof of absence, and gives the default date range. It also references get_availability for range behavior, indirectly indicating when this tool is appropriate versus that one, plus notes non-searchable event types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_feedbackSend feedback to Kalender SyncAInspectSends feedback from the user to the Kalender Sync team — for example when the user wanted to do something these tools cannot do yet (editing an existing event, answering an invite, …), or when something looks broken.
Call this ONLY when the user explicitly asked to send feedback, or clearly agreed after you offered it. Never send feedback on your own initiative, and never include calendar content the user did not put into the message themselves.
Replies: for a bug report the team may send the user a single reply about it by default — set contact_ok to false if the user does not want that. For the other categories it is the reverse: no reply is sent unless the user asked for one, in which case set contact_ok to true. Never a newsletter signup either way.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The user's feedback in their own words (what they wanted, what happened). | |
| category | Yes | missing_capability: the user wanted something the tools cannot do. bug: something misbehaved. other: everything else. | |
| contact_ok | No | May the team send one reply about this feedback? Omit to use the default: yes for `bug`, no for the other categories. Set false if the user declined a reply, true if the user asked for one. |
| Name | Required | Description |
|---|---|---|
| received | Yes | |
| feedback_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the annotations, such as the default reply behavior per category, the distinction between bug and other categories for contact_ok, and the rule about not including unsolicited calendar content. Since annotations only provide basic booleans (readOnlyHint: false, destructiveHint: false), the description adds substantial value.
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 with a clear first paragraph explaining purpose, a second paragraph with when-to-use rules, and a third paragraph explaining contact_ok behavior. Every sentence provides necessary guidance without redundancy. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, 1 enum, 100% schema coverage, and an output schema), the description adequately covers usage rules and behavioral details. The only minor gap is the lack of explicit mention of what the tool returns (output schema exists but no description of response). However, since an output schema is present, this is acceptable.
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?
Although schema description coverage is 100%, the description adds context beyond the schema by explaining the contact_ok default behavior based on category (bug vs others) and the nuance of when to set it to true or false. The description could slightly improve by explicitly linking category values to the feedback scenarios mentioned in the first paragraph, but overall adds meaningful guidance.
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 sends feedback from the user to the Kalender Sync team, and provides concrete examples of when it should be used (e.g., missing capabilities, broken features). This distinguishes it well from sibling tools like create_event or update_event which handle calendar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool ('only when the user explicitly asked to send feedback'), when not to call it ('never send feedback on your own initiative'), and provides clear rules about including calendar content. It also gives nuanced guidance on the contact_ok parameter based on feedback category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_eventUpdate eventAUpdates an event that THIS access created itself (via event_id from create_event). Events created by anyone else are not addressable. title, start and end describe the complete new state.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | New end, ISO 8601 with timezone | |
| start | Yes | New start, ISO 8601 with timezone (e.g. …+02:00 or …Z) | |
| title | Yes | ||
| event_id | Yes | Identifier from create_event | |
| location | No | ||
| calendar_id | No | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| updated | Yes | |
| event_id | Yes | |
| calendar_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnly=false, so the description is not required to repeat that. The description adds useful behavioral context: events created by others are not addressable, and 'title', 'start', 'end' describe the complete new state, implying replacement semantics. 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 two concise sentences, front-loaded with the core purpose, and every clause adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main behavior and constraints, and the output schema plus annotations fill in return and safety details. However, it is ambiguous about how optional fields interact with the 'complete new state' statement, and there is no guidance on failure modes or permissions, leaving gaps for a tool with 7 parameters.
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 only 43%, so the description must compensate. It nicely explains the three required state fields and the origin of event_id, but it does not address optional parameters like location, calendar_id, or description, leaving their semantics unclear.
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 (update) and the resource (event), with a specific scope: only events created by this access. It distinguishes the tool from siblings like create_event and delete_event by adding the self-created constraint.
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 clear context on when to use this tool (for updating events that this access created) and implies a restriction (not for events created by others). However, it does not explicitly name alternatives or exclusions, leaving some room for inference.
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!