IPMA Weather 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. The tools cover different weather-related data types (daily forecasts, fire risk, sea state, UV index, seismic data, station observations, warnings, city lists, and weather type descriptions), and their descriptions make it easy to distinguish which tool to use for each specific query.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern starting with 'get_' or 'list_', with clear and descriptive nouns (e.g., get_daily_aggregate_forecast, get_fire_risk, list_available_cities). There are no deviations in naming conventions, making the set predictable and easy to navigate.
Tool Count5/5
With 10 tools, the server is well-scoped for providing comprehensive weather data for Portugal. Each tool serves a unique and necessary function, from forecasts and observations to warnings and metadata, without feeling bloated or insufficient for the domain.
Completeness5/5
The tool set provides complete coverage for weather data in Portugal, including forecasts (daily, city-specific, sea, UV), real-time data (observations, seismic activity, warnings), and supporting information (city lists, weather type descriptions). There are no obvious gaps, and agents can access all relevant meteorological aspects without dead ends.
Average 4/5 across 10 of 10 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 status not available
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. It discloses the 30-day time window constraint and geographic scope, but lacks critical behavioral details: whether this is a read-only operation, rate limits, authentication needs, error conditions, or response format. The description adds some context but leaves significant gaps for a data retrieval tool.
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 sized and well-structured with clear sections: purpose statement, Args section with parameter details, and a Note with additional context. Every sentence adds value, though the Portuguese/English mix slightly affects readability. The information is front-loaded with the core purpose first.
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 no annotations and no output schema, the description provides adequate context for a simple single-parameter query tool. It covers purpose, parameter semantics, and geographic/temporal scope. However, it lacks information about response format, error handling, and operational constraints that would be important for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides comprehensive parameter semantics despite 0% schema description coverage. It fully documents the single parameter 'region' with its purpose, allowed values ('all', 'continente', 'açores', 'madeira'), default value ('all'), and meaning. This completely compensates for the schema's lack of descriptions.
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 seismic activity data for Portugal' with specific scope ('últimos 30 dias'). It distinguishes from siblings by focusing on seismic data rather than weather, fire, or forecasts. However, it doesn't explicitly differentiate from potential seismic siblings (none exist in this server).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('últimos 30 días') and mentions geographic scope (Azores, Continental Portugal, Madeira), but provides no explicit guidance on when to use this tool versus alternatives. No sibling tools overlap in domain, so differentiation isn't needed, but general usage context is only implied.
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 lacks critical behavioral details. It doesn't mention rate limits, authentication requirements, data freshness, error conditions, or whether this is a read-only operation. The description only covers basic functionality without operational 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 appropriately sized with clear sections: purpose statement, parameter explanations, and return value description. Every sentence adds value, though the Portuguese parenthetical could be considered slightly extraneous. The structure is front-loaded with the core 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 no annotations and no output schema, the description provides adequate basic information about what the tool does and its parameters, but lacks details about return format structure, error handling, and operational constraints. For a forecast tool with two parameters, it's minimally viable but leaves gaps in behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial value beyond the schema's 0% coverage. It explains that location_name can be left empty to see all available locations, provides concrete examples of valid values, defines the day parameter's encoding (0=today, 1=tomorrow, 2=day after tomorrow), and specifies the valid range. This compensates fully for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get sea state forecast'), resource ('Portuguese coastal areas'), and temporal scope ('up to 3 days'). It distinguishes from siblings by focusing on sea state rather than weather, fire risk, seismic data, or other forecast types mentioned in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its parameter explanations (e.g., 'Leave empty to see all available locations'), but doesn't explicitly state when to use this tool versus alternatives like 'get_forecast' or 'get_daily_aggregate_forecast'. No guidance on exclusions or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the 5-day time horizon and forecast components (temperature, precipitation, wind, weather type), which are useful behavioral traits. However, it doesn't mention rate limits, authentication needs, data freshness, or error conditions. The description adds some value but leaves significant behavioral aspects undocumented.
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 efficiently structured with a clear purpose statement, parameter documentation, and return value description in just three sentences. Every sentence adds value: the first states what the tool does, the second documents the single parameter with examples, and the third describes the output. No wasted words.
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 no annotations and no output schema, the description provides adequate basic information about purpose and parameters but lacks details about return format structure, error handling, or behavioral constraints. For a weather forecasting tool with no structured metadata, the description should ideally include more about data sources, update frequency, or validation rules to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only 1 parameter, the description provides essential semantic context: it explains city_name must be a Portuguese city name and gives concrete examples (Lisboa, Porto, Faro, Aveiro, Braga). This compensates well for the schema's lack of description, though it doesn't specify format constraints like case sensitivity or special characters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get 5-day weather forecast'), resource ('for a Portuguese city'), and scope ('detailed 5-day forecast including temperature, precipitation, wind, and weather type'). It distinguishes from siblings like get_fire_risk or get_sea_forecast by focusing on comprehensive 5-day weather forecasts rather than specialized data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Portuguese cities with the example list, but doesn't explicitly state when to use this tool versus alternatives like get_daily_aggregate_forecast or get_weather_warnings. The Portuguese city constraint is mentioned, but no guidance on exclusions or specific scenarios where this tool is preferred over 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the data source ('IPMA database') and scope ('comprehensive list'), but doesn't address important behavioral aspects like whether this is a static list or dynamically updated, potential rate limits, authentication requirements, or what format the list returns (e.g., structured data vs. raw text).
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 efficiently structured in two sentences: the first states the purpose and scope, the second clarifies what's included in the return. Every word adds value with no redundancy or unnecessary elaboration.
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?
For a simple list-retrieval tool with no parameters and no output schema, the description provides adequate purpose and scope information. However, without annotations or output schema, it lacks details about return format, data freshness, or error conditions that would be helpful for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100% (though trivial since there are no parameters). The description appropriately doesn't discuss parameters, focusing instead on what the tool returns. This meets the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all available Portuguese cities and islands') and resource ('weather forecasts'), distinguishing it from siblings that retrieve actual weather data rather than location metadata. It explicitly mentions the scope ('IPMA database') and types of locations included ('district capitals and islands').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating this tool provides 'available locations for weather forecasts,' suggesting it should be used to identify valid inputs for forecast-related siblings. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the siblings for different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral aspects: geographic limitation (Portugal only), temporal scope (2-day forecast), and return format (RCM classification with level definitions). However, it doesn't mention rate limits, authentication requirements, data freshness, or error conditions that would be helpful for an agent.
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 well-structured with clear sections (purpose, args, returns) and efficiently conveys necessary information. Every sentence earns its place, though the fire risk levels could be presented more concisely. The information is appropriately front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description provides good coverage: clear purpose, parameter documentation, return format explanation, and classification scale. It could be more complete by mentioning data source, update frequency, or municipality granularity, but covers the essentials well given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It fully documents the single parameter 'day' with its semantics (forecast day), valid values (0-1), and meaning (0=today, 1=tomorrow). This completely compensates for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get'), resource ('fire risk forecast'), and geographic scope ('for Portugal'). It distinguishes from siblings by focusing specifically on fire risk rather than general weather, seismic, or UV forecasts. The title 'Previsão Risco de Incêndio até 2 dias' reinforces the specific domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the geographic limitation ('for Portugal') and temporal scope ('until 2 days'), but doesn't explicitly state when to use this tool versus alternatives like get_forecast or get_weather_warnings. No guidance is provided about when this tool is preferred over sibling tools for fire-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 describes the return format (UV index forecast with defined levels) and geographic scope, but lacks details on rate limits, authentication needs, error handling, or data freshness. It adequately covers the core behavior but misses operational constraints.
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 efficiently structured: the first sentence states the purpose, the second clarifies the return, and the subsequent lines provide essential UV index classifications. Every sentence adds value without redundancy, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is nearly complete. It covers purpose, geographic and temporal scope, and output format with detailed UV levels. Minor gaps include lack of information on data sources or update frequency, but overall it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on output semantics by explaining the UV index scale and levels, which adds value beyond the schema. This compensates for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('UV index forecast'), including the geographic scope ('for Portugal') and time horizon ('até 3 dias'). It distinguishes from siblings by focusing exclusively on UV radiation forecasting, unlike other tools that handle weather types, sea conditions, fire risk, or seismic data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the geographic restriction ('for Portugal') and time frame ('até 3 dias'), suggesting this tool is for UV forecasting in Portugal up to 3 days ahead. However, it does not explicitly state when to use this versus alternatives like 'get_forecast' or 'get_daily_aggregate_forecast', nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It usefully describes the return content structure (warning types, awareness levels, affected areas, time ranges) but doesn't mention potential limitations like data freshness, API rate limits, or error conditions that would help an agent use it appropriately.
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 efficiently structured with a clear purpose statement followed by bullet points detailing return values. Every sentence earns its place, with no redundant information or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides excellent coverage of what the tool returns. It could be more complete by mentioning data source or update frequency, but it adequately explains the core functionality and output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on what the tool returns when invoked without inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get Portuguese meteorological warnings') with precise scope ('for up to 3 days'), distinguishing it from siblings like get_forecast or get_fire_risk by focusing on active warnings rather than forecasts or other data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the 'active weather warnings' focus and 3-day limit, suggesting this tool is for current alert situations rather than general forecasting. However, it doesn't explicitly state when to choose this over alternatives like get_forecast or list_available_cities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the temporal scope (last 24 hours, hourly data) and data format (list of meteorological variables), but doesn't mention rate limits, authentication needs, error conditions, or pagination behavior for the 'all stations' case.
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 sized and front-loaded with the core purpose. The bulleted list of return values is useful but could be slightly more concise. Every sentence adds value, though the Portuguese parenthetical could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with no output schema, the description provides good coverage: purpose, parameter semantics, return data structure, and temporal scope. It lacks some behavioral details (like error handling) but is reasonably complete given the tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the schema's 0% coverage. It explains that station_id is optional ('Leave empty to see all stations') and clarifies the parameter's purpose ('ID of the weather station'), which the schema only labels generically as 'Station Id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get meteorological observations') and resource ('from weather stations'), with explicit scope ('last 24 hours', 'hourly'). It distinguishes from siblings like forecast tools by focusing on historical observations rather than predictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (for recent observational data) and implies when not to use it (for forecasts, aggregates, or other data types covered by siblings). However, it doesn't explicitly name alternatives or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 describes the return format ('mapping of weather type IDs to their Portuguese and English descriptions') and purpose ('helps interpret the idWeatherType field'), but doesn't mention potential limitations like data freshness, rate limits, authentication requirements, or error conditions. It adequately covers the basic read operation but lacks 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three focused sentences that each add distinct value: stating the core function, describing the output format, and explaining the practical application. There's no redundancy or wasted words, and the information is front-loaded with the most important details first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description provides sufficient context for a read-only metadata lookup tool. It explains what the tool returns and why it's useful. The main gap is the lack of output schema, but the description compensates by describing the return format. For a simple tool like this, the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and output format, which is the correct approach for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get descriptions') and resources ('weather type codes used in forecasts'), and distinguishes it from siblings by focusing on metadata interpretation rather than forecast data retrieval. It explicitly mentions the target field ('idWeatherType') and output format ('mapping of weather type IDs to Portuguese and English descriptions').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('helps interpret the idWeatherType field in forecast data'), which implicitly distinguishes it from sibling tools that retrieve actual forecast data. However, it doesn't explicitly state when NOT to use it or name specific alternatives for similar functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 describes the aggregation scope ('aggregated forecast for all Portuguese locations') and temporal constraints ('until 3 days'), which adds useful context beyond basic functionality. However, it does not cover aspects like rate limits, authentication needs, error conditions, or response format details, leaving gaps for a tool with no annotation support.
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 appropriately sized and front-loaded, with the core purpose stated first, followed by parameter details and return clarification. Every sentence earns its place by adding value—no redundant or vague phrasing. The structure efficiently communicates key information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is largely complete. It covers purpose, parameter semantics, and scope well. However, it lacks details on the return format (e.g., structure of aggregated data) and any behavioral constraints like rate limits, which would enhance completeness for a forecast tool with no structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains the 'day' parameter's semantics (forecast day with 0=today mapping), valid range (0-2), and clarifies it returns aggregated data for the specified day. This fully compensates for the schema's lack of documentation, providing essential usage context that the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get daily aggregated weather forecast'), resource ('for Portugal'), and scope ('aggregated forecast for all Portuguese locations'), distinguishing it from siblings like get_forecast (likely more granular) or get_sea_forecast (different domain). It provides a precise verb+resource combination with explicit geographical and aggregation boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests usage for daily aggregated forecasts in Portugal, but does not explicitly state when to use this tool versus alternatives like get_forecast or list_available_cities. It provides clear context (Portugal, aggregated, 3-day forecast) but lacks explicit exclusions or named alternatives, missing the highest tier of guidance.
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:

[![ipma-mcp-server MCP server](https://glama.ai/mcp/servers/gabriel20vieira/ipma-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/gabriel20vieira/ipma-mcp-server)

Score Badge

Copy to your README.md:

[![ipma-mcp-server MCP server](https://glama.ai/mcp/servers/gabriel20vieira/ipma-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/gabriel20vieira/ipma-mcp-server)

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/gabriel20vieira/ipma-mcp-server'

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