Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Weatherapi Com MCP Server what's the current weather in Tokyo?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
用于访问 Weatherapi Com API 的 MCP 服务器。
EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！
🌐 访问 EMCP 平台
📝 注册并登录账号
🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器
🔍 搜索或找到本服务器（bach-weatherapi_com）
🎉 点击 "安装 MCP" 按钮
✅ 完成！即可在您的应用中使用
✨ 零配置：无需手动编辑配置文件
🎨 可视化管理：图形界面轻松管理所有 MCP 服务器
🔐 安全可靠：统一管理 API 密钥和认证信息
🚀 一键安装：MCP 广场提供丰富的服务器选择
📊 使用统计：实时查看服务调用情况
立即访问 EMCP 平台 开始您的 MCP 之旅！
Related MCP server: Weather API167 MCP Server
这是一个 MCP 服务器，用于访问 Weatherapi Com API。
PyPI 包名: bach-weatherapi_com
版本: 1.0.0
传输协议: stdio
pip install bach-weatherapi_compip install -e .# 运行（uvx 会自动安装并运行）
uvx --from bach-weatherapi_com bach_weatherapi_com
# 或指定版本
uvx --from bach-weatherapi_com@latest bach_weatherapi_compython server.py# 安装
pip install bach-weatherapi_com
# 运行（命令名使用下划线）
bach_weatherapi_com此 API 需要认证。请设置环境变量:
export API_KEY="your_api_key_here"变量名 | 说明 | 必需 |
| API 密钥 | 是 |
| 不适用 | 否 |
| 不适用 | 否 |
编辑 Cursor MCP 配置文件 ~/.cursor/mcp.json:
{
"mcpServers": {
"bach-weatherapi_com": {
"command": "uvx",
"args": ["--from", "bach-weatherapi_com", "bach_weatherapi_com"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}编辑 Claude Desktop 配置文件 claude_desktop_config.json:
{
"mcpServers": {
"bach-weatherapi_com": {
"command": "uvx",
"args": ["--from", "bach-weatherapi_com", "bach_weatherapi_com"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}此服务器提供以下工具:
alerts_apiAlerts API returns alerts and warnings issued by government agencies (USA, UK, Europe and Rest of the World) as an array if available for the location provided.
端点: GET /alerts.json
参数:
q (string) 必需: Example value: london
future_weather_apiFuture weather API method returns weather in a 3 hourly interval in future for a date between 14 days and 300 days from today in the future.
端点: GET /future.json
参数:
q (string) 必需: Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1
lang (string): Returns 'condition:text' field in API in the desired language
dt (string) 必需: 'dt' should be between 14 days and 300 days from today in the future in yyyy-MM-dd format (i.e. dt=2023-01-01)
realtime_weather_apiCurrent weather or realtime weather API method allows a user to get up to date current weather information in json and xml. The data is returned as a Current Object.
端点: GET /current.json
参数:
q (string) 必需: Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1
sports_apiSports API method allows a user to get listing of all upcoming sports events for football, cricket and golf in json.
端点: GET /sports.json
参数:
q (string) 必需: Example value: London
astronomy_apiAstronomy API method allows a user to get up to date information for sunrise, sunset, moonrise, moonset, moon phase and illumination in json.
端点: GET /astronomy.json
参数:
q (string) 必需: Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1
dt (string): Date
searchautocomplete_apiSearch or Autocomplete API returns matching cities and towns.
端点: GET /search.json
参数:
q (string) 必需: Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1
marine_weather_apiMarine weather API returns upto next 7 day marine and sailing weather forecast and tide data for global marine/sea points.
端点: GET /marine.json
参数:
q (string) 必需: Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1
days (number): Example value: 1
lang (string): Example value:
history_weather_apiHistory weather API method returns historical weather for a date on or after 1st Jan, 2010 (depending upon subscription level) as json.
端点: GET /history.json
参数:
q (string) 必需: Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1
lang (string): Returns 'condition:text' field in API in the desired language
hour (number): Restricting history output to a specific hour in a given day.
dt (string) 必需: For history API 'dt' should be on or after 1st Jan, 2010 in yyyy-MM-dd format
end_dt (string): Restrict date output for History API method. Should be on or after 1st Jan, 2010. Make sure end_dt is equal to or greater than 'dt'.
forecast_weather_apiForecast weather API method returns upto next 14 day weather forecast and weather alert as json. It contains astronomy data, day weather forecast and hourly interval weather information for a given city.
端点: GET /forecast.json
参数:
q (string) 必需: Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1
days (number): Number of days of forecast required.
lang (string): Returns 'condition:text' field in API in the desired language
dt (string): If passing 'dt', it should be between today and next 10 day in yyyy-MM-dd format.
ip_lookup_apiIP Lookup API method allows a user to get up to date information for an IP address in json.
端点: GET /ip.json
参数:
q (string) 必需: e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1
time_zone_apiTime Zone API method allows a user to get up to date time zone and local time information in json.
端点: GET /timezone.json
参数:
q (string) 必需: Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1
传输协议: stdio
HTTP 客户端: httpx
MIT License - 详见 LICENSE 文件。
此服务器由 API-to-MCP 工具生成。
版本: 1.0.0
Alerts API returns alerts and warnings issued by government agencies (USA, UK, Europe and Rest of the World) as an array if available for the location provided.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Example value: london |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns an array of alerts, but does not describe key traits such as data freshness, rate limits, authentication needs, error handling, or what happens if no alerts are found. This leaves significant gaps in understanding how the tool behaves in practice.
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, efficient sentence that front-loads the core functionality. It avoids unnecessary words and directly states what the tool does. However, it could be slightly improved by structuring key details (e.g., behavior or usage) more explicitly, but it is well-sized for its 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 lack of annotations and output schema, the description is incomplete. It does not explain the return format (beyond 'array'), error conditions, or practical usage context. For a tool with no structured behavioral data, more details on outputs and limitations are needed to adequately inform 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?
The input schema has 100% description coverage, with the parameter 'q' documented as a string example ('london'). The description adds that it is for 'the location provided,' clarifying the parameter's purpose as a location query. However, it does not provide additional semantics like format constraints or examples beyond the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it returns alerts and warnings from government agencies as an array based on a location input. It specifies the verb ('returns'), resource ('alerts and warnings'), and scope ('government agencies in USA, UK, Europe and Rest of the World'). However, it does not explicitly differentiate from sibling tools like weather or sports APIs, which lowers it from a perfect score.
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 no guidance on when to use this tool versus alternatives. It mentions the tool returns alerts 'if available for the location provided,' which implies a condition but does not specify when to choose this over other tools (e.g., for safety vs. weather information). No exclusions or prerequisites are stated, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Astronomy API method allows a user to get up to date information for sunrise, sunset, moonrise, moonset, moon phase and illumination in json.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1 | |
| dt | No | Date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool 'allows a user to get up to date information' but doesn't cover critical aspects like rate limits, authentication requirements, error handling, or whether it's a read-only operation. The description is minimal and leaves significant behavioral traits unspecified.
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, efficient sentence that front-loads the core purpose. It avoids unnecessary words and directly states what the tool does. However, it could be slightly more structured by separating usage context from functionality, but it's appropriately sized for its content.
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 (2 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output format beyond 'json', error cases, rate limits, and how it differs from sibling tools. Without annotations or an output schema, the description should provide more context to be fully helpful 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 description coverage is 100%, so the input schema already documents both parameters ('q' and 'dt') thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'get up to date information for sunrise, sunset, moonrise, moonset, moon phase and illumination in json.' It specifies the verb ('get'), resource ('astronomy information'), and output format ('json'). However, it doesn't explicitly differentiate from sibling tools like 'time_zone_api' or 'realtime_weather_api', which might also provide related astronomical 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contextual factors like when to choose this over 'time_zone_api' for sunset times or 'forecast_weather_api' for weather-related astronomy. Usage is implied by the purpose but lacks explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forecast weather API method returns upto next 14 day weather forecast and weather alert as json. It contains astronomy data, day weather forecast and hourly interval weather information for a given city.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1 | |
| days | No | Number of days of forecast required. | 3 |
| lang | No | Returns 'condition:text' field in API in the desired language | |
| dt | No | If passing 'dt', it should be between today and next 10 day in yyyy-MM-dd format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the 14-day forecast limit and JSON format, but lacks critical information about rate limits, authentication requirements, error conditions, or whether this is a read-only operation. The description doesn't adequately compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that efficiently convey the core functionality. It's front-loaded with the main purpose and includes key constraints (14-day limit, JSON format). While effective, it could be slightly more structured with clearer separation of different forecast components.
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 4-parameter tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the return structure looks like (beyond 'json'), doesn't mention error handling, and provides no context about the sibling tools. The absence of output schema means the description should compensate by explaining return values, which it doesn't do.
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 schema already documents all parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions 'for a given city' which aligns with the 'q' parameter but provides no additional context about parameter interactions or usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to return weather forecasts up to 14 days with astronomy data, daily forecasts, and hourly information for a given city. It specifies the verb ('returns') and resource ('weather forecast'), but doesn't explicitly differentiate from siblings like 'future_weather_api' or 'realtime_weather_api'.
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?
No guidance is provided on when to use this tool versus alternatives. With multiple weather-related sibling tools (future_weather_api, realtime_weather_api, etc.), the description offers no context about appropriate use cases, prerequisites, or distinctions from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Future weather API method returns weather in a 3 hourly interval in future for a date between 14 days and 300 days from today in the future.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1 | |
| lang | No | Returns 'condition:text' field in API in the desired language | |
| dt | Yes | 'dt' should be between 14 days and 300 days from today in the future in yyyy-MM-dd format (i.e. dt=2023-01-01) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It mentions the temporal constraints (14-300 days future, 3-hour intervals) but doesn't cover rate limits, authentication requirements, error conditions, response format, or what happens with invalid parameters. For an API tool with no annotations, this leaves significant gaps.
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, reasonably concise sentence that communicates the core functionality. However, it could be slightly more structured by separating the temporal constraints from the data format, and it doesn't front-load the most critical information about what distinguishes this from other weather tools.
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 an API tool with no annotations and no output schema, the description is insufficient. It doesn't explain what weather data is returned (temperature, precipitation, etc.), the response format, error handling, or authentication requirements. Given the complexity of weather data and lack of structured metadata, the description should provide more complete context for effective tool use.
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 schema already fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate coverage through the schema alone.
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 weather data in 3-hour intervals for future dates between 14 and 300 days from today. It specifies the verb ('returns'), resource ('weather'), and temporal scope ('future'), but doesn't explicitly differentiate from sibling tools like forecast_weather_api or history_weather_api.
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?
No guidance is provided about when to use this tool versus alternatives like forecast_weather_api (likely for shorter-term forecasts) or history_weather_api. The description only states what the tool does, not when it should be selected over similar weather-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
History weather API method returns historical weather for a date on or after 1st Jan, 2010 (depending upon subscription level) as json.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1 | |
| lang | No | Returns 'condition:text' field in API in the desired language | |
| hour | No | Restricting history output to a specific hour in a given day. | 0 |
| dt | Yes | For history API 'dt' should be on or after 1st Jan, 2010 in yyyy-MM-dd format | |
| end_dt | No | Restrict date output for History API method. Should be on or after 1st Jan, 2010. Make sure end_dt is equal to or greater than 'dt'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the date constraint ('on or after 1st Jan, 2010') and subscription-level dependencies, but lacks critical behavioral details: it doesn't specify authentication requirements, rate limits, error handling, or the structure of the JSON response. For a data-fetching tool with no annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that states the core purpose upfront. It avoids redundancy and wastes no words, though it could be slightly more structured (e.g., by separating key constraints). Overall, it's appropriately concise for the tool's complexity.
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 annotations and no output schema, the description is incomplete. It covers the basic purpose and date constraints but omits essential context: authentication needs, rate limits, error cases, and the JSON response structure. For a historical data API with multiple parameters, this leaves the agent under-informed about how to effectively invoke and interpret results.
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 schema fully documents all 5 parameters. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain 'q' formats or 'dt' constraints in more detail). Baseline 3 is appropriate as the schema handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'returns historical weather for a date on or after 1st Jan, 2010 as json.' It specifies the verb ('returns'), resource ('historical weather'), and temporal scope. However, it doesn't explicitly differentiate from siblings like 'realtime_weather_api' or 'forecast_weather_api' beyond the 'historical' qualifier, which is implied but not contrasted.
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 no guidance on when to use this tool versus alternatives. It mentions subscription-level dependencies but doesn't name or compare to sibling tools (e.g., 'realtime_weather_api' for current weather or 'forecast_weather_api' for future predictions). There's no explicit 'when-not' or alternative usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
IP Lookup API method allows a user to get up to date information for an IP address in json.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'up to date information' but does not cover critical aspects such as rate limits, authentication requirements, error handling, or data freshness guarantees. For an API tool with no annotations, this leaves significant gaps in understanding its operational behavior.
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, efficient sentence that front-loads the core purpose. It avoids unnecessary words and gets straight to the point. However, it could be slightly more structured by explicitly separating purpose from output format, but it remains highly concise and clear.
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 (an API with no annotations and no output schema), the description is incomplete. It lacks details on return values, error cases, usage limits, and how it differs from sibling tools. Without annotations or an output schema, the description should provide more context to guide the agent effectively, but it falls short.
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% description coverage, with the parameter 'q' documented as an IP address (IPv4/IPv6). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Since schema coverage is high, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'get up to date information for an IP address in json.' It specifies the verb ('get'), resource ('information for an IP address'), and output format ('json'). However, it does not distinguish this from potential sibling tools (like other APIs on the server), which prevents a score of 5.
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 no guidance on when to use this tool versus alternatives. It mentions 'up to date information' but does not specify use cases, prerequisites, or exclusions. With sibling tools like various weather APIs, there is no indication of when IP lookup is appropriate, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marine weather API returns upto next 7 day marine and sailing weather forecast and tide data for global marine/sea points.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1 | |
| days | No | Example value: 1 | 1 |
| lang | No | Example value: |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns forecast and tide data for up to 7 days, which is useful, but lacks details on rate limits, authentication needs, error handling, or data format. For a weather API with no annotation coverage, this is a significant gap in 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 a single, efficient sentence that front-loads key information (returns marine weather and tide data, up to 7 days, global points). It avoids unnecessary details, though it could be slightly more structured by separating scope from functionality.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the core purpose but lacks behavioral context and usage guidelines. Without annotations or output schema, more detail on return values or operational constraints would improve completeness.
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 schema fully documents all parameters (q, days, lang). The description adds no additional parameter semantics beyond implying marine/sea points in the query, which is already covered by the schema's examples. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it returns marine/sailing weather forecasts and tide data for global points, with a specific timeframe of up to 7 days. It distinguishes itself from siblings like 'realtime_weather_api' or 'forecast_weather_api' by focusing on marine-specific data, though it doesn't explicitly contrast with all siblings.
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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or compare it to sibling tools like 'forecast_weather_api' or 'realtime_weather_api', leaving the agent to infer usage based on the marine focus alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current weather or realtime weather API method allows a user to get up to date current weather information in json and xml. The data is returned as a Current Object.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the output format (json/xml) and that data is returned as a 'Current Object', but lacks critical details: authentication requirements, rate limits, error handling, whether it's read-only (implied but not stated), or any performance characteristics. The description is insufficient for a tool with zero annotation coverage.
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 (two sentences) but has structural issues. The first sentence is somewhat redundant ('Current weather or realtime weather API method'). The second sentence adds value by specifying the return object type. However, it could be more front-loaded with clearer differentiation from siblings.
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 annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It doesn't explain what a 'Current Object' contains, doesn't address authentication or rate limits, and provides minimal behavioral context. For a weather API tool among many siblings, more completeness is needed to guide proper 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 description coverage is 100%, so the schema fully documents the single parameter 'q' with extensive examples. The description adds no parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in 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 the tool's purpose: 'get up to date current weather information' with specific output formats (json and xml). It distinguishes from siblings like forecast_weather_api and history_weather_api by focusing on current/realtime data. However, it doesn't explicitly contrast with all siblings (e.g., alerts_api, marine_weather_api).
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 no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over forecast_weather_api for future predictions, history_weather_api for past data, or other siblings like marine_weather_api for specialized data. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search or Autocomplete API returns matching cities and towns.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'matching cities and towns,' which implies a read-only, non-destructive operation, but doesn't cover critical aspects like rate limits, authentication needs, error handling, or response format. For a tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence: 'Search or Autocomplete API returns matching cities and towns.' It is front-loaded with the core purpose and contains no redundant or verbose elements, making it highly 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?
Given the tool's complexity (handling diverse query types like coordinates, names, and codes), lack of annotations, and absence of an output schema, the description is incomplete. It doesn't explain the return format (e.g., structure of matching results), error conditions, or usage constraints, leaving gaps that could hinder effective agent operation.
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% description coverage, with the 'q' parameter fully documented in the schema itself (e.g., supporting latitude/longitude, city names, zip codes). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search or Autocomplete API returns matching cities and towns.' It specifies the action (search/autocomplete) and the resource (cities and towns). However, it doesn't explicitly distinguish this from sibling tools like 'ip_lookup_api' or 'realtime_weather_api' beyond the resource focus, which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'ip_lookup_api' (which might handle IP-based lookups) or 'forecast_weather_api' (which might provide weather data for locations), nor does it specify prerequisites or exclusions for usage. This leaves the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sports API method allows a user to get listing of all upcoming sports events for football, cricket and golf in json.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Example value: London |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the output format ('in json') but lacks details on rate limits, authentication needs, error handling, or whether this is a read-only operation. The description implies a safe read operation but doesn't explicitly state it, leaving gaps in behavioral context.
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, efficient sentence that front-loads the key information: the action, resource, and scope. It avoids unnecessary words, though it could be slightly more structured by separating the sports types for clarity. Overall, it's appropriately sized for its 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 moderate complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and output format but lacks details on usage context, behavioral traits, or error handling. With no output schema, it doesn't explain return values, which is a gap, but the description compensates somewhat by mentioning the json format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'q' described as 'Example value: London'. The description doesn't add any parameter semantics beyond what the schema provides, such as explaining what 'q' represents (e.g., location query). However, with high schema coverage, the baseline is 3, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'get listing of all upcoming sports events for football, cricket and golf in json.' It specifies the verb ('get'), resource ('sports events'), scope ('upcoming'), and sports types ('football, cricket and golf'). However, it doesn't explicitly differentiate from sibling tools like 'alerts_api' or 'forecast_weather_api', which are clearly different domains, so it doesn't need sibling differentiation.
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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or context for usage. For example, it doesn't clarify if this is for real-time data, historical data, or how it differs from other sports-related tools (though none are listed as siblings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Time Zone API method allows a user to get up to date time zone and local time information in json.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Query parameter based on which data is sent back. It could be following: Latitude and Longitude (Decimal degree) e.g: q=48.8567,2.3508 city name e.g.: q=Paris US zip e.g.: q=10001 UK postcode e.g: q=SW1 Canada postal code e.g: q=G2J metar: e.g: q=metar:EGLL iata:<3 digit airport code> e.g: q=iata:DXB auto:ip IP lookup e.g: q=auto:ip IP address (IPv4 and IPv6 supported) e.g: q=100.0.0.1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool 'allows a user to get' information, implying a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication needs, error handling, or data freshness guarantees. The description is minimal and lacks critical operational details.
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, efficient sentence that front-loads the core purpose. It avoids unnecessary words and directly states the tool's function. However, it could be slightly more structured by separating key points (e.g., output format, input types).
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 (API with various query types), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error cases, or practical usage examples. The schema handles parameters well, but the description fails to provide sufficient context for effective tool 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 description coverage is 100%, with the parameter 'q' fully documented in the schema. The description adds no additional parameter semantics beyond what's in the schema. According to rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the 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 the tool's purpose: 'get up to date time zone and local time information in json.' It specifies the verb ('get'), resource ('time zone and local time information'), and output format ('json'). However, it doesn't explicitly differentiate from sibling tools like ip_lookup_api or searchautocomplete_api that might also provide location-based 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or clarify scenarios where this API is preferred over others (e.g., vs. ip_lookup_api for IP-based time zones). Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
alerts_apiastronomy_apiforecast_weather_apifuture_weather_apihistory_weather_apiip_lookup_apimarine_weather_apirealtime_weather_apisearchautocomplete_apisports_apitime_zone_apiEach tool has a clearly distinct purpose with no overlap: alerts for warnings, astronomy for celestial events, forecast for 14-day predictions, future for long-range forecasts, history for past data, IP lookup for location, marine for sailing weather, realtime for current conditions, search for autocomplete, sports for events, and time zone for time data. The descriptions make it easy to differentiate between them.
All tool names follow a consistent pattern: they end with '_api' and use descriptive, lowercase terms (e.g., alerts_api, astronomy_api). This uniformity makes the set predictable and easy to navigate, with no deviations in style or structure.
With 11 tools, the server is well-scoped for a comprehensive weather API, covering current, forecast, historical, marine, astronomy, alerts, IP lookup, search, sports, and time zone functionalities. Each tool earns its place without feeling excessive or insufficient for the domain.
The tool surface is complete for a weather API domain, offering full coverage: realtime, forecast, history, future predictions, marine data, astronomy, alerts, location via IP and search, sports events, and time zones. There are no obvious gaps, and agents can handle typical weather-related workflows without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Global weather API: forecasts, historical data, marine, ski, astronomy and timezone.
WeatherAPI.com MCP — wraps WeatherAPI.com (api.weatherapi.com)
Weather data, forecast API, climate data, historical weather, alerts, agricultural & travel weather.
Global weather via Open-Meteo: forecast, ERA5 archive, marine, air quality, geocoding, elevation.
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/weatherapi_com'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
