noaa-spaceweather-mcp-server
Server Details
NOAA SWPC space weather: storm scales, Kp index, aurora forecasts, solar wind, activity, alerts.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/noaa-spaceweather-mcp-server
- GitHub Stars
- 1
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.5/5 across 6 of 6 tools scored.
Each tool targets a distinct aspect of space weather (alerts, aurora, conditions, Kp index, solar activity, solar wind). The descriptions clearly differentiate their purposes and even suggest when to use which tool, minimizing overlap.
All tool names follow the consistent pattern `noaa_spaceweather_get_<resource>`, using snake_case and a clear verb-noun structure. There are no deviations or mixed conventions.
With 6 tools, the server is well-scoped for a specialized domain. Each tool provides a necessary piece of information without bloat, and the number is sufficient to cover the main space weather data categories.
The tool set covers the primary space weather data: alerts, aurora forecasts, current conditions, Kp index, solar activity (flares, radiation), and solar wind. It is missing a dedicated geomagnetic storm forecast tool, but the Kp index and conditions tools cover the immediate needs. Overall, the surface is near-complete for its domain.
Available Tools
6 toolsnoaa_spaceweather_get_alertsGet Space Weather AlertsARead-onlyIdempotentInspect
Active SWPC alerts, watches, and warnings — parsed into structured records with product type, NOAA scale and level, issue time, validity window, and plain text. Covers geomagnetic storms, radio blackouts, and radiation storms. With active_only=false, also returns informational summaries, expired notices, and cancellations. max_age_hours controls how far back to look (default 48 h); the SWPC feed keeps all historical records and has no built-in expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | No | When true (default), return only in-force Warnings, Watches, and Alerts; exclude Summaries, Other, expired products, and cancellation notices. Set false to return all products, including cancellations (flagged by the cancelled field). | |
| max_age_hours | No | Maximum age of alerts to return, in hours (default 48). The SWPC feed retains all historical records — this window prevents returning weeks of historical notices as "active." |
Output Schema
| Name | Required | Description |
|---|---|---|
| alerts | Yes | Matching SWPC alert/watch/warning records. |
| notice | No | Status notice when no alerts are active. |
| fetchedAt | Yes | ISO 8601 timestamp of when this data was fetched. |
| totalCount | Yes | Count of records in the alerts array. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. The description adds valuable context: the SWPC feed retains all historical records with no built-in expiry, and max_age_hours controls the lookback window. 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?
Three sentences with clear front-loading of the core purpose. Every sentence provides essential information without redundancy. Efficient 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?
For a tool with 2 optional parameters and an output schema, the description covers behavior, parameter rationale, and data types sufficiently. No gaps given the presence of output schema (return values not required).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters documented). The description reinforces parameter meaning by explaining the rationale for max_age_hours (preventing weeks of historical notices) and the effect of active_only. This adds 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 returns 'Active SWPC alerts, watches, and warnings' and specifies what it covers (geomagnetic storms, radio blackouts, radiation storms). It distinguishes itself from sibling tools like get_aurora_forecast or get_kp_index by focusing on alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains behavior for active_only=true/false and mentions max_age_hours. While it doesn't explicitly state when to use this tool vs alternatives, the context signals (sibling tool names) and clear purpose make the usage context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_spaceweather_get_aurora_forecastGet Aurora ForecastARead-onlyIdempotentInspect
OVATION model aurora forecast for the next ~30–60 min: global grid of aurora probability percentages by latitude/longitude (1° resolution). With optional coordinates, returns the local aurora probability at the nearest grid point, the minimum Kp needed for aurora at that latitude, and a plain-language go/no-go verdict. Without coordinates, returns only global metadata. Data updates every ~5 minutes. Coordinates are geographic (WGS84), not geomagnetic.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | No | Geographic latitude in degrees (−90 to 90). Provide with longitude for a local aurora probability lookup. | |
| longitude | No | Geographic longitude in degrees (−180 to 180). Provide with latitude for a local aurora probability lookup. |
Output Schema
| Name | Required | Description |
|---|---|---|
| localLookup | Yes | Local aurora lookup result. Null when no coordinates were provided. |
| forecastTime | Yes | Time the aurora forecast is valid for, ISO 8601. |
| gridPointCount | Yes | Total number of grid points in the OVATION model. |
| observationTime | Yes | Time of the OVATION model observation, ISO 8601. |
| topAuroraRegion | Yes | Approximate region of the highest aurora probability grid point. |
| topAuroraPercent | Yes | Highest aurora probability anywhere on the globe (0–100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, open-world, idempotent. Description adds useful behavioral context: update frequency (~5 min), coordinate system (WGS84 geographic not geomagnetic), resolution (1° grid), and output behavior based on coordinates. 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?
Four sentences, front-loaded with main purpose, no unnecessary words. Each sentence adds essential information about behavior, modes, and data freshness.
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 tool has 2 optional params and output schema, description fully covers modes of operation, data source, update frequency, and coordinate system. No missing critical details for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. Description adds value by clarifying coordinate system (WGS84) and explaining that providing coordinates triggers local probability lookup with additional outputs like Kp needed and go/no-go verdict.
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 it provides OVATION model aurora forecast for next 30-60 min with global grid of probability percentages. Distinguishes between local lookup with coordinates vs global metadata without. Differentiates from sibling tools (alerts, conditions, etc.) by focusing on aurora forecast.
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 each mode: provide coordinates for local probability, omit for global metadata. Mentions data updates every 5 minutes. Does not explicitly say when not to use, but sibling context provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_spaceweather_get_conditionsGet Space Weather ConditionsARead-onlyIdempotentInspect
Current space-weather snapshot: NOAA R/S/G storm scales (today + 3-day forecast), latest Kp index with its G-scale equivalent and aurora-visibility latitude, and a plain-language status summary. The quickest way to answer "is anything happening right now?" — use before deciding whether to drill into solar wind (noaa_spaceweather_get_solar_wind), aurora (noaa_spaceweather_get_aurora_forecast), or alert details (noaa_spaceweather_get_alerts).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| today | Yes | Current observed NOAA storm scales for today. |
| summary | Yes | Plain-language status summary suitable for display, e.g. "Quiet conditions" or "G2 moderate geomagnetic storm in progress." |
| forecast | Yes | 3-day NOAA scale forecast (next 1–3 days). |
| currentKp | Yes | Latest observed planetary K-index (0–9). |
| observedAt | Yes | UTC date and time of the NOAA scales data period this snapshot reflects, e.g. "2026-06-04 15:00:00". |
| currentGScale | Yes | NOAA G-scale equivalent for current Kp (0–5). |
| auroraLatitude | Yes | Aurora visibility guidance for current conditions, e.g. "Aurora possible to ~55° geomagnetic latitude". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds useful behavioral context: includes forecasts, plain-language summary, and that it's a snapshot. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences concisely communicate purpose, content, and usage guidance. No redundant or irrelevant 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?
Tool has zero parameters and an output schema, so description need not explain return values. It fully covers what the tool does and when to use it, making it complete for an AI agent.
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, so description correctly does not add parameter info. Baseline of 4 is appropriate as schema coverage is 100% and no parameter documentation is 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?
Description clearly states it provides a 'current space-weather snapshot' with specific data elements (R/S/G scales, Kp index, aurora latitude) and explicitly distinguishes from sibling tools by naming them and their 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?
Explicitly states it is 'the quickest way to answer "is anything happening right now?"' and advises to 'use before deciding whether to drill into' sibling tools like solar wind, aurora forecast, and alerts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_spaceweather_get_kp_indexGet Kp IndexARead-onlyIdempotentInspect
Planetary K-index (0–9 geomagnetic activity scale) — recent observed 3-hour values with their NOAA G-scale equivalents and aurora-latitude guidance, plus the 3-day Kp forecast series. Kp is the primary driver of aurora visibility and geomagnetic storm severity: Kp≥5 is G1, Kp≥7 is G3 (aurora to ~50°), Kp≥9 is G5 extreme. Use noaa_spaceweather_get_conditions for a combined snapshot including storm scales; use this tool when you need the Kp time series or forecast detail.
| Name | Required | Description | Default |
|---|---|---|---|
| window_days | No | Number of past days of observed Kp to return (1–7, default 1). Larger windows show trend context. |
Output Schema
| Name | Required | Description |
|---|---|---|
| forecast | Yes | Forward-looking Kp forecast series (estimated and predicted entries only; observed history excluded). |
| observed | Yes | Observed Kp readings within the requested window, oldest first. |
| currentKp | Yes | Latest observed Kp value. |
| currentGScale | Yes | NOAA G-scale for current Kp. |
| observedCount | Yes | Number of Kp observations in the observed array, matching the requested window. |
| auroraLatitude | Yes | Aurora visibility guidance for current conditions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds valuable behavioral context: explaining the Kp scale and its relationship to G-storms and aurora visibility, which helps the agent understand the tool's output 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?
The description is only two sentences, front-loading the key information about what the tool returns and then providing usage guidance. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the essential aspects: output content, scale interpretation, usage guidance. It could mention the forecast timescale, but overall it's 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% for the single parameter window_days, which already describes its purpose. The description does not add significant extra meaning beyond the schema, so 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 returns the Planetary K-index with observed 3-hour values, G-scale equivalents, aurora-latitude guidance, and 3-day forecast. It explicitly distinguishes from sibling tool noaa_spaceweather_get_conditions by specifying when to use each.
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: 'Use noaa_spaceweather_get_conditions for a combined snapshot...; use this tool when you need the Kp time series or forecast detail.' This clearly tells the agent when to use this tool vs the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_spaceweather_get_solar_activityGet Solar ActivityARead-onlyIdempotentInspect
Solar flare and radiation storm picture: recent GOES X-ray flux with flare-class labels (A/B/C/M/X), 3-day flare-class probabilities (C/M/X), active solar regions with per-region flare probabilities, and GOES integral proton flux at ≥10 MeV with NOAA S-scale. For operators tracking HF radio blackout (R-scale, driven by X-ray) and radiation storm risk (S-scale, driven by protons). Active region data helps identify which region is driving current activity.
| Name | Required | Description | Default |
|---|---|---|---|
| include_regions | No | Include active solar region details (default true). Set false to skip region data and reduce response size. |
Output Schema
| Name | Required | Description |
|---|---|---|
| sScale | Yes | Current NOAA S-scale for solar radiation storms (0–5), derived from latest proton flux. |
| fetchedAt | Yes | ISO 8601 timestamp of when this data was fetched. |
| latestXray | Yes | Most recent GOES X-ray flux reading, null if unavailable. |
| recentXray | Yes | GOES X-ray flux readings from the past hour, oldest first. |
| sScaleText | Yes | Plain-language S-scale description, e.g. "S2 moderate radiation storm". |
| latestProton | Yes | Most recent ≥10 MeV proton flux reading, null if unavailable. |
| activeRegions | Yes | Currently active solar regions with per-region flare probabilities. Empty when include_regions=false or no regions are active. |
| probabilities | Yes | 3-day flare probability forecasts. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. Description adds value by detailing the data components (X-ray flux, flare classes, proton flux, active regions) and the scales (R-scale, S-scale), which helps the agent understand the tool's behavioral scope without repeating 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 at three sentences, front-loading the main output and use case. Each sentence adds relevant information; no wasted words, though it could be slightly tighter.
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 of solar activity data and the presence of an output schema, the description covers the key elements: flare and radiation storm metrics, active regions, and the operator use case. It is sufficient for an agent to understand what the tool offers.
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% for the single parameter include_regions, and its description in the schema is already clear. The tool description does not add extra meaning beyond what the schema provides, so it meets the 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?
Description clearly states the tool provides a 'solar flare and radiation storm picture' including specific data like GOES X-ray flux, flare probabilities, active regions, and proton flux. The verb 'get' and resource 'solar activity' are specific, and it distinguishes from siblings (e.g., no other tool mentions flare or proton data).
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?
Description explicitly targets 'operators tracking HF radio blackout and radiation storm risk,' providing clear context of use. It does not explicitly state when not to use or name alternatives, but sibling tools offer contrasting options (e.g., aurora forecast, KP index), implying situational differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_spaceweather_get_solar_windGet Solar WindARead-onlyIdempotentInspect
Real-time solar wind measurements from the active spacecraft at L1: proton speed (km/s), density (n/cm³), temperature (K), and the critical Bz component (southward Bz = negative = storm driver). Returns the recent plasma and magnetic field time series within the requested window, oldest first, each record tagged with the reporting spacecraft. Bz < −10 nT for sustained periods is a primary geomagnetic storm trigger — use alongside noaa_spaceweather_get_kp_index to see whether elevated solar wind has translated into a geomagnetic storm.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | Hours of recent solar wind history to return (1–168, default 3). Records update ~every 1 min, but the feed only carries roughly the last 24 hours — a larger window returns the whole feed, not more history. When a window comes back empty, feedStalenessHours and latestFeedPlasmaTime/latestFeedMagTime report how current the feed actually is. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mag | Yes | Magnetic field measurements (Bx, By, Bz, Bt) within the window, oldest first. |
| notice | No | Guidance when the requested window returned no plasma or magnetic field records — names the newest record the feed carries, or reports that the feed itself returned nothing from an active spacecraft. |
| plasma | Yes | Plasma measurements (speed, density, temperature) within the window, oldest first. |
| bzStatus | Yes | Plain-language Bz status, e.g. "Southward Bz −14 nT — storm-driving conditions" or "Northward Bz +5 nT — quiescent". |
| magCount | Yes | Number of magnetic field records in the mag array, spanning the requested window. |
| latestMag | Yes | Most recent magnetic field reading, null if no data in window. |
| plasmaCount | Yes | Number of plasma records in the plasma array, spanning the requested window. |
| latestPlasma | Yes | Most recent plasma reading, null if no data in window. |
| latestFeedMagTime | Yes | ISO 8601 time of the newest magnetic field record the feed carries, ignoring the window. Null when the feed returned no active-spacecraft mag records. |
| feedStalenessHours | Yes | Hours between now and the newest record across both feeds — how far behind real time the upstream data is. Null when both feeds returned no active-spacecraft records. |
| latestFeedPlasmaTime | Yes | ISO 8601 time of the newest plasma record the feed carries, ignoring the window. Null when the feed returned no active-spacecraft plasma records. Compare against the window to tell a quiet feed from a stale one. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, which the description does not contradict. The description adds significant behavioral context: returns time series oldest first, records tagged with spacecraft, feed update frequency (every ~1 min), feed window limitation (last 24 hours), and the significance of Bz < -10 nT as a storm trigger. This goes well 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 moderately sized (4 sentences), well-structured, and front-loaded with key measurements. Every sentence adds value, though the trigger sentence could be seen as additional context rather than essential. Overall 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 input schema fully covers the single parameter, annotations provide behavioral hints, an output schema exists (so return values are explained externally), and the description explains usage triggers and feed behavior, the tool definition is complete and well-rounded for an AI agent.
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?
Input schema has 100% coverage for the single parameter window_hours, already described. The description adds extra semantic value: explains that larger windows return the whole feed rather than more history, that records update every ~1 min, and provides guidance on handling empty windows via staleness fields. This enriches the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves real-time solar wind measurements from L1, listing specific parameters (proton speed, density, temperature, Bz). It distinguishes itself from siblings by focusing on plasma and magnetic field data, and is not a tautology.
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 suggests using alongside noaa_spaceweather_get_kp_index to assess whether elevated solar wind has translated into a geomagnetic storm. It provides clear context but does not state when not to use this tool, though the pairing recommendation is strong.
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!