Weatherapi Com MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 2.9/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
Usage Guidelines2/5
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.
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 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
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. 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines2/5
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.
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 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines2/5
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.
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 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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
Usage Guidelines2/5
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.
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 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines2/5
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.
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 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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines2/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![weatherapi_com MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/weatherapi_com/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/weatherapi_com)

Score Badge

Copy to your README.md:

[![weatherapi_com MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/weatherapi_com/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/weatherapi_com)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/weatherapi_com'

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