Personalized timing intelligence for AI agents — ask 'should I do X on this date?'
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 time granularity (hour, day, month, year) or a specific function (chart, profile management). No two tools overlap in purpose; the descriptions clearly differentiate them.
All tools follow a consistent 'intentions_<verb>_<noun>' pattern. The verb for time queries is uniformly 'ask', and profile tools use 'get'/'set'. The 'energy_chart' tool is the only slight deviation but still readable and fits the pattern.
Seven tools is an ideal size for this domain. Each tool serves a well-defined purpose without unnecessary redundancy or gaps, covering time queries at multiple granularities, visual charts, and profile management.
The tool surface fully covers the intended functionality: asking about timing at hour, day, month, and year levels; generating visual charts; and managing user profile. No obvious dead-ends or missing operations for the stated purpose.
intentions_ask_dayACall when the user asks about timing a decision for a specific date, or wants to pick the best day from a multi-day window. Covers trip dates, launch days, interview/meeting days, publish/send dates, travel, negotiation windows, relationship moments — any "when to X" question where the answer is a date ("should I X on April 23", "best day this month to Y", "下周四怎么样"). Modes: single date, compare up to 5 dates, or scan a range up to 31 days. Returns score (0-100), verdict, per-layer year/month/day breakdown (alerts + dimension signals), element breakdown, adverse alerts. For multi-month windows use intentions_ask_month; for hour precision use intentions_ask_hour.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Decision domain — tunes the analysis weighting. Default: general. | |
| question | Yes | The decision or action being considered | |
| birthInfo | No | Optional override. If provided, all 6 fields required: { year, month, day, hour, minute, gender } — use null for unknown hour/minute/gender. Omit entirely to use the stored profile. | |
| dateRange | No | Find best dates in range. Max 31 days — use ask_month for longer windows. | |
| targetDate | No | YYYY-MM-DD. Default: today | |
| compareDates | No | Up to 4 additional YYYY-MM-DD dates to compare against targetDate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true, and the description does not contradict it. The description adds valuable context on return values ('score (0-100), verdict, per-layer year/month/day breakdown, etc.'), which goes beyond the annotations. No destructive or auth information is needed as it's a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about 5 sentences, front-loaded with the primary use case. Every sentence adds value without redundancy. It is concise and well-structured.
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 there is no output schema, the description adequately explains return values (score, verdict, breakdowns). It covers the three modes and references sibling tools. Could mention that output is JSON, but otherwise it is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described, so baseline is 3. The description adds extra meaning by explaining modes (e.g., 'Modes: single date, compare up to 5 dates, or scan a range up to 31 days'), constraints (max 31 days for range, max 4 compare dates), and the optional nature of birthInfo. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Call when the user asks about timing a decision for a specific date, or wants to pick the best day from a multi-day window.' It uses specific verbs and resources, and distinguishes from sibling tools by mentioning alternatives for longer windows or hour precision.
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 use the tool, provides examples of scenarios (trip dates, launch days, etc.), mentions modes (single date, compare up to 5 dates, scan range up to 31 days), and gives exclusion criteria: 'For multi-month windows use intentions_ask_month; for hour precision use intentions_ask_hour.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
intentions_ask_hourACall when the user asks about timing within a specific day — best hour to act, morning vs afternoon, when during the day ("best time today to X", "morning or afternoon for Y", "几点去见面好"). Use for interview slots, meeting times, send/publish times, departure times, workout windows. Pro subscription required; on the free tier this returns a subscription_required error whose payload suggests intentions_ask_day for day-level analysis or intentions_energy_chart with period weekly / yearly for a visual overview (the caller LLM decides whether to retry). Modes: single (date+hour), compare up to 5 hour-pairs, or scan all 12 two-hour blocks of one day. Accepts any clock hour 0..23; internally mapped to the containing 2-hour block midpoint (0/2/4/…/22). 23:00–23:59 automatically rolls the effective day forward by one. Every output entry includes a window { start, end } local wall-clock span (YYYY-MM-DDTHH:MM, no timezone offset — interpret in the same frame as the input hour). Always cite this when presenting the time. Returns score, verdict, adverse alerts.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Decision domain — tunes the analysis weighting. Default: general. | |
| question | Yes | The decision or action being considered | |
| bestInDay | No | Find best hours within a single day. Each entry carries an explicit `window` span. | |
| birthInfo | No | Optional override. If provided, all 6 fields required: { year, month, day, hour, minute, gender } — use null for unknown hour/minute/gender. Omit entirely to use the stored profile. | |
| targetDate | No | YYYY-MM-DD. Default: today (single mode only) | |
| targetHour | No | Clock hour 0..23. Auto-rounded to the containing 2-hour block. 23:XX rolls the effective day forward by one. | |
| compareHours | No | Up to 4 additional (date, clock-hour 0..23) pairs to compare against targetDate+targetHour. Pairs that resolve to the same 2-hour block (e.g. hours 7 and 8 on the same date) are deduplicated — submit distinct blocks if you want distinct results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description adds extensive behavioral context: pro subscription required, free tier error handling, three modes (single, compare, scan), internal mapping to 2-hour blocks, 23:00-23:59 rolls day forward, output includes window span with no timezone offset. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise considering the complexity; front-loaded with purpose and usage. Every sentence adds value, but could be slightly better structured (e.g., separate sections for modes, edge cases, output). Still effective and efficient.
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 (7 params, nested objects, no output schema), description covers usage context, subscription behavior, all three modes, edge cases (hour roll), and output format (window, score, verdict, alerts). No output schema but description sufficiently informs agent of return structure.
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%, baseline 3. Description adds meaningful details beyond schema: explains targetHour auto-rounding, compareHours deduplication rule, bestInDay.top default, and output window format. Only minor gap: no default for category or targetDate described beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool is for timing within a specific day (best hour, morning vs afternoon). Uses specific verbs like 'Call when the user asks about timing within a specific day' and distinguishes from siblings by naming alternatives (intentions_ask_day, intentions_energy_chart).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (user asks about timing within a day), mentions pro subscription requirement and free tier behavior with clear fallback suggestions. Provides alternatives for different granularity (day-level analysis, visual overview).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
intentions_ask_monthACall when the user asks at month granularity or wants the best month from a multi-month window ("how is next month", "best month in 2026 to X", "下个月适合吗"). Use for trip-month selection, launch months, content-calendar planning, quarterly/annual decisions. Modes: single month, compare up to 5 months, or scan up to 12 months (returns top 5). Returns month score, element breakdown, adverse alerts. For day precision near the 4th–6th of a month use intentions_ask_day; for hour precision use intentions_ask_hour.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Decision domain — tunes the analysis weighting. Default: general. | |
| question | Yes | The decision or action being considered | |
| birthInfo | No | Optional override. If provided, all 6 fields required: { year, month, day, hour, minute, gender } — use null for unknown hour/minute/gender. Omit entirely to use the stored profile. | |
| monthRange | No | Find best months in range. Max 12 months. Inclusive on both ends. | |
| targetMonth | No | YYYY-MM. Default: current month | |
| compareMonths | No | Up to 4 additional YYYY-MM months to compare against targetMonth |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, so the description's lack of read-only mention is acceptable. It adds helpful context on scanning limits and return elements (score, breakdown, alerts) 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 well-organized: first usage, then modes, then sibling pointers. Though slightly long, every sentence adds value and is front-loaded with when to call.
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 (6 params, no output schema), the description covers the key aspects: modes, return values, and sibling alternatives. It omits details like 'element breakdown' but is sufficient for correct selection and invocation.
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 clarifies the meaning and use of parameters beyond the schema: 'compare up to 5 months' maps to compareMonths, 'scan up to 12 months' maps to monthRange. Schema coverage is 100%, so baseline is 3, but description adds significant usage context.
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 is for month-level queries, with explicit examples like 'how is next month' and 'best month in 2026'. It contrasts with sibling tools that handle day or hour precision.
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 provides explicit when-to-use guidance ('call when the user asks at month granularity'), explains modes (single, compare, scan), and directly names alternatives for day or hour precision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
intentions_ask_yearACall when the user asks about a full calendar year as a whole ("how is 2026", "今年怎么样", "what's next year like overall"). Returns year-level score, verdict, adverse alerts, and element dimensions. For month precision use intentions_ask_month; for day use intentions_ask_day. Window: currentYear-1 to currentYear+1 only.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Decision domain — tunes the analysis weighting. Default: general. | |
| question | Yes | The decision or action being considered | |
| birthInfo | No | Optional override. If provided, all 6 fields required: { year, month, day, hour, minute, gender } — use null for unknown hour/minute/gender. Omit entirely to use the stored profile. | |
| targetYear | No | YYYY. Default: current year. Allowed: currentYear-1 .. currentYear+1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds that it returns 'year-level score, verdict, adverse alerts, and element dimensions', which is useful context about the output. There is no contradiction. The behavioral constraint (window) is also disclosed.
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, no fluff. First sentence clearly states purpose and return content. Second sentence provides sibling differentiation and constraints. Every sentence is valuable and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description gives a high-level overview of return fields (score, verdict, alerts, dimensions). It covers main usage, constraints, and sibling relationships. Could elaborate on output structure, but sufficient for an agent to understand when to call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters adequately. The description does not add parameter-level details beyond what the schema provides, leading to a 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 clearly states this tool returns year-level outlook for a full calendar year, with specific examples of user queries ('how is 2026', '今年怎么样'). It distinguishes from sibling tools by explicitly mentioning month and day alternatives, and includes a window constraint (currentYear-1 to currentYear+1).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call ('when the user asks about a full calendar year as a whole') and when not to ('For month precision use intentions_ask_month; for day use intentions_ask_day'). Also provides a behavioral constraint (window limited to currentYear±1).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
intentions_energy_chartACall when the user wants a visual overview rather than a narrative answer ("show me this week", "chart for today", "next 12 months", "看一下图"). Returns an ASCII chart: hourly = 12 two-hour blocks of one day, weekly = 7 days, yearly = 12 months. The hourly mode emits the same hour-resolution scores as intentions_ask_hour and is gated behind the Pro subscription on the same terms — on the free tier it returns a subscription_required error whose payload suggests weekly / yearly chart modes or intentions_ask_day as alternatives. weekly and yearly are always free.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD. Default: today | |
| period | Yes | Which chart to render: `hourly` = 12 two-hour blocks of one day (Pro-gated), `weekly` = 7 days, `yearly` = 12 months. | |
| birthInfo | No | Optional override. If provided, all 6 fields required: { year, month, day, hour, minute, gender } — use null for unknown hour/minute/gender. Omit to use the stored profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: it returns an ASCII chart, hourly mode is gated behind Pro subscription, and free tier gets a subscription_required error with alternative suggestions. No contradiction with readOnlyHint.
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 front-loaded 'when to call' statement, followed by details. It is slightly verbose but each sentence adds value, explaining modes, gating, and alternatives.
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 3 parameters, no output schema, and moderate complexity, the description is complete. It covers chart output, subscription model, error handling, and parameter usage (birthInfo overrides, default date). It provides all necessary context 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?
Schema coverage is 100%, and the description adds context beyond parameter descriptions, such as explaining the gating for hourly and the behavior of birthInfo (use null for unknown fields). It also clarifies the meaning of the period enum values in the context of chart blocks.
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: providing a visual overview via ASCII charts for different periods (hourly, weekly, yearly). It distinguishes from narrative answers and sibling tools like intentions_ask_hour by noting that hourly mode emits the same hour-resolution scores as that tool.
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 tells when to use this tool (user wants visual overview, with example phrases) and provides guidance on alternatives: for free tier with hourly mode, it suggests weekly/yearly charts or intentions_ask_day. It also notes that hourly is Pro-gated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
intentions_get_profileAFetch the user's currently stored birth info. Use this before intentions_set_birth_info when updating an existing profile so you can send back a complete merged payload. Returns { hasProfile, birthInfo: { year, month, day, hour, minute, gender } | null } where any unknown field (e.g. unknown hour) is returned as null. No quota cost.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), the description details the return format including null handling for unknown fields and states 'No quota cost.' This adds significant value by clarifying response structure and cost implications.
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 states the primary action, the second provides usage guidance and return details. Every word earns its place, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly covers the return type and field structure, including null handling. It also mentions no quota cost. Could be improved by describing error conditions, but for a read-only fetch tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema coverage is 100% (empty). The description does not need to add parameter info; baseline 4 for zero parameters 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 fetches the user's currently stored birth info, distinguishing it from sibling tools like intentions_ask_* (for individual fields) and intentions_set_birth_info (for updating). The verb 'fetch' and resource 'birth info' are specific and 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?
Explicitly instructs to use this before intentions_set_birth_info when updating an existing profile to send a merged payload. Provides clear context but does not explicitly state when not to use it (e.g., for new profiles), though this is implied by the update workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
intentions_set_birth_infoACall once to register the user's birth date/time/gender. Each call is a complete replacement — all 6 fields must be supplied. For fields the user does not know or prefers not to share, pass null explicitly (e.g. hour: null for unknown birth time, gender: null for unspecified). To update just one field, first call intentions_get_profile to fetch the current values, merge the user's new input, then call this tool with the full merged payload. Identity-changing edits (year/month/day/hour/gender) are limited to 3 per calendar month; adding precision (e.g. filling in a previously-null hour) is always free. Returns the element profile.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | Birth day of month, 1–31. | |
| hour | Yes | null if unknown | |
| year | Yes | Birth year, 1920–2030. | |
| month | Yes | Birth month, 1–12. | |
| gender | Yes | null if unspecified | |
| minute | Yes | null if unknown; requires hour to also be non-null |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (idempotentHint: true), the description adds critical behavioral context: it explains that the tool is a complete replacement, notes the monthly edit limit for identity-changing fields, and clarifies that adding precision (e.g., filling a previously null hour) is not counted against the limit. It also states the return 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 a single coherent paragraph, but it contains multiple important points without redundancy. It is front-loaded with the purpose and then details usage rules. While slightly dense, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 required parameters, rate limit, null handling, update procedure), the description is remarkably complete. It covers return value, usage pattern, constraints, and edge cases. No output schema is provided, but the description compensates by stating the return value.
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 has 100% description coverage for parameters. The description adds value by explaining null handling for unknown fields (e.g., 'hour: null for unknown birth time') and the requirement that minute requires hour to be non-null. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Call once to register the user's birth date/time/gender' and clarifies that each call is a complete replacement of all six fields. This clearly distinguishes it from sibling tools like intentions_get_profile, which is used to fetch current values.
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 thorough guidance: it explains when to call, how to handle unknown fields by passing null, the complete replacement requirement, the procedure for updating a single field by merging with fetched profile, and the monthly limit on identity-changing edits. This leaves no ambiguity about usage.
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!
Sign in to create a connector for this server.