Weather & Climate Intelligence MCP
Server Details
Weather data, forecast API, climate data, historical weather, alerts, agricultural & travel weather.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 8 of 8 tools scored.
Each tool has a clearly distinct purpose: current_weather, forecast, historical_weather, climate_normals, agricultural_outlook, travel_conditions, weather_alerts, and mint_info cover different aspects of weather and climate without overlap.
All tool names follow a consistent snake_case pattern with descriptive, self-explanatory terms, e.g., current_weather, climate_normals, agricultural_outlook.
With 8 tools covering weather conditions, forecasts, history, normals, agriculture, travel, alerts, and additional blockchain info, the count is well-scoped for a comprehensive weather intelligence server.
The toolset covers current conditions, short-term and long-term forecasts, historical data, climate normals, agricultural insights, travel comparisons, and alerts, representing a complete lifecycle of weather-related queries.
Available Tools
9 toolsagricultural_outlookAInspect
Agricultural weather outlook — season-to-date growing degree days, frost risk over the next 14 days, soil moisture + soil temperature, 7-day precipitation outlook, and a planting-window assessment.
PAID: $0.01 USDC per query after the daily free allowance (50/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| latitude | Yes | decimal latitude. | |
| longitude | Yes | decimal longitude. | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the payment model (cost, free allowance, 402 handling) but lacks other behavioral traits such as data source, update frequency, or accuracy. The payment flow is adequately explained.
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, front-loaded with the tool's purpose, and includes essential payment details in a single paragraph. It could be slightly more structured, but no unnecessary sentences.
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 output schema exists, the description sufficiently covers purpose and payment. It lacks explicit usage context compared to siblings, but the tool is relatively simple with 4 parameters. Adequate for an agent to invoke 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%, so baseline is 3. The description adds context for agent_id (scopes free-tier counter) and payment_tx (used after 402), but latitude/longitude are standard. Overall, marginal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an 'Agricultural weather outlook' with specific metrics like growing degree days, frost risk, soil moisture, soil temperature, precipitation outlook, and planting-window assessment. It distinguishes from sibling tools (e.g., current_weather, forecast) by focusing on agriculture-specific 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 implies usage for agricultural planning but does not explicitly state when to use this tool versus alternatives like current_weather or forecast. Payment instructions are provided, but no guidance on when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
climate_normalsAInspect
Climate normals for a location — multi-decade monthly averages (high/low/ mean temp, precipitation), frost probabilities, average frost dates, and growing degree days. Derived from the Open-Meteo archive (set NOAA_CDO_TOKEN for official 30-year NOAA normals).
PAID: $0.01 USDC per query after the daily free allowance (50/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | optional month 1-12 to return just that month (else all 12). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| latitude | Yes | decimal latitude. | |
| longitude | Yes | decimal longitude. | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the data source (Open-Meteo archive) and mentions an optional NOAA token. It details the pay-per-use model and the 402 error flow. However, it does not mention other behavioral aspects like rate limits, idempotency, or if calls are destructive (likely not). Given no annotations, the description carries the burden but lacks completeness.
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 reasonably concise and structured into two paragraphs: one explaining the output and data source, another covering payment and authentication. It front-loads the purpose. Could trim minor details, but 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 output schema exists (context indicates yes) and the description covers the tool's purpose, data derivation, and payment flow, it is mostly complete. It does not explain the output format, but that is presumably covered by the output schema. The mention of the NOAA token is a helpful prerequisite.
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%, so the baseline is 3. The tool description does not add significant meaning beyond the schema's parameter descriptions. It mentions the payment flow but that is already implicit in the payment_tx parameter 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 it provides 'climate normals' as multi-decade monthly averages for temperature, precipitation, frost, and growing degree days. It distinguishes itself from sibling tools like 'current_weather', 'forecast', and 'historical_weather' by focusing on long-term averages, not real-time or short-term 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 explains what the tool does and includes payment handling instructions, but does not explicitly state when to use it versus alternatives or provide criteria for selecting this tool over siblings. The usage context is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
current_weatherAInspect
Current conditions for a location — temperature, feels-like, humidity, wind, conditions, cloud cover, and visibility. FREE. Give either latitude+longitude or a city (optionally with state/country).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | city name (geocoded), e.g. "Denver". | |
| state | No | optional state/region to disambiguate the city. | |
| country | No | optional country name or code to disambiguate the city. | |
| latitude | No | decimal latitude. | |
| longitude | No | decimal longitude. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool is free and lists output fields, but lacks details on error handling, rate limits, data freshness, or what happens if the location is invalid. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence delivers the core purpose and output, the second covers inputs and cost. Information is front-loaded and every word serves a function.
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 weather tool with 100% schema coverage and an output schema, the description is nearly complete. It covers what the tool does, what it returns, and how to specify the location. Minor omissions like data source or update frequency do not significantly hinder usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters into two alternative sets (lat/lon vs city+state+country) and stating the output fields, helping the agent understand parameter relationships and purpose beyond their individual 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 explicitly states it provides current weather conditions including temperature, feels-like, humidity, wind, cloud cover, and visibility. The verb 'current' and the listed fields make the purpose unambiguous, and it naturally distinguishes from siblings like forecast or historical_weather.
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 the two input alternatives (lat/lon or city with optional state/country), which is helpful. However, it does not provide explicit guidance on when to use this tool over siblings (e.g., 'for current conditions, not forecast') or when to avoid it (e.g., if data is unavailable).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daily_briefAInspect
The curated daily weather-intel brief — the day's most significant weather in one package: active severe NWS alerts, significant weather events of the last 24h, a 72-hour outlook for major US metros, and agricultural signals (growing-degree-days, frost risk, soil, precipitation). Each brief carries a MINT provenance attestation so a buyer can verify it was produced by this server, unaltered.
PAID: $5 USDC per brief. Defaults to today (UTC); a brief expires at the next midnight UTC. On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | brief date YYYY-MM-DD (default today, UTC). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description covers key behaviors: paid ($5 USDC), expiration at midnight UTC, provenance attestation, payment flow with re-call. It would benefit from mentioning any rate limits or free-tier counters, but agent_id is noted.
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 with two main sentences and a separate payment paragraph. It is well-structured, front-loads key content, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (paid, multiple content types, payment flow) and the presence of an output schema, the description is complete. It covers what the brief contains, payment mechanics, expiry, and verification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema: explains date defaults and expiration, agent_id scopes free counter, payment_tx use after 402. Enhances understanding of each parameter's role.
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 a curated daily weather-intel brief with specific components (severe alerts, significant events, 72-hour outlook, agricultural signals). It distinguishes itself from sibling tools by listing unique content and the paid nature.
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?
Describes when to use the tool (for a daily briefing) and provides detailed payment instructions including handling 402 errors. Does not explicitly mention alternatives among siblings, but the context of a daily brief is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forecastAInspect
Weather forecast — up to 16-day daily outlook (high/low, conditions, precipitation probability, wind) plus the next 48 hours hourly. Cheap enough to call constantly.
PAID: $0.005 USDC per query after a generous daily free allowance (50/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. agent_id scopes your allowance; an Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | forecast days (1-16, default 7). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| latitude | Yes | decimal latitude. | |
| longitude | Yes | decimal longitude. | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses payment flow, 402 error handling, free allowance scoping via agent_id, and authentication bypass. This adds significant behavioral context beyond the input schema.
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 relatively concise, covering key information in two blocks. It could be slightly more structured, but it is efficient with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of payment handling and daily free allowance, the description covers essential behavioral and usage aspects. The presence of an output schema reduces the need to explain return values.
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 for each parameter. The description adds payment_tx handling details but does not significantly enhance parameter semantics beyond what schema already provides. Baseline 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 it provides weather forecasts up to 16 days daily and next 48 hours hourly, with specific details on what is included. This definitively sets it apart from siblings like current_weather or historical_weather.
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 mentions it is 'Cheap enough to call constantly' and explains payment handling, but does not explicitly contrast with when to use siblings like current_weather. It provides good context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
historical_weatherAInspect
Historical daily weather for a date range — high/low/mean temperature, precipitation, and max wind per day (global, from the Open-Meteo archive).
PAID: $0.01 USDC per query after the daily free allowance (50/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | Yes | ISO date "YYYY-MM-DD". | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| latitude | Yes | decimal latitude. | |
| date_from | Yes | ISO date "YYYY-MM-DD". | |
| longitude | Yes | decimal longitude. | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses pricing model, payment flow on 402, auth bypass, and agent scoping. Does not mention potential limitations like date range constraints or rate limits, but covers the key behavioral traits beyond basic functionality.
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: first sentence succinctly states purpose and data content; second sentence explains the payment model. No wasted words, front-loaded with primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (pricing, payment handling, auth, agent tracking) and existence of output schema, the description covers the essential behavioral aspects. Could mention date range limits or data availability, but overall it is fairly complete and useful for an 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?
Schema coverage is 100%, so baseline is 3. Description adds value for payment_tx and agent_id by explaining the payment flow and free-tier scoping. For latitude/longitude and dates, it adds no new info beyond schema, but the added context justifies a score above baseline.
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 historical daily weather data for a date range with specific metrics (high/low/mean temp, precipitation, max wind), and is sourced from Open-Meteo archive. The verb is implied (retrieve) and distinguishes from siblings like current_weather or 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?
Provides important usage context: pricing ($0.01 after 50 free/day), how to handle 402 error with payment_tx, and auth bypass option. Also mentions agent_id for free-tier scoping. Does not explicitly compare with siblings for when to use this tool, but the purpose itself implies use for historical data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_infoAInspect
FoundryNet Data Network info + MINT Protocol details. FREE.
Returns how to attest your agent's weather/climate analysis with MINT Protocol for verifiable on-chain proof, the MINT MCP endpoint, and the sister data servers (gov-contracts, brand-intel, patent-intel, financial-signals).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses it is FREE and lists returned data. It does not mention side effects or limitations, but as a read-only info tool, this is sufficient.
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: first boldly states purpose and 'FREE', second lists outputs. No wasted words, front-loaded with essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description covers all necessary context: what the tool does and what it returns, within the domain of weather/climate analysis.
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 schema coverage is 100%. The description adds value by detailing the output content beyond the schema, which 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 it returns FoundryNet Data Network info and MINT Protocol details, and enumerates specific outputs (attestation method, endpoint, sister servers). It distinguishes from sibling weather data tools unequivocally.
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 implies use for obtaining network/protocol info to attest weather analysis, but does not explicitly state when not to use or name alternatives. However, context with sibling tools makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
travel_conditionsAInspect
Weather comparison between two locations for trip planning — origin vs. destination forecast, the temp/precip deltas, active destination advisories, and structured packing recommendations (not prose).
PAID: $0.01 USDC per query after the daily free allowance (50/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | optional ISO date "YYYY-MM-DD" within the next 7 days (else today). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| dest_lat | Yes | ||
| dest_lon | Yes | ||
| origin_lat | Yes | ||
| origin_lon | Yes | ||
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses payment model ($0.01 USDC per query after 50/day free), 402 error handling (pay Solana memo and retry with payment_tx), and authorization bypass (Bearer fnet_ key). No annotations provided, so description carries full burden and does so well.
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 with two clear sections: functional purpose and payment details. Every sentence serves a purpose. Front-loaded with primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core usage, payment loop, and hints at output structure (structured, not prose). Output schema exists, so agent can infer return format. Lacks coordinate range or timezone details but overall sufficient given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning beyond schema: explains lat/lon as origin/destination, date as optional within 7 days, and payment_tx as retry parameter. Schema covers only 43% of parameters, but description compensates by explaining purpose and workflow, though coordinate bounds are not mentioned.
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 'Weather comparison between two locations for trip planning' and lists specific outputs: origin vs. destination forecast, temp/precip deltas, advisories, and structured packing recommendations. This distinguishes it from siblings like 'current_weather' or 'forecast' which focus on single locations.
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 purpose implies usage for trip planning comparing two locations, distinguishing from single-location tools. However, it does not explicitly state when not to use (e.g., for a single location) or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
weather_alertsAInspect
Active NWS severe-weather alerts (US). FREE — public safety. Query by state code, by latitude+longitude (point), or with no args for nationwide.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | 2-letter US state code, e.g. "TX". | |
| latitude | No | decimal latitude (point query). | |
| longitude | No | decimal longitude (point query). | |
| radius_km | No | reserved (point query uses the NWS point lookup). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool is free and for public safety, but does not mention rate limits, response size, or update frequency. The behavioral traits are adequately implied but not fully detailed.
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 entire description is a single concise sentence that is front-loaded with essential information. Every element serves a purpose with no superfluous wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and four optional parameters, the description sufficiently covers what the tool does and how to use it. No critical information is missing for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by summarizing query patterns (state, point, nationwide) and clarifying radius_km is reserved, providing context beyond the schema 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 active NWS severe-weather alerts for the US, specifying query methods (by state, lat/lon, or nationwide). This distinctly distinguishes it from sibling tools like forecast or current_weather.
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 outlines when to use the tool (for severe alerts) and how to query, but does not explicitly mention alternatives or when not to use it. The sibling tools are listed, but no comparative guidance is given.
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!