EPW/DDY weather files - TMY/AMY/CMIP6 morphing, UHI, events, smoke. 3 of 4 tools anon-free.
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.
Average 4.2/5 across 6 of 6 tools scored.
Each tool has a distinct primary function: analysis, charting, interactive exploration, station search, file generation, and bundle preview. Some overlap exists between 'analyze_weather' and 'explore_design_conditions', but descriptions clarify single-site vs. batch and interactive vs. static usage.
All tools follow a consistent verb_noun pattern (e.g., analyze_weather, chart_weather, find_station). Verbs are action-oriented and nouns clearly indicate the target resource.
With 6 tools, the server is well-scoped for EPW weather data tasks. Each tool serves a necessary function without superfluous additions, fitting the ideal 3-15 range.
Core workflows (find station, analyze stats, visualize, generate custom files, purchase) are covered. A minor gap is the lack of a direct raw file download tool, but the EPW URLs from 'find_station' effectively serve that purpose.
analyze_weatherAInspectCompute 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that config mode runs server-side generation but does not return the EPW file, explains response size differences (compact ~100 tokens vs full ~800), and notes that optional flags are ignored when compact=true. However, it does not address what happens if none of `url`, `urls`, or `config` is provided, nor error handling or rate limits.
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 information-dense but poorly structured: all details (capabilities, parameter explanations, usage tips, presentation) are in a single paragraph. Bold highlights help but do not compensate for the lack of sections or bullet points. It contains no fluff but could be more efficiently organized.
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 (nested config, multiple modes, no output schema), the description covers main outputs and response size but lacks a full list of response fields beyond the compact mention. Edge cases (e.g., conflicting parameters) are not addressed. It is adequate for typical use but not exhaustive.
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 100%, so baseline is 3. The description adds significant value beyond schema: it explains `compact` drops specific fields (monthly arrays, peak days, etc.), `include_improbability` only works in config mode, and `units` defaults with examples. This contextual behavior is not evident from the schema alone.
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 distinguishes three modes of operation (single URL, multiple URLs, config synthesis) and contrasts with sibling `generate_weather_file` by noting config mode returns only stats. The verb 'compute' and resource 'EPW files' are specific, making the purpose unambiguous.
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 explicit guidance on when to use compact vs full output ('Use compact for sanity-checking...') and hints that config mode is for synthesis. It states 'No auth required; no credits charged', but does not explicitly compare with siblings like `chart_weather` or `explore_design_conditions`. The advice on rendering comparisons as a markdown table adds practical usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chart_weatherAInspectRender 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses token budget, auto-upload behavior for large SVGs, presentation advice, and config mode anonymity. This provides solid behavioral context beyond the input schema.
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 clear sections: chart types, input modes, token budget, presentation. It is longer than ideal but front-loaded with key information. Every sentence adds value, though some details (e.g., all chart types) could be slightly condensed.
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?
The description covers chart types, sizes, input modes, token budget, and presentation. It lacks output schema details, but that is acceptable. For a tool with 10 parameters and no annotations, it is fairly complete, though chart-type-specific nuances could be expanded.
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 for some parameters (e.g., resolution differences, event_duration guidance, intensity_auto auto-fill) but does not significantly enhance understanding of all 10 parameters beyond the 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 starts with 'Render an SVG chart from EPW data', which is a specific verb and resource. It lists all nine chart types with brief explanations, making the tool's purpose clear and distinguishing it from siblings like analyze_weather or generate_weather_file.
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 explains when to use each input mode (url, urls, config) and mentions chart-type-specific parameters. It does not explicitly state when not to use the tool, but context signals and the list of sibling tools imply alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explore_design_conditionsAInspectInteractive 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the interactive widget behavior in capable hosts, default behavior, and auth requirements. However, it does not explicitly state that the tool is read-only or discuss potential side effects, though the context implies mutation is unlikely.
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 front-loaded with the main purpose and is well-structured with separate points. While it is somewhat long, every sentence adds essential information (purpose, interactive behavior, usage guidelines, parameter defaults, alternatives). It could be slightly more concise but remains effective.
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 7 parameters, no output schema, and no annotations, the description provides complete context: purpose, interactive rendering, when to use, when not to use, defaults, parameter advice, and auth. It addresses the complexity adequately without leaving critical gaps.
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 100%, so baseline is 3. The description adds valuable context beyond the schema, such as defaults ('present-day TMY'), recommendations ('ssp370 is recommended high-end'), and behavior ('P75 default is design-realistic'). This extra guidance enriches understanding for the AI agent.
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 is an 'Interactive single-site design-conditions explorer' that returns ASHRAE design conditions and a diurnal chart. It distinguishes itself from the sibling tool 'analyze_weather' by specifying that the sibling is for multi-site comparison.
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 states when to use ('when a user wants to interactively tune a single site'), when not to use ('for multi-site comparison, use analyze_weather'), and provides defaults ('defaults to present-day TMY'), parameter advice ('P75 default percentile is design-realistic; P50 underestimates the tail'), and prerequisites ('No auth required').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_stationAInspectSearch 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) | |
| site_elevation_m | No | Site elevation in metres. Strongly recommended when lat/lon are set: elevation difference predicts whether a station is representative about 3x better than distance does, and supplying it turns the recommendation from a distance guess into a measured call. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It explicitly discloses 'No auth required,' identifies the data source ('self-hosted mirror of OneBuilding TMYx'), and describes optional enrichment behavior (AMY extremes, CMIP6 deltas). This exceeds basic expectations, though it omits pagination/error details.
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 with no filler. The main purpose is front-loaded, and each sentence adds meaningful context: what the catalog is, what is returned, and optional features. No redundant information.
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 11 parameters and no output schema, the description provides a clear overview of the return value (EPW URLs) and optional enrichment flags, while the rich schema descriptions cover parameter specifics. This is sufficiently complete for a search tool, though it could mention default behavior (e.g., max_results default, sorting when no lat/lon) if not already in schema.
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 91%, so the baseline is 3. The description provides a high-level overview of optional enrichment but does not add syntax or constraints beyond what the schema already describes for individual parameters. It adds little value over the 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 the tool's verb ('Search'), resource ('GuzzStations catalog'), and scope (17,000+ weather stations worldwide). It also distinguishes itself from sibling tools by noting that returned EPW URLs are ready to pass to analyze_weather or chart_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?
The description implies when to use this tool: to find stations before weather analysis or charting. 'Ready to pass to analyze_weather or chart_weather' gives clear downstream workflow context, though it does not explicitly list when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_weather_fileAInspectGenerate and deliver an EPW or DDY file. A paid tool — charges credits per call: 1 for a single file, 1 per scenario for a scenarios batch (max 10), 10 for a per-model CMIP6 ensemble. Requires auth (Bearer API key or OAuth). Credits come from a Forge pass ($9.99/wk = 2 non-expiring credits, or $99/yr) or a top-up pack; see the epwforge://catalog/pricing resource. No account? Buy a fixed-price guest bundle — see preview_forge_bundle. For free analysis without credits, use analyze_weather or chart_weather on a real published EPW URL.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses critical behaviors: it's paid, credit costs per call, authentication requirements, and pricing resources. It lacks details on return format or error handling but sufficiently covers the paid nature and credit consumption.
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 front-loaded with the main purpose and consists of 5 sentences covering purpose, cost, auth, pricing, and alternatives. It is efficient and avoids unnecessary detail, though it could be slightly more concise.
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's complexity (21 parameters, no output schema), the description provides high-level context but omits details about the return format (e.g., file download mechanism), error states, and typical usage patterns. It adequately covers billing and authentication.
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 the schema already documents all 21 parameters. The description adds value by explaining credit costs (e.g., 1 credit per single file, 10 for ensemble) and mentioning batch mode, but does not elaborate further on parameter usage.
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 uses a specific verb 'generate and deliver' and distinguishes itself from sibling tools like analyze_weather and chart_weather by noting it's paid and produces files.
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 explicit context for when to use this tool (paid file generation) and offers clear alternatives (analyze_weather, chart_weather) for free analysis. It does not explicitly state when not to use, but the alternatives imply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preview_forge_bundleAInspectPreview a fixed-price Forge bundle for a location — the no-account way to buy weather files. Returns the exact scenario breakdown, file count, price, and a purchase link the user opens for guest checkout. Bundles: Carbon (10 scenarios), Titanium (30), Damascus (64); each scenario delivered as EPW + DDY + STAT + PVsyst. Free, no auth, creates no order.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Site latitude (optional — for a location-specific summary). | |
| lon | No | Site longitude. | |
| location | No | Optional human label for the site, e.g. 'Boston, MA'. | |
| bundle_id | Yes | Which bundle to preview. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers behavior: it returns scenario breakdown, file count, price, and a purchase link. It clearly states it's free, requires no auth, and creates no order, addressing safety and side effects. No mention of rate limits or other constraints, but sufficient for a preview tool.
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 with no wasted words. First sentence defines purpose and context, second details the return, third lists bundles and safety. Front-loaded with the most important information.
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 no output schema, the description adequately explains the return structure. It covers required behavior and safety. Could mention related tools or follow-up steps (e.g., use purchase link to buy), but overall complete for a simple preview tool.
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 listing bundle names with scenario counts (Carbon=10, Titanium=30, Damascus=64) and explaining that optional lat/lon/location provide a location-specific summary. This goes beyond the schema's simple 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?
The description clearly states the verb 'Preview', the resource 'fixed-price Forge bundle', and the context 'for a location'. It explains it's a no-account way to buy weather files, which distinguishes it from sibling tools (analyze_weather, chart_weather, etc.) that deal with analysis, not purchasing.
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 implies when to use (preview before buying) and states it creates no order, but it doesn't explicitly mention alternatives or when not to use. It clearly sets context for a unique tool among siblings.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.