stormscope

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.4.5
Disambiguation5/5
Each tool targets a distinct weather data type (alerts, conditions, forecast, radar, etc.) with no overlap. The get_briefing tool is a composite but clearly documented as a summary tool, avoiding confusion.
Naming Consistency5/5
All tool names follow the consistent pattern 'get_<noun>', making it easy to predict the function from the name. No mixing of conventions or irregular verbs.
Tool Count5/5
9 tools is well-scoped for a comprehensive weather server, covering all major aspects (alerts, conditions, forecast, radar, severe weather outlooks, surface analysis, upper air) without being overwhelming.
Completeness4/5
The tool set covers the core weather domain thoroughly. Minor gaps exist (e.g., marine forecasts, climate data) but are beyond the stated scope. The briefing tool effectively fills the need for an overview.
Average 4.6/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It details detail levels, unit formats, and default coordinate behavior. It does not mention safety traits (e.g., read-only) but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-organized: clear sections for purpose, use cases, detail levels, and units. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (not shown), return values are covered. The description covers all input parameters and default behaviors. Minor omission: no mention of location validation or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning: explains detail enum values, unit override syntax, and lat/lon optionality. However, it does not clarify valid ranges for lat/lon (only US locations implied by name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states "Get current weather conditions for a US location," matching the tool name and resource. It distinguishes from siblings by focusing on real-time conditions, not alerts, forecasts, or radar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides example queries under "Use when:" and explains detail levels and units. However, it does not explicitly state when to avoid using the tool or point to specific sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: categorical vs probabilistic output, day parameter range, units accepted but no effect. It does not cover error handling or rate limits, but for a read-only tool, the behavioral traits are sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (~100 words) and well-structured: purpose first, then usage triggers, then parameter details. Each sentence provides essential information without redundancy. Front-loaded key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no required, no enums, and an output schema, the description covers all necessary usage aspects and output types. It does not detail error cases or API limits, but the output schema likely documents return values, making the description sufficient for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate fully. It explains all five parameters: latitude/longitude optional (default primary location), outlook_type values with output details, day meaning, units accepted but irrelevant. This adds critical meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check SPC severe weather outlook for a US location.' It provides specific verb+resource ('Check SPC severe weather outlook') and differentiates from siblings like get_national_outlook by focusing on SPC outlook with examples like 'Severe weather risk?' and 'Storm outlook?'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage cues with example questions ('Severe weather risk?', 'Storm outlook?') and explains when to use different outlook types. It mentions omitting lat/lon for primary location but does not explicitly state when not to use or compare with siblings, though the context of sibling tools is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully covers behavior: it explains parameter effects (severity_filter values, detail levels, lat/lon default behavior, units being ignored), and notes that alert text comes from NWS as-is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with a clear opening line, usage hints, and parameter explanations. It is slightly verbose but each sentence adds value, and structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values need not be detailed. The description covers all parameters, usage, and behavioral nuances. Minor missing details (e.g., error handling) but overall complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain each parameter. It does so comprehensively: severity_filter lists valid values, detail explains two levels, lat/lon omission uses primary location, and units is documented as non-functional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('active weather alerts for a US location'), making the purpose unambiguous. It also includes example queries and filter options, reinforcing understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool ('Use proactively at conversation start') and example triggers. It does not directly mention when not to use or contrast with siblings, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It transparently describes the combination of data sources, the two detail levels, units format with examples, and primary location fallback. No side effects or auth needs implied, which is consistent with a read-only briefing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured, starting with purpose then block of details. Slightly long but each sentence adds value. Could be tightened, but not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and an existing output schema, the description covers inputs, behavior, usage guidelines, and parameter semantics thoroughly. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds rich meaning: explains 'detail' parameter options ('standard' vs 'full' with specific inclusions), units format with examples and allowed fields, and lat/lon omission behavior. None of this is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a comprehensive weather briefing for a US location' and distinguishes itself from sibling tools by positioning as the default for 'What's the weather?', combining conditions, forecast, alerts, and SPC outlook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use as default and details for 'standard' vs 'full' detail levels. Mentions omitting lat/lon for primary location. Does not explicitly state when not to use or suggest specific sibling alternatives, but context signals provide sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: explains modes (daily, hourly, raw), default settings, units system, and that main temperature/wind are always in Fahrenheit/mph due to NWS data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose and use cases, but somewhat long. Every sentence adds value, so slight deduction for verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no required fields, multiple modes, and units system, description covers all aspects. Output schema exists, so output format not needed. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description compensates by explaining each parameter: lat/lon optional, modes, days/hours ranges, and detailed unit overrides. Adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets a forecast for US locations, uses specific verb and resource. Differentiates from sibling tools like get_conditions and get_alerts by specifying 'forecast'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides example queries for when to use ('What's the forecast?', 'Will it rain?'). Does not explicitly state when not to use or compare to alternatives, but context signals imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains that the tool returns risk areas with human-readable region descriptions and that no lat/lon is needed. It does not explicitly state it is a read-only operation, but the nature is implied. The description is transparent about the output but could be slightly more explicit about non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using line breaks and bullet-like formatting. Every sentence adds value without repetition. It is front-loaded with the core purpose and usage examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, when to use it, parameter details, and output characteristics ('returns all active risk areas with human-readable region descriptions'). However, it does not specify how many risk areas to expect or update frequency. With an existing output schema (not shown), this is acceptable, but the description alone is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains both parameters: 'day: 1=today, 2=tomorrow, 3=day after' and 'units: accepted for API consistency but does not affect outlook output'. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'CONUS-wide SPC severe weather risk areas'. It includes usage examples ('Any severe weather in the US?', 'National storm outlook?') and implicitly differentiates from sibling tools like get_spc_outlook by specifying national coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' examples are provided, making it clear when to invoke this tool. The description also clarifies that the 'units' parameter is accepted for API consistency but does not affect the output, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: imagery-based, unitless, returns summary and links, omitting lat/lon uses configurable location, units parameter does not affect output. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with key purpose, then usage, then details. Every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete given output schema existence and sibling context. Covers purpose, usage, behavior, parameters, and output nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description explains that lat/lon are optional (use configured location) and units is accepted but does nothing. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets NEXRAD radar info with textual summary and links. Differentiates from sibling weather tools like get_alerts or get_forecast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases like 'Show me radar' and notes textual summary is useful when images can't be displayed. Lacks explicit exclusion criteria but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of disclosure. It details the return structure (12-hour time series, height in dam, temperature, wind, relative/absolute vorticity in 10^-5 s^-1), explains the underlying model (global GFS via Open-Meteo) and grid spacing (~110km), and clarifies that it's not region-restricted. There are no contradictions or omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear introduction, usage cues, scientific context, and parameter details. It uses bullet-like formatting and line breaks for readability. However, it is relatively long; some sentences could be merged or trimmed without losing value, justifying a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an upper-air forecast tool with 3 parameters and an output schema (not shown), the description covers all necessary aspects: purpose, usage scenarios, scientific background, parameter behavior, and output details. It distinguishes itself from siblings like get_surface_analysis and get_spc_outlook, and the presence of an output schema reduces the need to describe return format further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains all three parameters: latitude and longitude can be omitted for a default location, and units are described in depth with examples ('us' or 'si' with field overrides like 'pressure:mb,wind:kt'). This adds significant meaning beyond the schema's basic types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get 500mb upper-air forecast with heights, temperature, wind, and vorticity.' It specifies the resource (500mb upper-air forecast) and the verb (get), and the inclusion of derived quantities like vorticity distinguishes it from siblings like get_surface_analysis or get_forecast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when:' phrases like 'What does 500mb look like?' and 'Where are the troughs?', giving clear contextual cues. It also advises omitting lat/lon for default location and notes it is not US-only. However, it does not explicitly state when not to use or provide alternatives to this tool, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: returns distance/bearing to fronts and pressure centers, update frequency (every 3 hours for analysis), CONUS-only coverage, and approximate warm/cold sector detection. It provides adequate transparency, though it could mention any rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and bullet points. Every sentence adds value, and the most important information (purpose, what it returns) is front-loaded. No trivial or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 optional parameters, output schema, no annotations), the description is exceptionally complete. It covers all parameters, provides usage examples, discloses limitations (CONUS, approximate detection, data source), and includes example queries. It fully compensates for the lack of annotations and schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all 7 parameters. It details product (analysis vs forecast, day usage), detail (standard vs full), scope (local vs all with 400km threshold), units (with field overrides), and lat/lon (optional, defaults to primary). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves surface analysis or forecast showing fronts, pressure centers, and warm/cold sectors. It provides specific verb-resource pairs like 'Get surface analysis' and 'Returns distance and bearing,' and distinguishes it from sibling tools like get_conditions and get_forecast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'Use when:' section with example queries, explains when to use 'analysis' vs 'forecast' and 'local' vs 'all' scope, and explicitly states what is not included (mesoscale boundaries). It gives clear guidance on when to invoke this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![stormscope MCP server](https://glama.ai/mcp/servers/thornjad/stormscope/badges/card.svg)](https://glama.ai/mcp/servers/thornjad/stormscope)

Score Badge

Copy to your README.md:

[![stormscope MCP server](https://glama.ai/mcp/servers/thornjad/stormscope/badges/score.svg)](https://glama.ai/mcp/servers/thornjad/stormscope)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/thornjad/stormscope'

If you have feedback or need assistance with the MCP directory API, please join our Discord server