Skip to main content
Glama
BACH-AI-Tools

Weather API167 MCP Server

by BACH-AI-Tools
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Weather Api167 MCP Server

English | 简体中文 | 繁體中文

🚀 使用 EMCP 平台快速体验

EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！

快速开始：

  1. 🌐 访问 EMCP 平台

  2. 📝 注册并登录账号

  3. 🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器

  4. 🔍 搜索或找到本服务器（bach-weather_api167）

  5. 🎉 点击 "安装 MCP" 按钮

  6. ✅ 完成！即可在您的应用中使用

EMCP 平台优势：

  • ✨ 零配置：无需手动编辑配置文件

  • 🎨 可视化管理：图形界面轻松管理所有 MCP 服务器

  • 🔐 安全可靠：统一管理 API 密钥和认证信息

  • 🚀 一键安装：MCP 广场提供丰富的服务器选择

  • 📊 使用统计：实时查看服务调用情况

立即访问 EMCP 平台 开始您的 MCP 之旅！

Related MCP server: OpenWeatherMap MCP Server

简介

这是一个 MCP 服务器，用于访问 Weather Api167 API。

  • PyPI 包名: bach-weather_api167

  • 版本: 2.0.0

  • 传输协议: stdio

安装

从 PyPI 安装:

pip install bach-weather_api167

从源码安装:

pip install -e .

运行

方式 1: 使用 uvx（推荐，无需安装）

# 运行（uvx 会自动安装并运行）
uvx --from bach-weather_api167 bach_weather_api167

# 或指定版本
uvx --from bach-weather_api167@latest bach_weather_api167

方式 2: 直接运行（开发模式）

python server.py

方式 3: 安装后作为命令运行

# 安装
pip install bach-weather_api167

# 运行（命令名使用下划线）
bach_weather_api167

配置

API 认证

此 API 需要认证。请设置环境变量:

export API_KEY="your_api_key_here"

环境变量

变量名

说明

必需

API_KEY

API 密钥

是

PORT

不适用

否

HOST

不适用

否

在 Claude Desktop 中使用

编辑 Claude Desktop 配置文件 claude_desktop_config.json:

{
  "mcpServers": {
    "weather_api167": {
      "command": "uvx",
      "args": ["--from", "bach-weather_api167", "bach_weather_api167"],
      "env": {
        "API_KEY": "your_api_key_here"
      }
    }
  }
}

注意: 请将 E:\path\to\weather_api167\server.py 替换为实际的服务器文件路径。

可用工具

此服务器提供以下工具:

forecast_weather

Fetch forecast weather data using coordinate value, place name or zip code

端点: GET /api/weather/forecast

参数:

  • lon (string): Longitude coordinate(Note. lat and lon value has priority over both place and zip value). use the lat and lon for more accurate and reliable weather data

  • lat (string): Latitude coordinate(Note. lat and lon value has priority over both place and zip value). use the lat and lon for more accurate and reliable weather data

  • place (string): City name, state code (only for the US) and country code divided by comma like Zion,VA,US . Please use ISO 3166 country codes. Note. place value has priority over zip value

  • zip (string): Zip code with optional country code(Note. Zip value will only be used if both lat,lon and place name not provided)

  • cnt (string): Number of timestamps to retrieve (up to a maximum allowed by the API)

  • units (string): Unit type (standard, metric, and imperial)

  • type (string): Forcast Type

  • mode (string): Mode type

  • lang (string): Language type

country_info

Return detail for given country

端点: GET /api/weather/country/detail

参数:

  • country (string): Example value: United Kingdom

us_weather_alert_data

US weather alert daily information for given region or area and other filtering parameter

端点: GET /api/weather/us/alert

参数:

  • status (string): use comm(,) to separate multiple value

  • message_type (string): Example value: alert,update,cancel

  • area (string): example AM,AN

  • region (string): Example value: AL,AT

  • zone (string): Example>> OKZ929

  • region_type (string): Example>> marine,land This value can't be used in combination with area or region

  • urgency (string): Example value: Immediate,Expected

  • severity (string): Example value: Extreme,Severe,Moderate

  • certainty (string): Example value: Observed,Likely,Possible,Unlikely,Unknown

  • limit (string): Example value: 500

us_zone_list

Zone list for US given state or All Zone list if state not given

端点: GET /api/weather/us/zone

参数:

  • state (string): Example value: WY

earthquake_data

Near real time earthquake for given country

端点: GET /api/weather/earthquake

参数:

  • country (string): Example value: US

  • startDate (string): Example value:

  • endDate (string): Example value:

current_weather

Fetch current weather data using coordinate value, place name or zip code

端点: GET /api/weather/current

参数:

  • lon (string): Longitude coordinate(Note. lat and lon value has priority over both place and zip value). use the lat and lon for more accurate and reliable weather data

  • lat (string): Latitude coordinate(Note. lat and lon value has priority over both place and zip value). use the lat and lon for more accurate and reliable weather data

  • place (string): City name, state code (only for the US) and country code divided by comma use like Zion,VA,US . Please use ISO 3166 country codes. Note. place value has priority over zip value

  • zip (string): Zip code with optional country code(Note. Zip value will only be used if both lat,lon and place name not provided)

  • units (string): Unit type (standard, metric, and imperial)

  • lang (string): Language type

  • mode (string): Mode type

air_pollution_data

Fetch air pollution data using coordinate value, place name or zip code

端点: GET /api/weather/air_pollution

参数:

  • lat (string): Latitude coordinate(Note. lat and lon value has priority over both place and zip value). use the lat and lon for more accurate and reliable weather data

  • lon (string): Longitude coordinate(Note. lat and lon value has priority over both place and zip value). use the lat and lon for more accurate and reliable weather data

  • place (string): City name, state code (only for the US) and country code divided by comma like Zion,VA,US . Please use ISO 3166 country codes Note. place value has priority over zip value

  • zip (string): Zip code with optional country code(Note. Zip value will only be used if both lat,lon and place name not provided)

  • type (string): Data for air pulltion type

技术栈

  • 传输协议: stdio

  • HTTP 客户端: httpx

开发

此服务器由 API-to-MCP 工具自动生成。

版本: 2.0.0

Available Tools

7 tools
air_pollution_dataC

Fetch air pollution data using coordinate value, place name or zip code

ParametersJSON Schema
NameRequiredDescriptionDefault
latNoLatitude coordinate(Note. lat and lon value has priority over both place and zip value). use the lat and lon for more accurate and reliable weather data0
lonNoLongitude coordinate(Note. lat and lon value has priority over both place and zip value). use the lat and lon for more accurate and reliable weather data0
placeNoCity name, state code (only for the US) and country code divided by comma like Zion,VA,US . Please use ISO 3166 country codes Note. place value has priority over zip value
zipNoZip code with optional country code(Note. Zip value will only be used if both lat,lon and place name not provided)
typeNoData for air pulltion type

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It states 'Fetch' but lacks details on data freshness, rate limits, or whether it returns current or historical data. Without output schema, agent must guess response format.

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?

Single sentence, no redundant information. Efficiently conveys the core action and input types without filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 optional parameters, no output schema, and zero annotations, the description is too sparse. Agent lacks information about required fields, data structure, or error handling. Incomplete for practical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions explaining parameter priority. The description adds minimal value ('using coordinate value, place name or zip code') but does not improve on schema detail. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Fetch' and resource 'air pollution data', and specifies three input methods (coordinate, place, zip). While it doesn't explicitly differentiate from siblings like 'current_weather', the tool name and resource are distinct enough for an agent to infer purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Description does not specify scenarios (e.g., checking air quality vs. weather) or exclusions. Agent must rely solely on tool name and sibling names, which is insufficient for confident selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

country_infoC

Return detail for given country

ParametersJSON Schema
NameRequiredDescriptionDefault
countryNoExample value: United Kingdom

TDQS

C2.9/5.0
Behavior2/5

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 does not disclose any behavioral traits such as rate limits, authentication, or what 'detail' entails (e.g., population, capital).

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 a single sentence with no unnecessary words, achieving maximum conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and minimal parameter info, the description is too brief to fully specify the tool's functionality. It omits what 'detail' includes and any constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with one parameter having an example. The description adds no extra meaning beyond the schema; it does not clarify valid values or the effect of omitting the optional parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Return detail for given country', which clearly indicates the verb (return) and resource (detail for a country). It is distinct from sibling tools that focus on weather and pollution data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It provides no context for when it is appropriate or when to avoid it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

current_weatherA

Fetch current weather data using coordinate value, place name or zip code

ParametersJSON Schema
NameRequiredDescriptionDefault
lonNoLongitude coordinate(Note. lat and lon value has priority over both place and zip value). use the lat and lon for more accurate and reliable weather data0
latNoLatitude coordinate(Note. lat and lon value has priority over both place and zip value). use the lat and lon for more accurate and reliable weather data0
placeNoCity name, state code (only for the US) and country code divided by comma use like Zion,VA,US . Please use ISO 3166 country codes. Note. place value has priority over zip value
zipNoZip code with optional country code(Note. Zip value will only be used if both lat,lon and place name not provided)
unitsNoUnit type (standard, metric, and imperial)
langNoLanguage type
modeNoMode type

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It fails to mention data freshness, rate limits, authentication, or response format. The tool's behavior beyond fetching is opaque, limiting transparency.

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 a single, clear sentence of 12 words that directly states the tool's action and inputs. Every word contributes meaning, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 7 parameters and no output schema, the description should explain what data is returned (e.g., temperature, humidity) and clarify behavior for missing inputs. It only mentions location methods, leaving significant gaps for an agent to understand the tool fully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 reiterates the three location methods but adds no new meaning beyond the schema's detailed parameter descriptions. There is no benefit or penalty beyond baseline.

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 fetches 'current weather data' using specific location methods (coordinate, place, zip). This distinguishes it from sibling tools like 'forecast_weather' and 'air_pollution_data', providing a clear purpose.

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 outlines three location input methods but does not explicitly state when to prefer this tool over siblings. However, the sibling names (e.g., 'forecast_weather', 'air_pollution_data') imply differentiation, and the schema elaborates on parameter priority.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

earthquake_dataC

Near real time earthquake for given country

ParametersJSON Schema
NameRequiredDescriptionDefault
countryNoExample value: US
startDateNoExample value:
endDateNoExample value:

TDQS

C2.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description does not disclose any behavioral traits such as data freshness, rate limits, or what occurs when no data matches. Without annotations, the description provides no information about side effects or operational characteristics beyond the basic purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but it is underspecified. It could benefit from clarifying the result type without adding significant length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a data retrieval tool with three parameters and no output schema, the description fails to explain what the response contains (e.g., list of events, details). The absence of information about required fields (none marked required) further reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage but parameter descriptions are minimal (e.g., 'Example value: US' for country). The tool description adds no additional context about expected formats (e.g., date format) or how parameters affect the query, leaving the agent to infer usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it provides 'near real time earthquake for given country', which indicates the domain but lacks a specific verb (e.g., retrieve, list). It is clear it is earthquake data and distinguishes from sibling weather and pollution tools, but the exact nature of the result (list vs. single event) is ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives like forecast_weather or current_weather. There is no mention of prerequisites, limitations, or conditions under which the tool should or should not be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

forecast_weatherB

Fetch forecast weather data using coordinate value, place name or zip code

ParametersJSON Schema
NameRequiredDescriptionDefault
lonNoLongitude coordinate(Note. lat and lon value has priority over both place and zip value). use the lat and lon for more accurate and reliable weather data0
latNoLatitude coordinate(Note. lat and lon value has priority over both place and zip value). use the lat and lon for more accurate and reliable weather data0
placeNoCity name, state code (only for the US) and country code divided by comma like Zion,VA,US . Please use ISO 3166 country codes. Note. place value has priority over zip value
zipNoZip code with optional country code(Note. Zip value will only be used if both lat,lon and place name not provided)
cntNoNumber of timestamps to retrieve (up to a maximum allowed by the API)
unitsNoUnit type (standard, metric, and imperial)
typeNoForcast Type
modeNoMode type
langNoLanguage type

TDQS

B3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must disclose behaviors. It only says 'fetch', implying a read operation, but omits details like auth needs, rate limits, data freshness, or that coordinates have priority. Minimal transparency.

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 a single sentence of 13 words – concise and front-loaded with the core purpose. No extraneous wording, but it could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 9 parameters, no required fields, and no output schema, the description is insufficient. It doesn't explain return format, cnt limit, units meanings, or what type/mode/lang do. Users would lack essential context.

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 coverage is 100%, but the description adds value by explaining priority rules (lat/lon over place over zip) and that lat/lon are more accurate. This complements the schema descriptions, though other parameters like type, mode, lang lack additional context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool fetches forecast weather data using coordinates, place name, or zip code. It clearly identifies the resource (forecast weather) and how to specify location, though it doesn't explicitly differentiate from sibling tools like current_weather.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like current_weather or earthquake_data. There are no scenarios or prerequisites mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

us_weather_alert_dataC

US weather alert daily information for given region or area and other filtering parameter

ParametersJSON Schema
NameRequiredDescriptionDefault
statusNouse comm(,) to separate multiple value
message_typeNoExample value: alert,update,cancel
areaNoexample AM,AN
regionNoExample value: AL,AT
zoneNoExample>> OKZ929
region_typeNoExample>> marine,land This value can't be used in combination with area or region
urgencyNoExample value: Immediate,Expected
severityNoExample value: Extreme,Severe,Moderate
certaintyNoExample value: Observed,Likely,Possible,Unlikely,Unknown
limitNoExample value: 500

TDQS

C2.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description must carry the behavioral burden. It fails to disclose traits like data freshness, whether it's read-only, pagination, or what happens with no parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence, but it is vague and poorly structured ('for given region or area and other filtering parameter'). Could be more precise and front-loaded with the action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, yet the description does not explain return format or structure. With 10 optional parameters and no required ones, lacks guidance on valid combinations or defaults.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% but descriptions are minimal (e.g., examples only). The tool description adds no parameter info beyond the schema, missing meanings for codes like 'AM' or 'AL'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it provides 'US weather alert daily information' for a region/area, which identifies the resource but lacks a specific verb (e.g., 'retrieve', 'list'). It does not differentiate from siblings like current_weather or forecast_weather.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description only implies general usage for a given region/area, with no exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

us_zone_listA

Zone list for US given state or All Zone list if state not given

ParametersJSON Schema
NameRequiredDescriptionDefault
stateNoExample value: WY

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses the main behavior (filtered or all zones list) but is minimal. No mention of authentication, rate limits, or zone format. Adequate but could add detail.

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?

Single sentence, front-loaded with key info, no superfluous words. Efficient and clear.

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 low complexity (one optional parameter, no output schema), the description covers main usage. Could define what 'zone' means for clarity, but overall sufficient.

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?

The description adds meaning beyond the schema: explains that state is optional and filters the list, while omitting returns all zones. Schema already has example value, but description clarifies the conditional logic.

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?

Description clearly states the tool provides a zone list for a US state, or all zones if no state is given. The verb 'list' and resource 'zone' are explicit, and it distinguishes from sibling tools like weather or earthquake data.

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 tells when to use the tool (for US zone list) and how the state parameter affects output. No explicit alternatives or when-not-to-use, but sibling tools are in different domains so no confusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 7 tool updatesv2.0.2
    • First observedair_pollution_data
    • First observedcountry_info
    • First observedcurrent_weather
    • First observedearthquake_data
    • First observedforecast_weather
    • First observedus_weather_alert_data
    • First observedus_zone_list
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

All tools have distinct purposes: current weather, forecast, air pollution, earthquakes, US alerts, US zone list, and country info. No overlapping functionality that would confuse an agent.

Naming Consistency5/5

All tool names follow snake_case and a consistent pattern of descriptor_noun (e.g., current_weather, air_pollution_data, us_zone_list). No mixing of conventions.

Tool Count5/5

Seven tools is a reasonable scope for a weather API server, covering core weather data, forecasts, air pollution, earthquakes, and US-specific alerts without being overwhelming or too sparse.

Completeness3/5

The set covers basic weather, forecast, air pollution, earthquakes, and US alerts, but misses historical weather, global severe warnings, and non-US alerts. These are notable but not critical gaps for a basic weather server.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/BACH-AI-Tools/weather_api167'

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