ERA5 SMI

by leandroavl

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct data source or processing step: inspect_netcdf for inspection, the fetch tools are differentiated by time resolution (hourly vs monthly mean) and data type (pressure levels, single levels, land soil moisture), and extract_point_timeseries is the only output-writing tool. There is no meaningful overlap between tool purposes.
Naming Consistency4/5
The naming follows a consistent snake_case verb_noun pattern, with fetch_era5_* clearly grouped by data type and time resolution. Minor deviation: tools without 'hourly' are implicitly monthly mean (e.g., fetch_era5_pressure_levels), which is not explicitly reflected in the name, and inspect/extract use generic verbs rather than the fetch_ prefix.
Tool Count5/5
Seven tools cover the full data-preparation workflow for the ERA5 SMI pipeline: inspection, downloading multiple ERA5 variants, and extracting point timeseries. The count is well-scoped, not bloated or sparse, and each tool has a clear role.
Completeness4/5
The tool surface covers the main data types (pressure levels, single levels, land soil moisture) in both hourly and monthly resolutions, plus inspection and extraction. Minor gaps: there is no tool for directly listing available variables or fetching ERA5-Land hourly soil moisture, but these are not critical given the stated SMI focus.
Average 3.6/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are present, so the description must carry the burden of disclosing side effects. It only says 'Downloads' and does not mention that it writes a local file (output_filename), requires CDS credentials, or imposes API/rate limits. This leaves the agent with little beyond the action verb.
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 front-loaded sentence with no filler. It loses one point for being terse to the point of under-specification for a tool with nine parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With nine parameters, a rich schema, and multiple sibling tools, a one-sentence description is not complete enough. It omits when to use this tool, how output is delivered, and any operational caveats, despite the schema covering parameters well.
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% and all nine parameters have descriptions and examples. The tool description adds no parameter-level meaning, so it does not exceed the baseline of 3.
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 uses the specific verb 'Downloads' and names a clear resource, 'ERA5 hourly surface data,' which distinguishes this from sibling pressure-level and soil-moisture tools. The 'hourly surface' qualifier disambiguates from fetch_era5_single_levels and fetch_era5_pressure_levels.
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 about when to choose this tool over siblings such as fetch_era5_single_levels or fetch_era5_hourly_pressure_levels. It neither states explicit conditions nor mentions alternatives or exclusions.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the download action, without disclosing whether existing files are overwritten, network dependencies, data size implications, or any side effects beyond creating a file.
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?
A single, front-loaded sentence with no filler; every word adds meaning. It is appropriately sized for the simple action it names and avoids redundancy.
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?
Despite rich schema coverage, the tool has 10 parameters, no annotations, and an output schema, yet the description offers no context on prerequisites, when to use it, or caveats. The one-sentence description is too minimal to fully support selection and invocation in context.
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%, and each parameter has descriptive text with examples (e.g., 'east' includes full usage examples). The tool description itself adds no parameter semantics, but the schema fully covers them, so the baseline score applies.
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 uses a specific verb ('Downloads') and names the resource ('ERA5 hourly data on specific pressure levels'), which clearly differentiates it from sibling tools like fetch_era5_single_levels and fetch_era5_pressure_levels by specifying both hourly and pressure level dimensions.
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 usage guidance is provided. It does not state when to choose this over fetch_era5_pressure_levels or fetch_era5_hourly_single_levels, nor mention prerequisites like CDS authentication, optional bounding-box usage, or the ability to specify multiple days.
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, the description carries the full burden of disclosing behavioral traits. It only states 'Downloads' without mentioning side effects like writing to a local file, requiring network access, or potential authentication/rate limits. The tool's behavior beyond the core download action is opaque, which is insufficient for a data-fetching operation.
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, front-loaded sentence with zero wasted words. It efficiently communicates the tool's core purpose, and no additional content is needed for clarity at the level of intent; other dimensions cover missing depth.
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?
Despite a moderately complex parameter set (8 params) and no annotations, the description fails to provide broader context: it does not explain that it supports spatial bounding boxes, what output format is returned (though an output schema may exist), or how downloads are handled (e.g., file overwrite behavior). The description is too sparse to be considered complete for an agent to confidently invoke the tool.
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 each of the 8 parameters having a description in the schema. The tool description itself adds no additional parameter semantics, so it does not improve on the schema. Baseline 3 is appropriate because the schema fully documents parameters, though the description misses opportunities to clarify relationships between coordinates or variable naming.
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 'Downloads ERA5 monthly mean surface data' uses a specific verb ('downloads'), names the exact resource ('ERA5 monthly mean surface data'), and the phrase 'monthly mean' clearly distinguishes this tool from hourly siblings like fetch_era5_hourly_single_levels. It also contrasts with pressure-level and soil-moisture tools, providing clear scoping.
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 the tool is for monthly mean surface data but does not explicitly state when to prefer it over alternatives (e.g., hourly or pressure-level tools). There is no mention of when not to use it or which sibling to choose for different temporal/spatial needs, so guidance is only implicit.
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. The description only says 'Downloads' and does not disclose potential side effects like network dependency, overwriting existing files, required API credentials, or failure modes. It adds no behavioral context beyond what the tool name and schema imply.
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 two sentences, front-loaded with the action verb and resource. There is no redundant or filler content. Every sentence earns its place.
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?
The description provides a clear purpose and usage context, and the schema is comprehensive. However, it lacks any note about prerequisites (e.g., CDS API key, network availability) or potential pitfalls, which would be important for a data download tool. Given the schema and output schema, this is a decent but not fully complete description.
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 already provides 100% coverage, with detailed parameter descriptions including examples and soil layer depth ranges. The description adds no additional parameter semantics beyond hints like 'one soil layer' and 'monthly mean,' which are already captured implicitly. Baseline 3 is appropriate.
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 uses a specific verb 'Downloads' and clearly identifies the exact resource: 'ERA5-Land monthly mean volumetric soil water content for one soil layer.' This distinguishes it from sibling tools like fetch_era5_single_levels or fetch_era5_hourly_pressure_levels, which target different datasets. Mentioning the SMI pipeline adds useful context.
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 states 'This is the primary data source for the SMI pipeline (see skills/calculate-smi)', which gives a clear context for when to use it. However, it does not explicitly state when not to use it or name alternative tools, though sibling names are available. That prevents a 5.
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?
No annotations are provided, so the description carries the burden. It clearly identifies the operation as a download (non-destructive retrieval), which is helpful. However, it does not disclose potential behavioral traits such as overwrite behavior, download size/time, authentication needs, or return format beyond what the output schema implies.
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?
A single, well-structured sentence that is front-loaded with the core action and resource. No redundant or filler content.
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 complexity (9 params) and presence of an output schema, the description provides the essential distinction (monthly mean, pressure levels) and the temporal scope. It could mention the alternative hourly/single-level options, but the description is adequate for a straightforward download tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal semantics beyond the schema, only reinforcing that the data is monthly mean and spans years. No new parameter-level meaning is introduced.
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 uses a specific verb ('Downloads') and identifies the exact resource (ERA5 monthly mean data) with key qualifiers (specific pressure levels, given month, one or more years). It clearly distinguishes from sibling tools that fetch hourly data or single levels.
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 use for monthly mean pressure-level data but does not explicitly state when to choose this over alternatives like fetch_era5_hourly_pressure_levels or fetch_era5_single_levels. No exclusions or specific use cases are 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 the burden of behavioral disclosure. It states the tool inspects the file and returns a summary, which is a read-only action. However, it does not mention potential errors (e.g., invalid filepath, unsupported format) or any side effects, though for a simple inspection tool this is somewhat acceptable.
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, focused sentence that directly states the action and expected output. No filler or redundancy; every word adds value.
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?
The tool is simple (one parameter) and has an output schema, so the description does not need to explain return structure. It adequately covers the tool's purpose and result. The only minor gap is lack of explicit usage context relative to sibling tools, but that is not critical for a straightforward inspection tool.
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 single 'filepath' parameter adequately described as 'The absolute path to the .nc file to inspect.' The description does not add additional parameter detail, but the schema already provides sufficient semantics, so a baseline of 3 is appropriate.
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 uses a specific verb ('Inspects') with a clear resource ('a NetCDF file') and states the expected output ('summary of its contents (dimensions, variables, coordinates)'). It clearly distinguishes this tool from siblings like fetch_era5_* and extract_point_timeseries, which are data retrieval/extraction tools rather than file inspection.
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 this tool is used to preview or summarize a NetCDF file, but it does not explicitly state when to use it versus the sibling fetch/extract tools. No exclusions or alternative recommendations are provided, so the usage context is only implicitly clear.
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 discloses the extraction method (nearest-pixel), temporal resolution (monthly), and output format. However, it does not mention overwrite behavior, error handling, or explicit file existence prerequisites beyond 'downloaded', leaving some gaps in side-effect 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 two sentences, front-loaded with the main action, and includes a purposeful reference to the downstream skill. Every sentence contributes, with no fluff or redundancy.
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?
The description, combined with the high schema coverage and presence of an output schema, gives sufficient context for correct usage. It explains the exact CSV format and ties to the calculate-smi skill. Minor gaps like multi-variable handling are already addressed by the schema's optional variable parameter and examples.
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 schema has 100% coverage for all parameters with clear descriptions, so the baseline is 3. The description adds context about the output columns and nearest-pixel selection, but it does not elaborate on parameter specifics beyond what the schema already provides. Thus, minimal added value over the 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 a specific action (extracts nearest-pixel monthly time series) and a specific output (CSV with columns year,month,date,<variable>). It distinguishes itself from sibling fetch/inspect tools by operating on a downloaded NetCDF file and producing a CSV, making its purpose unambiguous.
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 it should be used after a NetCDF file is downloaded and its output is intended for the calculate-smi skill. It does not explicitly exclude other tools, but given the sibling tools are fetching or inspecting, the context is clear. It lacks direct alternative naming but provides sufficient contextual workflow 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:

[![SMI_mcp MCP server](https://glama.ai/mcp/servers/leandroavl/SMI_mcp/badges/card.svg)](https://glama.ai/mcp/servers/leandroavl/SMI_mcp)

Score Badge

Copy to your README.md:

[![SMI_mcp MCP server](https://glama.ai/mcp/servers/leandroavl/SMI_mcp/badges/score.svg)](https://glama.ai/mcp/servers/leandroavl/SMI_mcp)

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/leandroavl/SMI_mcp'

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