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.3/5 across 9 of 9 tools scored. Lowest: 3.4/5.
Each tool targets a distinct weather or climate use case: current conditions, forecasts, historical data, agricultural outlook, climate normals, travel comparison, alerts, and a daily brief. The only potential overlap is between forecast and daily_brief, but daily_brief is a curated summary package, so tools are clearly distinguishable.
All tool names follow a consistent snake_case pattern with a descriptive prefix (e.g., agricultural_outlook, current_weather, weather_alerts). There is no mixing of conventions, making the naming predictable and easy to understand.
With 9 tools, the server strikes a good balance—neither sparse nor overwhelming. Each tool covers a specific aspect of weather intelligence (current, forecast, historical, alerts, travel, agriculture, normals, brief, and an info tool), fitting the domain well.
The tool surface covers core weather operations (current, forecast, historical, alerts) plus specialized domains (agriculture, travel, normals, daily brief). Minor gaps exist (e.g., no dedicated marine or air quality tool), but for general weather intelligence, it is largely complete.
Available Tools
11 toolsagricultural_outlookAInspect
Get the agricultural weather outlook for a location from Open-Meteo — 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?
The description discloses behavioral traits including the payment model, error handling (402), and authentication bypass. It also lists the kinds of data returned. No annotations are provided, so the description carries full burden and does so thoroughly.
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 clearly separated paragraphs: one for purpose, one for payment handling. Every sentence adds value, and critical information is front-loaded.
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 agricultural data and payment model, the description is complete. It covers what the tool does, how to use it, payment details, and error recovery. The output schema existence is noted in context, and the description doesn't need to 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?
Schema coverage is 100% and the description adds meaning beyond the schema: it explains agent_id's role in scoping free-tier usage and payment_tx's function for re-calling after a 402. Latitude and longitude are standard but clearly implied.
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 an agricultural weather outlook for a location, listing specific data points like growing degree days, frost risk, soil moisture, precipitation outlook, and planting-window assessment. This distinguishes it from sibling tools like current_weather or forecast, which are more general.
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 includes payment guidelines (free allowance, cost per query, how to handle 402 errors with payment_tx, and bypass with Authorization header). However, it does not explicitly contrast usage with sibling tools or specify when to choose this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brief_summaryAInspect
Get the top 5 signals from today's brief as structured JSON — a cheap sample of the full daily_brief. Returns the day's highest-priority items (no prose) so an agent can decide whether to buy the full brief.
PAID: $0.50 USDC (vs the full daily_brief price). Defaults to today (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?
With no annotations, the description fully discloses the tool's paid nature, pricing, default behavior, error handling, and authentication, providing complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with three clear sentences covering purpose, output, and pricing/payment flow, containing no unnecessary words.
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?
It adequately covers the tool's functionality, return format, pricing, error recovery, and default behavior, making it self-contained for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds useful context: date defaults to UTC, agent_id scopes free-tier counter, and payment_tx is for re-call after a 402, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the top 5 signals from today's brief as structured JSON, distinguishing it from the full daily_brief by being a cheaper sample.
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 explains when to use this tool (to decide whether to buy the full brief) and provides payment handling instructions, including 402 error recovery and auth bypass with a Bearer key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
climate_normalsAInspect
Get climate normals for a location — multi-decade monthly climate data averages (high/low/mean temp, precipitation), frost probabilities, average frost dates, and growing degree days. 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?
No annotations provided, so description carries full burden. It discloses payment structure, 402 handling, auth bypass, and data source options. While it does not explicitly state read-only nature, the context implies retrieval only.
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 two concise paragraphs, front-loaded with purpose. Every sentence serves utility with no filler.
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 5 parameters, no annotations, and existence of output schema, the description covers purpose, data sources, payment, authorization, and free allowance. It leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value for payment_tx and agent_id parameters by explaining their role in payment and free-tier scoping. Other parameters are adequately described in 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 retrieves climate normals (multi-decade monthly averages) and lists specific data types (temp, precipitation, frost, etc.). It distinguishes from sibling tools like current_weather and forecast by emphasizing 'multi-decade' and 'averages'.
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 gives clear context for use (long-term climate data) but does not explicitly compare to siblings or state when not to use. However, the specificity implies appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
current_weatherBInspect
Get current weather for a location from Open-Meteo — 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?
No annotations are provided, so the description must carry full behavioral transparency. It mentions the data source (Open-Meteo) and lists returned fields, but does not disclose data freshness, rate limits, or any reliability characteristics.
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 extremely concise with two sentences. The first sentence conveys purpose and output, the second gives usage modes. Every sentence adds value with no wasted words.
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 (return values not needed in description), the description satisfactorily covers what the tool does and how to use it. It lacks depth on data freshness or contrasts with siblings, but is adequate for most selection scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already documents all parameters. The description adds value by clarifying the two usage modes (city with optional state/country, or lat/lon), but this is largely redundant with 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 gets current weather for a location and lists the data fields (temperature, feels-like, humidity, etc.). It distinguishes from siblings like forecast and historical_weather by specifying 'current', but does not explicitly contrast with them.
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 basic usage guidance: 'Give either latitude+longitude or a city (optionally with state/country).' and notes the service is free. However, it does not provide when to use this tool versus alternatives like forecast or weather_alerts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daily_briefAInspect
Get the curated daily weather-intel brief — the day's most significant weather in one package, from NOAA/NWS and Open-Meteo. Includes active severe NWS weather alerts, significant weather events of the last 24h, a 72-hour forecast outlook for major US metros, and agricultural weather 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 (x402 rail). | |
| stripe_token | No | Stripe Checkout Session id (cs_…), when re-calling after paying the Stripe payment link (alternative to x402). Can also be supplied via the X-Stripe-Token header. |
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 fully discloses behavioral traits: it is a paid tool ($5 USDC), brief expires at midnight UTC, payment flow on 402 errors, and an authorization bypass. This provides complete transparency for an agent to handle payment and understand cost implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the main purpose first, followed by contents, payment details, and re-call instructions. While it is relatively long, every sentence adds necessary information, and it is not verbose. Minor restructuring could improve skimmability.
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, the description adequately covers purpose, payment, and basic usage. It could be more specific about geographic scope ('major US metros') and the definition of 'significant weather events', but overall it provides sufficient context for an agent to decide to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for all 4 parameters. The tool description adds value by explaining the payment_tx parameter in the context of the 402 payment flow and the agent_id's role in free-tier scoping, beyond what the schema provides.
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 a 'curated daily weather-intel brief' and enumerates its components (severe alerts, events, forecast, agricultural signals). This distinguishes it from sibling tools which provide individual weather data elements, making its unique value proposition explicit.
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 implicitly conveys when to use this tool (when a comprehensive daily summary is needed) by listing what it includes. However, it does not explicitly exclude alternatives or direct to siblings for specific needs, though the context of sibling names provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forecastAInspect
Forecast weather for a location from Open-Meteo — 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?
With no annotations, the description fully discloses behavioral traits: cost per query, free daily allowance (50/day), 402 error handling with Solana memos, retry mechanism with payment_tx, agent_id scoping, and auth bypass. It also explains the data provided. The only minor gap is no mention of response format, but output schema compensates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with core functionality, then cost details, then error handling. Every sentence adds value; no redundant text. Could be slightly shorter but maintains clarity.
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 (5 params, payment, error handling, output schema exists), the description covers the essential aspects: function, cost, free tier, error recovery, and auth. Minor gaps include not specifying units or timezones, but output schema likely covers these. Overall sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining agent_id scopes the free-tier counter and payment_tx is used for retrying after a 402, which is not in the schema descriptions. This enhances agent understanding beyond the schema properties.
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 forecasts weather for a location, specifying the scope: up to 16-day daily outlook (high/low, conditions, precipitation probability, wind) plus next 48 hours hourly. It uses a specific verb ('forecast') and resource ('weather'), distinguishing it 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 suggests the tool is cheap enough to call constantly but does not provide explicit guidance on when to use this tool over alternatives (e.g., for short-term vs long-term forecasts, or vs other weather tools). There are no 'when not to use' or sibling comparisons, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
historical_weatherAInspect
Get historical weather for a location and date range from the Open-Meteo archive — daily high/low/mean temperature, precipitation, and max wind per day (global climate data).
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, the description fully carries the burden. It discloses the paid nature, daily free limit, and precise re-call protocol on 402. This gives agents clear expected behavior beyond a simple read operation.
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 extremely concise: two short paragraphs. The first sentence states core functionality, the second adds payment details. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (mentioned in context), the description does not need to detail return values. It already specifies the data fields (temp, precip, wind) and covers the critical payment edge case, making it complete for the tool's 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?
Schema coverage is 100% and all parameters are already well-described in the schema (type, format, purpose). The description does not add new semantic meaning to parameters beyond what the schema provides, so 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 uses a specific verb ('Get') and resource ('historical weather') and explicitly states the data returned (daily high/low/mean temperature, precipitation, max wind). It clearly differentiates from siblings like current_weather and 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?
The description provides clear when-to-use context (historical data from Open-Meteo archive) and detailed payment/error handling instructions (free allowance, 402 payment flow, Authorization header bypass). It does not explicitly state when not to use but siblings imply alternatives.
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.
supply_chain_riskAInspect
Score weather risk along a supply-chain / shipping route (0-100) with the specific threats at each endpoint and a shipment recommendation. Combines current conditions and active NWS severe-weather alerts at both the origin and destination into a single transport-risk score.
PAID: $0.02 USDC per call 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 |
|---|---|---|---|
| origin | Yes | origin city (e.g. "Memphis, TN") or "lat,lon". | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| ship_date | No | optional planned ship date (YYYY-MM-DD), echoed in the result. | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| destination | Yes | destination city or "lat,lon". |
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 paid usage, cost ($0.02 USDC per call), free allowance (50/day), 402 retry logic with payment_tx, and optional Authorization header. It does not mention rate limits or data retention.
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, front-loading the main purpose first, then providing payment details in a separate paragraph. Each sentence adds unique information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output (0-100 score, specific threats, shipment recommendation) and covers payment edge cases. Since output schema exists, it does not need to detail return structure further. Sibling tools are provided for context.
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 baseline is 3. Description adds value by explaining payment_tx usage (re-call after 402) and origin/destination format (city or lat,lon). It does not clarify agent_id or ship_date beyond schema defaults.
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 scores weather risk along a supply chain route (0-100) by combining current conditions and NWS alerts at origin and destination. It uses specific verbs and resources, and distinguishes from siblings like current_weather and weather_alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains payment and 402 handling but does not explicitly guide when to use this tool versus alternatives. It implies use for shipping route risk but lacks explicit when-not-to-use or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
travel_conditionsAInspect
Compare weather between two locations for trip planning, using Open-Meteo forecast and NWS alerts — origin vs. destination forecast, 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?
With no annotations, the description fully discloses data sources (Open-Meteo, NWS), cost structure, free allowance, and payment retry flow. It also notes output is structured (not prose). This is thorough, though it omits rate limits or error handling beyond 402.
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 concise paragraphs: first covers purpose and output, second covers cost/payment flow. No wasted words, front-loaded with the core 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?
Given 7 parameters and an output schema (not shown), the description covers the essential behavioral and payment context. It references output structure and data sources, making it sufficient for the tool's 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?
Schema description coverage is 43% (3 of 7 params described). The description adds context for payment_tx and clarifies coordinate roles (origin vs destination), but does not provide units, ranges, or format constraints beyond what the schema already offers.
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 compares weather between two locations for trip planning, specifying origin vs destination forecast, temp/precip deltas, advisories, and packing recommendations. This distinguishes it from sibling tools like weather_alerts 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?
The description explicitly states the use case (trip planning comparing two locations) and provides context on cost and payment retry. It does not explicitly exclude other uses, but the sibling list implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
weather_alertsAInspect
Check active severe-weather alerts from NOAA/NWS (US). FREE — public safety. Query by state code, by latitude+longitude (point), or with no args for nationwide weather alerts.
| 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?
The description effectively discloses the tool's free nature, data source, and query options. However, it does not mention parameter interaction (e.g., mutual exclusivity), rate limits, or data freshness. The presence of an output schema partially compensates.
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 a single, front-loaded sentence that conveys all key information without unnecessary words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple alert retrieval tool, the description covers the main query modes and data source. With an output schema present, details about return format are less critical. Minor omissions like 'active' definition or pagination are acceptable.
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 description adds semantic grouping of parameters (state, lat/long, no args) beyond the schema, clarifying they are alternative query modes. Since schema coverage is 100%, the baseline is 3, and the extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks active severe-weather alerts from NOAA/NWS, specifies the geographic scope (US), and outlines query methods. This 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 implies when to use it (for severe weather alerts) but does not provide explicit guidance on when not to use it or compare it with sibling tools. The agent must infer usage from context.
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!