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
- Server Listing
- epwforge-mcp
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.6/5 across 5 of 5 tools scored.
Tools are mostly distinct: analyze_weather provides statistics, chart_weather produces charts, explore_design_conditions offers interactive single-site design conditions, find_station searches for stations, and generate_weather_file creates files. Some overlap exists (analyze_weather and explore_design_conditions both give design conditions; chart_weather and explore_design_conditions both produce charts), but descriptions clarify the differences in interactivity, scope, and output format.
All tool names follow a consistent verb_noun pattern in snake_case: analyze_weather, chart_weather, explore_design_conditions, find_station, generate_weather_file. No deviations or mixing of conventions.
Five tools is appropriate for the server's scope of EPW weather file analysis and generation. The set covers search, analysis, charting, interactive exploration, and file generation without being too sparse or overly numerous.
The tool surface covers the core workflow: finding stations, analyzing statistics, charting, interactive exploration, and generating files. Minor gaps include no direct file upload or modification tools, but the config mode in analyze_weather and chart_weather allows synthesis and manipulation for analysis, so the surface is mostly complete.
Available Tools
5 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. Token-saver: pass compact: true to get a ~10-field headline response (~100 tokens) instead of the full ~800-token payload. Use compact for sanity-checking, dashboards, or when chaining many calls; full when you need monthly arrays / peak days / full ASHRAE. 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. | |
| compact | No | Return a ~10-field headline-only response (~100 tokens) instead of the full ~800-token payload. Drops monthly arrays, peak days, n_hours, weather_basis blob. Good for sanity checks, dashboards, batched chained calls. Set to false (default) when you need the full payload. | |
| include_idf | No | Add ready-to-paste EnergyPlus SizingPeriod:DesignDay IDF objects to the response. AEC-facing. Ignored when compact=true. | |
| include_full_ashrae | No | Add ASHRAE 0.4%/1%/2% cooling DB + 99.6%/99% heating DB design conditions to the response. Free. Ignored when compact=true. | |
| 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?
With no annotations provided, the description fully discloses key behaviors: config mode returns only stats, not EPW content; compact reduces token count; optional parameters add specific data; no auth or credits. No contradictions or omissions are apparent.
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 well-structured with leading purpose, structured list of capabilities, and emphasis on key features (e.g., token-saver, presentation hint). It is somewhat long but each sentence adds value for a complex tool. Slightly more conciseness would improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of multiple modes and optional parameters, and no output schema, the description covers all major aspects: purpose, modes, token-saver, optional flags, and auth/credits. It could hint at expected response structure, but the detail provided is sufficient for an agent to invoke correctly.
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 covers all 8 parameters with 100% description coverage. The tool description adds value beyond schema by explaining config mode behavior, compact token savings, presentation hints for urls, and context for parameters like include_idf (AEC-facing) and include_improbability (config-only).
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 computes design conditions, HDD/CDD, monthly stats, and peak days for EPW files. It specifies three modes (single URL, multiple URLs for comparison, config for synthesis) and distinguishes itself from siblings (e.g., generate_weather_file for file generation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use each mode and the compact parameter for token saving. It mentions no auth or credits needed. However, it doesn't explicitly contrast with sibling tools (e.g., when to use chart_weather or explore_design_conditions), leaving some inference to the agent.
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. Eight 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), utci_carpet (~90 KB, outdoor heat-stress hour × day, colored by UTCI category — Bröde 2012, shaded Tmrt), economizer_carpet (~90 KB, air-side economizer free / integrated / locked-out hour × day under ASHRAE 90.1 high-limit), pv_tilt_azimuth (~60 KB, annual PV generation across full tilt × azimuth space, isotropic-sky POA at lat from EPW header — optimum orientation marked), solar_under_events (~12 KB, weekly GHI of the modified scenario vs the no-overlay reference; bands color event-affected weeks. Requires config — server runs the pipeline twice, with and without overlays), 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, utci_carpet, economizer_carpet, pv_tilt_azimuth) | |
| 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. | |
| pv_tilt | No | pv_tilt_azimuth only. Optional — marks the user's planned tilt (deg, 0=horizontal) on the heatmap alongside the optimum. | |
| econ_mode | No | economizer_carpet only. 'drybulb' (default) limits OA by Tdb; 'enthalpy' limits by moist-air enthalpy — more honest in humid climates (captures latent load). | |
| chart_type | No | Default: diurnal | |
| pv_azimuth | No | pv_tilt_azimuth only. Optional — marks the user's planned compass azimuth (deg, 0=N, 180=S) on the heatmap. | |
| 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. | |
| econ_high_limit_f | No | economizer_carpet only. ASHRAE 90.1 high-limit shutoff. Defaults: 75°F (drybulb mode) or 28 BTU/lb (enthalpy mode). | |
| econ_supply_air_f | No | economizer_carpet only. Supply-air temperature setpoint (°F). Default 55. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description covers all behavioral traits: output size ranges, blob storage auto-upload, no auth required, anon-safe config mode, pipeline execution details, and token budget. Exceptionally transparent.
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?
Comprehensive but slightly lengthy; front-loaded with purpose and chart types. Every sentence adds value, but could benefit from structured formatting for easier scanning. Still effective for AI agent.
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 10 parameters, no output schema, and complex behavior, the description covers all input modes, parameter relationships, output handling, and token budget. Only minor gap: explicit return format (SVG or URL) is implied but clear.
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%; baseline 3. Description adds significant meaning: explains chart type specifics, conditional parameters, default values, and usage notes (e.g., stress-test durations). Enhances understanding 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?
The description clearly states it renders SVG charts from EPW data, lists eight specific chart types with details, and distinguishes input modes (url, urls, config). It differentiates from sibling tools like generate_weather_file and analyze_weather.
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?
Provides extensive usage guidance: when to use each chart type, parameter dependencies, token budget, and presentation advice. Lacks explicit contrast with all siblings but offers clear context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explore_design_conditionsAInspect
Interactive single-site design-conditions explorer. Returns full ASHRAE design conditions + diurnal chart for the requested scenario. In MCP Apps-capable hosts (Claude Desktop, ChatGPT, VS Code, Goose), the response renders as a widget with sliders for SSP / year / percentile / UHI — dragging a slider re-calls this tool live. Use when a user wants to interactively tune a single site. For multi-site comparison, use analyze_weather(urls=[...]) instead. Defaults to present-day TMY (no morph) — pass ssp+year for future scenarios. P75 default percentile is design-realistic; P50 underestimates the tail. No auth required.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude, decimal degrees | |
| lon | Yes | Longitude, decimal degrees | |
| ssp | No | CMIP6 emission scenario. Omit for present-day TMY. ssp370 is the recommended high-end; ssp585 (SSP5-8.5) is an opt-in extreme stress-test pathway for worst-case analysis. | |
| uhi | No | Urban Heat Island preset | |
| year | No | Future horizon. Pair with ssp. | |
| percentile | No | Warming percentile. P75 design-realistic; P50 median. | |
| allow_custom_location | No | Required when no OneBuilding station within 50 km |
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 discloses interactive widget behavior, re-calling on slider drag, and lack of auth requirements. The description adds value beyond what annotations would provide, though it does not mention rate limits or data volume.
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 compact paragraph with front-loaded main purpose. Every sentence adds value, covering purpose, widget behavior, usage guidance, and defaults. No waste.
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 7 parameters, 2 required, and no output schema, the description covers return values ('full ASHRAE design conditions + diurnal chart') and interactive rendering. It is mostly complete, though output format details are not described beyond the widget context.
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 extra context: defaults to present-day TMY, P75 realistic, ssp370 recommended, ssp585 as stress-test, and allow_custom_location requirement. This goes beyond what the schema alone provides.
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 starts with 'Interactive single-site design-conditions explorer' and explicitly contrasts with sibling tool analyze_weather for multi-site comparison. It clearly states the verb (explore/returns) and the resource (design conditions for a single site).
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 states when to use ('user wants to interactively tune a single site') and when not ('For multi-site comparison, use analyze_weather instead'). It also provides guidance on defaults (P75 realistic, SSP usage) and authentication (none).
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). ssp370 is the recommended high-end; ssp585 (SSP5-8.5) is an opt-in extreme stress-test pathway for worst-case analysis. | |
| 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?
No annotations exist, so the description carries full transparency burden. It discloses auth requirements, catalog size, and conditional enrichment behavior. It could elaborate on sorting behavior when lat/lon are provided, but current detail is sufficient.
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 two sentences, tightly packed with information. Every clause adds value: catalog source, number of stations, output URL usage, optional features, and auth status. No word is wasted.
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 complex tool with 10 parameters and no output schema, the description covers the main features, usage conditions, and expected outputs. It mentions the catalog size, enrichment options, and prerequisites. The lack of return format details is acceptable given no output schema, and the description is otherwise 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?
With 90% schema coverage, the description adds significant value: it explains that lat+lon are used for proximity sorting, that include_amy_extremes and include_climate_deltas require lat+lon, and it provides extra context on SSP scenarios (e.g., recommending ssp370). This goes beyond what the schema provides.
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 explicitly states the verb ('Search'), the resource ('GuzzStations catalog'), and the output ('matching stations with EPW URLs'). It also notes that results are ready for sibling tools, distinguishing its purpose from analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: no auth required, optional enrichment with AMY extremes or CMIP6 deltas, and that lat/lon enables proximity sorting. It does not explicitly state when not to use this tool, but the sibling list implies its role as a data-fetching step.
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. ssp370 is the recommended high-end for design; ssp585 (SSP5-8.5) is an opt-in extreme stress-test pathway (~4.4°C, low likelihood per IPCC AR6 / CMIP7) for worst-case analysis. | |
| 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?
No annotations provided, so description carries full burden. It discloses credit costs (1,2,10), auth requirements, free tier credits, and that it generates and delivers files. Does not cover rate limits or idempotency, but cost structure is well explained.
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?
Single paragraph, front-loaded with main action, no wasted words. Includes key information concisely.
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 21 params, no output schema, and no annotations, the description provides essential context: credits, auth, alternatives. Lacks return format details, but sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description adds context on credit costs per file/batch/ensemble and alternatives, but does not significantly enhance parameter meaning 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?
The description clearly states that the tool generates EPW or DDY files, specifies its paid nature, and distinguishes from sibling tools like analyze_weather and chart_weather for preview/analysis without download.
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 provides guidance on when to use this tool versus alternatives: 'For preview/analysis without download, use analyze_weather or chart_weather with config instead.' Also details credit costs and auth requirements.
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!
Your Connectors
Sign in to create a connector for this server.