NOAA SWPC space weather: storm scales, Kp index, aurora forecasts, solar wind, activity, alerts.
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 6 of 6 tools scored.
Each tool covers a distinct data domain (alerts, aurora, conditions, Kp index, solar activity, solar wind). Conditions and kp_index both include Kp values, but the descriptions clearly differentiate a snapshot from a time series, so confusion is unlikely.
All tools follow the exact same 'noaa_spaceweather_get_<noun>' pattern with consistent snake_case and descriptive nouns. There is no mixing of verb styles or casing conventions.
Six tools is well-scoped for a space weather data server, covering the major NOAA SWPC products without unnecessary redundancy or bloat.
The tool set covers the full operational space weather picture: alerts, conditions snapshot, Kp index, solar wind, solar activity, and aurora forecast. These form a coherent and mutually-reinforcing set with no obvious dead ends.
noaa_spaceweather_get_alertsGet Space Weather AlertsAActive 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." |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds important context: the SWPC feed retains all historical records and has no built-in expiry, which affects interpretation of max_age_hours. It also explains that active_only=false returns additional product types. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of four short sentences. It is front-loaded with the core purpose and each subsequent sentence adds relevant detail about scope, output format, or parameter behavior. There is no filler or 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?
With an output schema present and annotations covering safety, the description thoroughly covers the tool's scope, categories, parameter semantics, and feed behavior. It is sufficient for an agent to select and invoke the tool appropriately, especially given the simple two-parameter interface.
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 comprehensively documents both parameters, including defaults, behavior, and constraints. The description essentially restates the schema content for max_age_hours and active_only, adding no new meaning beyond what the schema already provides. Since schema coverage is 100%, 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 function: retrieving active SWPC alerts, watches, and warnings, parsed into structured records with specific fields. It distinguishes itself from sibling tools by focusing on alerts (geomagnetic storms, radio blackouts, radiation storms) rather than forecasts or indices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (for alerts on geomagnetic, radio, and radiation events) and explains parameter behavior, but it does not explicitly reference sibling tools or state when not to use this tool. The scope is clear, but alternatives are not named.
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 ForecastAOVATION 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. |
| 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior, but the description adds valuable context: data updates every ~5 minutes, coordinates are geographic (WGS84) not geomagnetic, and the behavior difference with/without coordinates. 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 concise: three sentences, each packed with essential information. It front-loads the main purpose and avoids redundant phrasing, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with optional parameters, the description fully explains the two operational modes, data update frequency, coordinate system, and return behavior. The output schema exists, so no need to detail return values. This is a complete, self-contained description.
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 has 100% coverage for both parameters, and the description enhances this by explaining that providing coordinates triggers a local lookup at the nearest grid point, while omitting them returns only global metadata. This adds behavioral meaning beyond the schema's individual parameter descriptions.
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 provides an OVATION model aurora forecast for the next 30-60 minutes, with a global grid of probability percentages. It distinguishes itself from siblings by focusing specifically on aurora forecast, and details what the output includes.
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 two usage modes: with coordinates returns local probability, Kp threshold, and verdict; without coordinates returns only global metadata. This is clear context, though it does not explicitly compare to sibling tools or state when not to use this tool.
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 ConditionsACurrent 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 | |||
| 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". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds valuable behavioral context: it returns a snapshot with today's and 3-day forecast, includes a plain-language summary, and provides a recommended usage flow. 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 two sentences with no wasted words. It front-loads the core output, then adds usage guidance and sibling comparisons. Every phrase 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?
For a simple, read-only, zero-parameter tool with rich annotations and an output schema, the description fully covers what to expect and when to use it. It also references sibling tools for further context, making the tool's role in the overall spaceweather suite clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no burden to explain parameters. Baseline for 0-param tools is 4, and the description appropriately focuses on output content and usage context instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Current space-weather snapshot' and then enumerates exact data elements (NOAA R/S/G storm scales, 3-day forecast, Kp index, G-scale equivalent, aurora-visibility latitude, status summary). It clearly distinguishes itself from siblings by positioning as the quickest 'is anything happening right now?' tool and names specific sibling tools to drill into.
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 explicitly tells the agent when to use this tool: 'use before deciding whether to drill into' alternative tools. It also names the alternatives (solar wind, aurora, alerts), giving clear decision context and exclusions for deeper dives.
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 IndexAPlanetary 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds meaningful interpretive context beyond annotations, explaining the Kp scale, storm severity thresholds (e.g., Kp≥5 is G1), and aurora-latitude implications. This helps the agent understand the data's significance without conflicting 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, front-loaded with the core definition, followed by interpretive thresholds and usage guidance. Every sentence adds value, with no redundancy or filler. It is appropriately sized for the tool's simplicity and effectively 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 one optional parameter, no required parameters, and an existing output schema, the description is complete. It explains what data is returned (observed values, forecast), provides context on interpreting Kp, and gives usage alternatives. The output schema covers return structure, so the description need not repeat it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% for the single parameter window_days, with a clear explanation of its range and default. The description itself does not add parameter details, but the schema fully documents semantics. Per the rubric, a baseline of 3 is appropriate when schema coverage is high.
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 the Planetary K-index with recent observed 3-hour values, G-scale equivalents, aurora-latitude guidance, and a 3-day forecast series. It uses a specific verb (get) and resource (Kp index), and explicitly distinguishes from sibling get_conditions by noting the Kp time series and forecast detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: '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.' This directly addresses when to use this tool versus an alternative, satisfying the when/when-not criterion.
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 ActivityASolar 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent, and the description adds valuable context: temporal scope ('recent', '3-day'), the relationship between X-ray and R-scale / protons and S-scale, and interpretive guidance on active regions. This goes beyond the annotations to explain what the data means.
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, each earning its place: first lists the data components, second states the operational use case, third highlights the value of active region data. Efficient, dense, 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?
With an output schema present and a simple single-parameter input, the description covers the data types, temporal scope, and operational significance. It provides a complete picture for a read-only retrieval tool without over-explaining the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter (include_regions) with 100% coverage, so the description does not need to add anything. The description's mention of active regions indirectly relates to the parameter, but the schema description is sufficient. Baseline 3 applies.
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 provides solar flare and radiation storm data including GOES X-ray flux, flare classes, probabilities, active regions, and proton flux. It distinguishes itself from sibling tools (alerts, aurora, kp_index, etc.) by specifying its unique content and operational relevance.
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 identifies target users ('operators tracking HF radio blackout and radiation storm risk') and ties the data to specific scales (R-scale, S-scale), providing clear context for when to use. It does not explicitly compare to alternatives, but the intended use case is unambiguous.
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 WindAReal-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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already declaring read-only and idempotent behavior, the description adds important behavioral nuances: the 24-hour feed limit, the fact that larger windows return the whole feed rather than more history, the ~1 minute update interval, and the availability of staleness fields when a window is empty. This goes beyond the annotations and helps the agent understand data freshness and edge cases.
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 compact, with three sentences that efficiently convey the tool's output, storm-significance, and feed limitations. It does repeat some feed-limit information already present in the schema, but overall every sentence earns its place without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, a rich schema description, and an output schema available, the description covers the essential aspects: what data is returned, ordering, spacecraft tagging, storm relevance, and how to interpret empty windows. It sufficiently orients the agent without needing to explain return values, as the output schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter window_hours is fully documented in the input schema, including range, default, feed constraints, and behavior when empty. The description itself does not add parameter semantics beyond the schema, so the baseline of 3 applies given the high schema coverage.
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 identifies the tool as returning real-time solar wind measurements from L1, listing specific variables (proton speed, density, temperature, Bz) and the response format (time series, oldest first, tagged with spacecraft). It differentiates from sibling weather tools by focusing on solar wind plasma and magnetic field 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?
The description explicitly recommends using this tool alongside noaa_spaceweather_get_kp_index to determine whether elevated solar wind has translated into a geomagnetic storm, providing clear context on when to interpret the data. It implies the primary use case is monitoring storm triggers via Bz, though it does not explicitly state when not to use this tool; still, the guidance is actionable.
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.