epwforge-mcp
Server Details
EPW/DDY weather files - TMY/AMY/CMIP6 morphing, UHI, events, smoke. 3 of 4 tools anon-free.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- guzz-labs/epwforge-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: finding stations, analyzing weather data, charting it, and generating files. No overlap in functionality.
All tool names follow a consistent verb_noun pattern (analyze_weather, chart_weather, find_station, generate_weather_file), making them predictable and easy to distinguish.
4 tools is well-scoped for this domain, covering the essential operations without unnecessary bloat.
The tool surface covers the main workflow (discovery, analysis, visualization, generation). A minor gap is the lack of a batch listing tool, but the core is complete.
Available Tools
4 toolsanalyze_weatherAInspect
Compute design conditions, HDD/CDD, monthly stats, and peak heating/cooling days for one or more EPW files. Accepts a url (existing EPW), urls (compare 2+), or config (synthesize on the fly with morphing/UHI/events/smoke). Config mode runs the full generation pipeline server-side but returns only stats — never the EPW content. Optional include_full_ashrae adds ASHRAE 0.4/1/2% cooling + 99.6/99% heating design conditions with mean coincident dewpoint. Optional include_improbability (config mode) adds a stress-test score. Optional include_idf adds ready-to-paste EnergyPlus SizingPeriod:DesignDay objects. Optional units ('imperial' default | 'metric'). Presentation: when calling with urls (multiple files), the response includes a comparisons array — render it as a markdown table to the user. Lead with the headline delta, not the raw data. No auth required; no credits charged.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | EPW URL to analyze (single file) | |
| urls | No | Multiple EPW URLs for comparison (first = baseline). Max 10. | |
| units | No | Output units (default: imperial). When 'metric', temperatures are °C, wind m/s, precip mm, distance km/m. | |
| config | No | Synthesize an EPW server-side and analyze it. Stats only — file never returned. lat + lon required. Same morph/UHI/event params as generate_weather_file. | |
| include_idf | No | Add ready-to-paste EnergyPlus SizingPeriod:DesignDay IDF objects to the response. AEC-facing. | |
| include_full_ashrae | No | Add ASHRAE 0.4%/1%/2% cooling DB + 99.6%/99% heating DB design conditions to the response. Free. | |
| include_improbability | No | Add EPWForge's stress-test improbability score (config mode only). Indicates how extreme the synthesized scenario is vs historical baselines. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that config mode runs generation pipeline server-side but returns only stats, and that tool is read-only with no auth needed. Could mention rate limits or file size constraints, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and outputs, second enumerates input modes and key constraint. No filler, front-loaded with essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes high-level outputs (HDD/CDD, monthly stats, etc.) but lacks detail on return format or structure, especially given no output schema. With siblings chart_weather and generate_weather_file, more specificity on output shape would help agents fully understand capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for top-level params (url, urls, config). Description adds value by clarifying config mode requires lat+lon and references sibling generate_weather_file for detail. However, it does not elaborate on config sub-parameters beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Compute' and specific outputs: design conditions, HDD/CDD, monthly stats, peak days. It specifies three input modes (single url, compare multiple, synthesize config), distinguishing it from siblings like generate_weather_file (returns EPW).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use each mode: 'Accepts a url (existing EPW), urls (compare 2+), or config (synthesize on the fly)'. States config mode returns only stats, not EPW, guiding choice vs generate_weather_file. Also notes 'No auth required; no credits charged'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chart_weatherAInspect
Render an SVG chart from EPW data. Five chart types: diurnal (~10 KB, monthly hourly profile), temp_carpet (heatmap of hour × day-of-year — ~30 KB preview / ~150 KB full), wind_rose (~12 KB, polar bars by direction × speed), monthly_boxplot (~6 KB, Q1/median/Q3 + whiskers per month), comparison (~10 KB, design-condition deltas across EPWs). Accepts url (single), urls (2+ for comparison), or config (synthesize on the fly). Config mode is anon-safe — runs pipeline, returns SVG only. No auth required. Token budget: SVGs are returned inline by default. Large outputs (>50 KB) auto-upload to Blob storage (when configured) and return a URL instead, keeping your context lean. Always check svg_size_kb in the response. Presentation: when handing the chart to the user, just link or embed it — don't narrate what's in it. Let the chart speak.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | EPW URL (single-EPW charts: diurnal, temp_carpet, wind_rose, monthly_boxplot) | |
| urls | No | EPW URLs for chart_type=comparison (first = baseline) | |
| config | No | Synthesize an EPW and chart it. Same params as generate_weather_file. SVG only — no file delivery. | |
| chart_type | No | Default: diurnal | |
| resolution | No | temp_carpet only. 'preview' (default) ~30 KB with 32 color buckets — visually identical at typical render sizes. 'full' ~150 KB with per-cell rgb() — use only when saving to file or when you specifically need exact color fidelity. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that no auth is required, config mode is anon-safe, and the tool returns SVG only. This gives a good sense of the tool's safety and output, though additional details on rate limits or data handling could further improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no redundancy. Front-loaded with the primary purpose, then quickly covers chart types and input modes, ending with a safety note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two chart types, multiple input modes, and a nested config object, the description adequately explains the main options. It lacks precise details about SVG output content beyond temperature and deltas, but overall is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining how parameters work together (e.g., chart_type triggers specific charts) and summarizing config mode behavior, which goes beyond individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool renders an SVG chart from an EPW file, explicitly naming two chart types (diurnal, comparison) and three input methods (url, urls, config). This distinguishes it from sibling tools like analyze_weather, generate_weather_file, and find_station.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear context on when to use each chart type and input mode, and notes that config mode is anon-safe. It does not explicitly state when not to use this tool, but the differentiation from siblings is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_stationAInspect
Search the GuzzStations catalog (17,000+ weather stations worldwide, self-hosted mirror of OneBuilding TMYx). Returns matching stations with EPW URLs ready to pass to analyze_weather or chart_weather. Optionally enriches with AMY extreme years (hottest / coldest / most-humid on record) and CMIP6 climate deltas. No auth required.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude — when set, results sorted by proximity | |
| lon | No | ||
| ssp | No | SSP scenario (only used with include_climate_deltas) | |
| year | No | Future horizon (only used with include_climate_deltas) | |
| query | No | Search by city / state (case-insensitive partial match) | |
| country | No | ISO 3-letter country code filter, e.g. 'USA', 'GBR' | |
| percentile | No | Warming percentile (only used with include_climate_deltas, default 50) | |
| max_results | No | Max stations (default: 10) | |
| include_amy_extremes | No | When true and lat+lon are set, also returns the hottest / coldest / most-humid years on record (per ERA5, 1950–present). Useful for picking AMY basis years. | |
| include_climate_deltas | No | When true with lat+lon+ssp+year, also returns the monthly CMIP6 delta-T per month and per variable. Lets agents reason about specific shifts before generating files. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies read-only search, no auth needed. However, lacks explicit statement about non-destructive behavior and omits sorting behavior (proximity when lat/lon provided). With no annotations, more detail would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundant info. Every sentence adds value: catalog scope, return use, authentication status.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple search tool with good schema coverage, but missing details about return format/structure (since no output schema). Could mention that results are sorted when lat/lon provided. Completeness is decent but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema does most of the work. Description adds no extra parameter details beyond the schema, meeting baseline but not exceeding. For example, it doesn't reiterate the sorting effect of lat/lon.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search the GuzzStations catalog' with specific resource name and count (17,000+), and notes return type (EPW URLs). Distinct from sibling tools analyze_weather and chart_weather, as indicated by 'ready to pass to'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly tells when to use (to find stations) and that results feed into siblings. Also notes 'no auth required'. Does not explicitly list when-not-to-use or alternatives, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_weather_fileAInspect
Generate and deliver an EPW or DDY file. The only paid tool — charges credits per call: 1 for a single file, 2 for a 4-file scenarios batch, 10 for a per-model CMIP6 ensemble. Requires auth (Bearer API key or OAuth). Free tier: 5 welcome credits at signup. For preview/analysis without download, use analyze_weather or chart_weather with config instead.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude, decimal degrees | |
| lon | Yes | Longitude, decimal degrees | |
| ssp | No | CMIP6 emission scenario | |
| uhi | No | Urban Heat Island preset | |
| year | No | Future horizon | |
| basis | No | Weather file basis (default: tmy) | |
| smoke | No | Enable wildfire smoke overlay | |
| events | No | Comma-separated events. Valid: heatwave, coldsnap, hothumid, coldwindy. Pairs auto-compound (heat+humid, cold+wind). | |
| format | No | Output format (default: epw) | |
| amy_year | No | Year for AMY basis | |
| ensemble | No | Generate a per-model CMIP6 ensemble (~20 EPWs, one per climate model). Costs 10 credits. Requires ssp + year. | |
| intensity | No | Per-event "type:1-7" intensity (1-10 with stress_test=true). 5 = typical extreme, 7 = severe ~50-yr return. | |
| scenarios | No | Batch mode — array of configs, each generated in parallel. Same shape as the top-level config. When set, top-level config params are ignored. Costs 1 credit per scenario (up to 10). | |
| percentile | No | Warming percentile (default: 50) | |
| tmy_period | No | TMYx vintage. Default 2011-2025. | |
| include_ddy | No | When format=epw, also include the matching DDY in the response (single-file only). | |
| stress_test | No | Unlock intensity 8-10. Default false. | |
| event_duration | No | Event length in days (3-30, default 14). **For stress-test scenarios use 14-21 days** — shorter durations don't capture sustained operational impact (charging schedules, occupancy patterns, equipment cycling). 7 days is too short for any design or resilience analysis. Use 7-10 only for transient short-duration events. | |
| intensity_auto | No | Auto-fill unspecified intensities from IPCC AR6 (default: true) | |
| smoke_duration | No | Smoke days (3-30, default: 7) | |
| smoke_intensity | No | Smoke severity 1-10 → peak AOD 0.1-6.0 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses that this is the only paid tool, charges credits per call (with specific costs for single file, scenarios batch, and ensemble), and requires authentication. It also mentions the free tier. However, it does not mention what happens if credits are insufficient or the exact delivery mechanism. Still, it provides substantial behavioral context beyond the bare minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that covers all essential points: purpose, cost, authentication, alternatives. It is front-loaded with the action. While it is informative and not excessively long, it could be slightly more concise by integrating the credit details more tightly. However, it remains well-structured for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 21 parameters, no output schema, and is a complex file generation tool, the description provides a good overview. It explains the main modes (single, batch, ensemble), the credit costs, and alternatives. It lacks details on error handling or output format specifics, but it covers the key contextual needs for an AI agent deciding whether to use this tool. The completeness is high but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage on parameters, so the description does not need to repeat that information. The description adds context about credit costs for the 'scenarios' and 'ensemble' parameters, but otherwise does not significantly enrich the parameter semantics beyond what the schema already provides. The score is baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates and delivers EPW or DDY files. It distinguishes itself from sibling tools (analyze_weather, chart_weather, find_station) by noting it is the only paid tool and that alternatives exist for preview/analysis. The verb 'Generate and deliver' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (to get actual file download) and when not (use analyze_weather or chart_weather for preview/analysis). It also covers credit costs, authentication requirements, and the free tier. This provides clear guidance on when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!