Turn any goal with a deadline into a private, gamified, evidence-based execution calendar.
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 9 of 9 tools scored.
Each tool targets a distinct action: creating, validating, revising, monitoring, attaching/reading documents, sharing, and template exploration. There is no overlap between create_calendar and revise_calendar, or between list_templates and get_template_guide.
All tool names follow a consistent lowercase verb_noun pattern with underscores (e.g., create_calendar, get_status, validate_spec). No mixed conventions or vague verbs.
With 9 tools, the set is well-scoped for the calendar lifecycle: setup, planning, monitoring, and support. Each tool earns its place without redundancy.
The tool surface covers the full workflow: template discovery, spec validation, calendar creation, revision, status checks, document attachment/reading, and sharing. No obvious missing operations for the intended coaching use case.
attach_documentAttach a documentAInspectAttach a supporting text document to a calendar — a syllabus/curriculum, exam spec, training history, race info. Stored with the calendar so any future session can read it when revising the plan. Text only (paste text out of PDFs), max 5 docs × 200KB.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Short document name, e.g. "AQA Biology GCSE spec" | |
| content | Yes | The full text content | |
| admin_token | Yes | ||
| calendar_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses persistence ('stored with the calendar') and limits ('text only', 'max 5 docs × 200KB'), going beyond the annotations. However, it does not address idempotency or what happens when a document with the same name is attached again, which would be useful given idempotentHint=false.
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 primary action, and every phrase adds value. No fluff, no repetition of schema or annotations.
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 tool with 4 parameters and an output schema, the description adequately covers the core purpose, persistence, and constraints. The gap is the lack of clarification on repeated attach behavior (overwrite vs duplicate), which could matter, but overall the context is sufficient for most use cases.
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 description adds meaning to 'content' by specifying it is text-only and giving examples (syllabus/curriculum, exam spec) and size limits. It also clarifies 'name' usage through examples. Schema descriptions cover 50% of parameters, but admin_token and calendar_id are self-explanatory from their names, and the description does not conflict with 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 action ('attach a supporting text document to a calendar') with specific examples (syllabus/curriculum, exam spec) and constraints (text only, max 5 docs × 200KB). This distinguishes it from siblings like read_document or create_calendar, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you need to store reference material for future sessions ('so any future session can read it when revising the plan'). It does not explicitly name alternatives or exclusions, but the context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_calendarCreate a sprint calendarAInspectCreate a hosted Consistency Calendar from a validated SprintSpec. Returns the user's private calendar URL and an admin token for later revisions. Free; each calendar includes 2 free AI revisions.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | A SprintSpec v1 that passed validate_spec |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only operation (readOnlyHint=false) but do not convey specifics. The description adds valuable behavioral context: it creates a hosted resource, returns a private URL and admin token, and clarifies the cost (free) and included revisions (2 AI revisions). This goes beyond the structured annotations and helps set expectations.
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 consists of three short, information-dense sentences. The first sentence states the primary purpose, the second explains key output artifacts, and the third covers cost and included revisions. There is no redundant or filler content, and the structure is logical and easy to scan.
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 tool with one parameter, output schema, and annotations, the description covers the essential context: prerequisite (validated spec), outputs (URL and token), and a notable business rule (free with 2 AI revisions). It does not explain the concept of a 'Consistency Calendar', but given sibling tools like get_template_guide, this may be understood from context. The output schema handles detailed return structure, so the description is sufficiently complete for typical 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 schema already provides 100% coverage for the only parameter ('spec' is described as 'A SprintSpec v1 that passed validate_spec'). The description merely echoes 'validated SprintSpec' without adding new details about the parameter's structure, requirements, or examples. Per the rubric, baseline 3 is appropriate when schema coverage is high and the description adds no further parameter 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 tool's function: 'Create a hosted Consistency Calendar from a validated SprintSpec'. This is a specific verb-resource pair that distinguishes it from siblings like create_share_link and revise_calendar, and also mentions the key outputs (URL and admin token), leaving no ambiguity about what the tool does.
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 when to use the tool by specifying it requires 'a validated SprintSpec', suggesting prior use of validate_spec. It also mentions 'admin token for later revisions', which hints at a workflow involving revise_calendar. However, it does not explicitly contrast with alternatives or state when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statusGet sprint progressARead structured progress for a sprint calendar (execution %, streaks, missed sessions, metric vs guide, at-risk flags) so you can coach the user. Requires the calendar_id and admin_token from create_calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| today | No | User-local date YYYY-MM-DD; defaults to server UTC date | |
| admin_token | Yes | ||
| calendar_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description aligns with these by saying 'Read'. It adds context about requiring admin_token for authorization and describes what data is returned, which goes beyond the 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?
Two sentences: the first front-loads the action and output, the second states the prerequisite. No unnecessary wording or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a read-only tool: purpose, output data, prerequisite, and user intent (coaching) are all covered. The output schema and annotations handle return values and safety, so nothing critical is missing.
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 only 33%; admin_token and calendar_id lack descriptions. The description compensates by stating they come from create_calendar, providing important origin context. The 'today' parameter is already documented in the schema, so it doesn't need repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool reads structured progress for a sprint calendar with specific metrics (execution %, streaks, missed sessions, metric vs guide, at-risk flags). The verb 'Read' and the specific resource distinguish it from sibling tools like read_document or list_templates.
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 a clear prerequisite: calendar_id and admin_token must come from create_calendar, indicating when to use this tool after calendar creation. However, it does not explicitly name alternatives or state when not to use it, but the guidance is sufficient for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_template_guideGet a coaching guideAGet the coaching guide for one sprint template: the interview checklist (what to ask the user), evidence-based constraints the plan must respect, a SprintSpec skeleton to adapt, and hard decline criteria. Pass the user's goal in goal to also receive a goal-specific playbook (marathon, HYROX, Ironman, weight loss, exam season, certifications, language exams…).
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | The user's goal in their words, e.g. "first marathon in April" — matches an expert playbook when available | |
| template_id | Yes | One of the ids from list_templates |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe read-only, idempotent operation. The description adds transparency about the output content (checklist, constraints, skeleton, decline criteria) and the conditional enrichment based on the goal parameter. This is more than the annotation provides, giving the agent a clear expectation of what the tool returns.
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 verb and resource, and packs in the key content categories without redundancy. The second sentence efficiently explains the optional goal parameter, making every word useful.
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 a rich output schema, the description doesn't need to explain return structure. It covers the tool's core function and the conditional objective behavior. It could mention a prerequisite (e.g., obtain template_id from list_templates), but that is already present in the schema, so the description is sufficiently 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%, but the description adds semantic value for the goal parameter by listing concrete goal types (marathon, HYROX, Ironman, etc.) and explicitly noting it triggers a goal-specific playbook. This goes beyond the schema's generic 'matches an expert playbook when available'.
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's purpose with a specific verb ('Get') and resource ('coaching guide for one sprint template'), and enumerates the guide's contents (interview checklist, constraints, skeleton, decline criteria). This distinguishes it from siblings like list_templates, which only lists template IDs.
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 when to use it: when you need the coaching guide for a specific sprint template, and it explains the optional goal parameter enriches the result with a goal-specific playbook. It doesn't explicitly compare to alternatives like validate_spec or get_status, but the context is clear enough that an agent can infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesBrowse sprint templatesAConsistency Calendar (consistencycalendar.com) turns a goal with a deadline (race, exam, savings target, life event, project) into a private, gamified, evidence-based execution calendar the user ticks off daily. Call this first to see the available sprint templates. It is a general planning tool, not a medical, financial, or treatment service.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds context about the product and a domain disclaimer ('not a medical, financial, or treatment service'), but does not disclose additional behavioral traits like response details or rate limits. With annotations covering the core behavior, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and slightly verbose. It begins with a product description before stating the tool's purpose in the second sentence, so it is not front-loaded. The disclaimer in the third sentence is somewhat tangential for a listing tool. Still, it is not excessively long, so it is acceptable but not ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters) and has an output schema plus comprehensive annotations. The description provides useful context about the overall product and the tool's role as the first step. It is complete enough for an agent to understand when and why to use it, though it could mention what the response contains, but the output schema covers that.
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 schema is empty (100% coverage). No parameter explanation is needed, and the baseline for 0 parameters is 4. The description does not add parameter-specific details because none exist.
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's function: 'Call this first to see the available sprint templates.' It identifies the resource (sprint templates) and the action (list/browse), matching the tool name. It also distinguishes from siblings like get_template_guide by positioning this as the initial step for viewing available templates.
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 by saying 'Call this first,' indicating this should be the initial call when working with sprint templates. However, it does not mention alternatives or when-not-to-use, stopping short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_documentRead an attached documentARead a document previously attached to a calendar (ids are listed in get_status under documents). Use when revising a plan so the new plan respects the syllabus/history the user provided.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes | ||
| admin_token | Yes | ||
| calendar_id | Yes |
| Name | Required | Description |
|---|---|---|
| error | No | A user-safe error message when the document cannot be read. |
| content | No | The attached document text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety semantics. The description adds useful behavioral context beyond that: it clarifies that the document must have been 'previously attached to a calendar' and shows how to find acceptable doc_id values via get_status. This gives a concrete operational detail not present in 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 two sentences, each with a clear purpose: the first states the action and scope, the second provides usage context and a pointer to find document IDs. There is no redundant phrasing or filler. It is front-loaded with the core verb and resource, making it easy to scan.
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 low complexity and the presence of annotations and an output schema, the description covers the essential context: what the tool reads, where IDs come from, and when to use it. It doesn't explain return values or error handling, but the output schema presumably covers that. The main gap is lack of context for calendar_id and admin_token, but those are inferable from the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the lack of parameter descriptions. It directly explains doc_id by saying 'ids are listed in get_status under documents,' which is helpful. However, it does not explain calendar_id or admin_token, leaving those parameters somewhat under-specified. The description partially compensates but not fully for all three required 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's function: 'Read a document previously attached to a calendar.' It distinguishes itself from siblings like attach_document, get_status, and revise_calendar by specifying its scope and resource. The reference to get_status for document IDs adds precise context, making it obvious this tool is for retrieving attached documents, not creating or modifying them.
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 use the tool: 'Use when revising a plan so the new plan respects the syllabus/history the user provided.' It also points to get_status as the source for document IDs. Although it doesn't explicitly list alternatives or when-not-to-use scenarios, the use case is clear enough to guide an agent's decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
revise_calendarRevise a sprint planAReplace a calendar's plan with a revised SprintSpec (life happened: injury, moved exam, new constraints). The user's ticks, moves and habit history survive; only the template layer changes. First 2 revisions per calendar are free.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | The full revised SprintSpec v1 | |
| reason | No | One line on why, for the version history | |
| admin_token | Yes | ||
| calendar_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation declares destructiveHint true, and the description clarifies the scope: 'The user's ticks, moves and habit history survive; only the template layer changes.' It also discloses a rate limit: 'First 2 revisions per calendar are free.' This adds valuable context 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?
The description is three concise sentences with no fluff. It front-loads the primary action and adds essential caveats in the following sentences.
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 complexity (nested spec object, destructive action, output schema), the description covers the essential context: what is replaced, what survives, and the free limit. The existence of an output schema means return values need not be 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?
With 50% schema coverage, the schema describes spec and reason, but calendar_id and admin_token lack descriptions. The description does not elaborate on parameters; it only refers to 'SprintSpec'. It provides little added meaning 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 action: 'Replace a calendar's plan with a revised SprintSpec.' It distinguishes from sibling tools like create_calendar (creation vs revision) and validate_spec (validation vs replacement). The mention of 'life happened' scenarios adds context.
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 for use: revising an existing plan when life circumstances change (injury, moved exam). It doesn't explicitly mention alternatives or exclusions, but the distinction from creation/validation is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_specCheck a plan is validAValidate a draft SprintSpec without creating anything. Returns machine-readable errors (fix and retry) and warnings (evidence-based advice — take them seriously).
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | The SprintSpec v1 JSON object |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as read-only, idempotent, and non-destructive. The description adds useful behavioral context by specifying that it returns machine-readable errors and warnings, with a note that warnings are evidence-based advice, improving transparency beyond the 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 extremely concise at two sentences, front-loaded with the primary function, and every word adds value. It clearly states what the tool does and what it returns without unnecessary 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?
With an output schema present and a single parameter thoroughly described, the description adequately covers the tool's behavior and output. The notes on errors and warnings are sufficient for an agent to use it 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 only parameter 'spec' is fully described in the schema as 'The SprintSpec v1 JSON object' (100% coverage). The tool description doesn't add further detail beyond the schema, 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 the tool's purpose: to validate a draft SprintSpec safely without creating anything. It distinguishes from sibling creation tools by emphasizing the non-mutating nature and specifying the machine-readable output, making it unambiguous.
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 phrase 'without creating anything' implies that this should be used before any creation step, and the validation focus is clear. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it falls short of a 5.
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!