Intentions MCP Server
Server Details
Personalized timing intelligence for AI agents — ask 'should I do X on this date?'
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.8/5 across 7 of 7 tools scored.
Each tool targets a distinct time granularity (day, hour, month, year) or purpose (chart, profile management), with no ambiguity between them. Descriptions explicitly reference when to use alternative tools.
All tools follow a consistent 'intentions_verb_noun' snake_case pattern (e.g., intentions_ask_day, intentions_set_birth_info), making the set predictable and easy to navigate.
With 7 tools, the set covers the core functionality (queries at various granularities, visual chart, profile management) without being oversized or sparse for the stated purpose.
The tool surface covers all major query types (day, hour, month, year), visual output, and profile CRUD. Minor gap: no explicit tool for deleting a profile, but set_birth_info can effectively nullify fields.
Available Tools
7 toolsintentions_ask_dayARead-onlyInspect
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. 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to repeat that. It adds valuable behavioral details: the tool returns a score (0-100), verdict, per-layer breakdowns, and adverse alerts. It also describes three modes (single date, compare up to 5, scan a range). This 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?
The description is concise and well-structured. It opens with a clear purpose statement, provides examples, lists modes in a bullet-like fashion, describes the return structure, and ends with sibling tool guidance. Every sentence is necessary and well-placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return structure sufficiently. It covers all parameters and their interactions, includes constraints (max 31 days, max 5 dates), references sibling tools for broader context, and mentions the category enum's role in weighting. The description leaves no significant gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds value by explaining how parameters map to usage modes (targetDate for single, compareDates for comparison, dateRange for scanning). It also clarifies defaults (targetDate defaults to today) and limits (max 31 days for range, max 4 additional dates for comparison).
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: answering 'when to X' questions for a specific date or best day from a multi-day window. It provides concrete examples (trip dates, launch days, etc.) and explicitly distinguishes from sibling tools like intentions_ask_month and intentions_ask_hour.
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 ('when the user asks about timing a decision for a specific date') and gives examples. It also tells when not to use it by directing users to intentions_ask_month for multi-month windows and intentions_ask_hour for 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_hourARead-onlyInspect
Call 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds substantial behavioral details: Pro subscription requirement, free-tier error handling, hour mapping (0..23 to 2-hour block midpoint, rollover at 23:00-23:59), output window format, and return contents (score, verdict, adverse alerts). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. Every sentence adds value (examples, subscription, modes, hour mapping, output notes). Slightly verbose but not wasteful; could be more streamlined but effective.
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 absence of an output schema, the description covers return values (score, verdict, adverse alerts, window span) and mentions citing the window. It explains all modes and parameter interactions. Missing systematic return structure, but sufficient for correct 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?
Schema coverage is 100% (baseline 3), but the description adds important meaning beyond schema: explains the hour rounding behavior, the rollover at 23:00-23:59, and the window span in bestInDay. This compensates with actionable detail, justifying 4.
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: determining the best hour to act within a specific day. It provides concrete examples (e.g., 'best time today to X') and distinguishes from sibling tools by mentioning alternatives like intentions_ask_day for day-level analysis and intentions_energy_chart for visual overview.
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 timing within a specific day') and provides use cases. Notes subscription requirement and error handling on free tier, including suggestions for alternate tools. Describes three modes (single, compare, scan all) without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
intentions_ask_monthARead-onlyInspect
Call 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: returns month score, element breakdown, adverse alerts; describes modes (single month, compare up to 5, scan up to 12 returning top 5). No contradictions 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?
Concise but dense: front-loaded with key purpose and use cases, then breaks into modes and return value details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers when to use, all modes, return values, sibling differentiation, and parameter behavior. No output schema, but description sufficiently explains what to expect.
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?
Adds meaning beyond schema: category tunes weighting, monthRange inclusive, compareMonths max 4 additional, targetMonth defaults to current month. With 100% schema coverage, description still enriches understanding.
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 granularity queries, specifying use cases like trip-month selection, launch months, and content-calendar planning. It distinguishes from siblings by mentioning day and hour precision alternatives.
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?
Explicit guidance on when to use: when user asks at month granularity or wants best month from multi-month window. Explicit when not to use: for day precision near 4th–6th use 'intentions_ask_day' and 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_yearARead-onlyInspect
Call 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return types (year-level score, verdict, adverse alerts, element dimensions) and the valid window, adding behavioral context beyond the readOnlyHint annotation. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with the first sentence front-loading the purpose and examples. Every sentence adds value, and there is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations and full schema coverage, the description adequately covers the tool's behavior, return types, and distinctions from siblings. No output schema exists, but the description mentions what is returned, making it 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?
The input schema has 100% description coverage, so the schema already documents each parameter. The description does not add additional meaning beyond the schema, so the baseline score 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: answering queries about a full calendar year as a whole. It provides examples of user inputs and explicitly distinguishes from siblings (intentions_ask_month, intentions_ask_day), making the purpose 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 description explicitly tells when to use this tool ('when the user asks about a full calendar year') and when not to ('For month precision use intentions_ask_month; for day use intentions_ask_day'). It also notes the valid window constraint, providing complete usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
intentions_energy_chartARead-onlyInspect
Call 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond readOnlyHint and openWorldHint: hourly mode is Pro-gated and returns subscription_required error, with alternative suggestions. No contradictions 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?
Every sentence is purposeful, front-loaded with usage scenario, and the structure guides the agent efficiently. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: purpose, chart meanings, gating, alternatives, parameter defaults, and return type (ASCII chart). No output schema needed; description fully compensates.
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 description adds extra meaning: hourly = 12 two-hour blocks, weekly = 7 days, yearly = 12 months; and clarifies default date. Exceeds baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool is for visual overviews rather than narrative answers, with examples like 'show me this week', and distinguishes from sibling tools by specifying chart types (hourly, weekly, yearly).
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 clear when-to-use scenarios, and for the Pro-gated hourly mode suggests alternatives (weekly/yearly or intentions_ask_day), aiding proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
intentions_get_profileARead-onlyInspect
Fetch 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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the return structure including fields and null handling, and mentions 'No quota cost', adding value beyond the readOnlyHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each providing essential 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?
Given no parameters and no output schema, the description sufficiently explains return type, structure, and usage context with sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Baseline 4 for zero parameters, no additional info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and resource 'birth info', and distinguishes from sibling 'intentions_set_birth_info' by specifying it is for reading before updating.
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 tool before 'intentions_set_birth_info' when updating an existing profile, providing clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
intentions_set_birth_infoAIdempotentInspect
Call 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses complete replacement behavior, rate limits (3 per month for critical edits vs. free for adding precision), and return value. Annotations (idempotentHint=true, destructiveHint=false) are consistent and the description adds useful context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four focused sentences with no fluff. The first sentence states purpose, the second covers null handling, the third explains update workflow, and the fourth adds rate limit details. Well-structured 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?
Covers all essential aspects: what the tool does, how to use it (including null handling and partial updates), constraints (rate limits), output (element profile), and references sibling tools. Complete for a mutation tool with 6 required 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 coverage is 100%, and the description adds context about null usage, the constraint that minute requires hour non-null, and the complete replacement requirement. It enhances understanding of 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 it registers the user's birth date/time/gender, with a specific verb ('register') and resource ('birth info'). It distinguishes from sibling tools like intentions_ask_day which focus on individual fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: call once for full registration, pass null for unknown fields, use intentions_get_profile for partial updates, and limits on identity-changing edits. It also clarifies the update procedure and rate limits.
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.
Discussions
No comments yet. Be the first to start the discussion!