epwforge-mcp

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description fully discloses behavior: config mode synthesizes server-side but returns only stats, no EPW content; token-saver compact option; no auth/credits required; presentation guidance for comparisons. All relevant behavioral traits are covered.

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?

Description is lengthy but well-structured with front-loaded purpose and logical grouping. Every sentence adds unique value, though some details (e.g., event_duration ranges) could be moved to parameter descriptions to reduce verbosity.

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?

Despite no output schema, description explains response structure (comparisons array, markdown table rendering, compact vs full payload). All optional flags are documented with their effects. The tool's complexity is fully addressed.

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%, but description adds significant value: explains compact token savings (~100 vs ~800 tokens), config mode limitations, include options (idf, full_ashrae, improbability), units default, and urls first-as-baseline. This goes well beyond basic schema definitions.

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 computes design conditions, HDD/CDD, monthly stats, and peak days for EPW files. It distinguishes from siblings like chart_weather (charts) and generate_weather_file (generates EPWs) by specifying analysis of existing or synthesized 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?

Provides clear modes (url, urls, config) with appropriate contexts, and guidance on compact vs full output. Lacks explicit when-not-to-use or alternatives to siblings, but the modes cover the intended use cases sufficiently.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses auth requirements (none), token budget auto-upload, and chart sizes. Mentions that config mode is anon-safe. Does not hide behavioral traits. With no annotations, this is thorough.

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?

While lengthy, every sentence provides actionable information. Structured logically: purpose, chart types, input guidance, token budget, presentation. Could be slightly more concise but not wasteful.

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?

Comprehensive for a tool with 10 parameters and multiple modes. Covers token budget, auth, and sizing. Lacks explicit error handling or return format details beyond SVG/URL, but given complexity, it's well-done.

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?

Full schema coverage with 100% parameter descriptions. Tool description adds significant context: chart sizes, usage scenarios for each parameter, and warnings (e.g., event_duration min 14 for stress-test). Exceeds baseline of 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?

Specific verb 'Render' and resource 'SVG chart from EPW data'. Lists all chart types with sizes and brief descriptions. Clearly differentiated from sibling tools that analyze, explore, find stations, or generate weather 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?

Clearly states when to use url, urls, or config, and which chart types apply. Provides guidelines on token budget and presentation. Lacks explicit exclusions or comparison to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description thoroughly explains interactive widget behavior, live re-calling on slider drag, default present-day TMY, percentile implications, and that no auth is required.

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?

Well-structured with front-loaded purpose, then widget behavior, then sibling reference, then defaults. Concise enough, though could be slightly shorter without losing clarity.

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?

Covers output (ASHRAE design conditions + diurnal chart), interactive behavior, and defaults. Missing explicit mention of the 'allow_custom_location' parameter and response details outside the widget, but given the widget behavior, this is adequate.

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 the default percentile (P75 design-realistic), that ssp585 is deprecated, and the default scenario (TMY).

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 'explore' and the resource 'design conditions' for a single site, and distinguishes itself from the sibling tool analyze_weather 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 says 'Use when a user wants to interactively tune a single site' and provides an alternative: 'For multi-site comparison, use analyze_weather(urls=[...]) instead.' Also covers default behavior and authentication.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states that no authentication is required and describes optional enrichment conditions. However, it does not disclose error handling, rate limits, or what happens when no stations match. For a search tool, the transparency is adequate but not comprehensive.

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 four sentences, concisely covering purpose, optional features, and auth requirements. It front-loads the main function and then details enrichments. Every sentence adds value, though there is a minor redundancy in mentioning 'no auth required' after the primary purpose.

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 10 parameters and no output schema, the description explains the optional enrichment conditions and links to sibling tools. It does not describe the return format or pagination, but the mention of 'EPW URLs ready to pass to...' implies the output structure. Reasonably complete for a search 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?

With 90% schema description coverage, the schema already defines parameter semantics. The description adds context about the catalog (self-hosted mirror) and the relationship to sibling tools, but does not clarify parameter syntax or constraints beyond what the schema provides. Baseline score of 3 is appropriate due to high schema coverage.

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 searches a catalog of weather stations, returns EPW URLs for use with sibling tools, and optionally enriches with AMY extremes and CMIP6 deltas. It distinguishes itself from siblings by specifying the output's downstream use.

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 says to use this tool for searching stations and optionally enriching results. It also mentions passing results to analyze_weather or chart_weather, providing context for when to use siblings. However, it does not explicitly state when not to use this tool or suggest alternatives like explore_design_conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses key behaviors: charges credits (with specific costs per call type), requires auth, and free tier credits. However, lacks description of response format (e.g., download link or binary) and rate limiting, which would be needed for full transparency given no annotations.

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?

Five sentences, each essential: purpose, cost breakdown, auth requirement, free tier info, and sibling alternatives. No redundancy, front-loaded with primary action.

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?

Covers cost, auth, and alternatives well. However, with 21 parameters and no output schema, the agent lacks information about the response format (how the file is delivered). This gap slightly reduces completeness.

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 all 21 parameters with rich descriptions, so baseline is 3. Description adds value by linking parameters to credit costs (e.g., scenarios batch costs 2, ensemble costs 10), providing global context not present in 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 generates and delivers EPW or DDY files, distinguishes itself as the only paid tool, and explicitly contrasts with sibling tools (analyze_weather, chart_weather) for preview/analysis use cases.

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 explicit guidance on when to use (need file) vs. when to use alternatives (preview/analysis without download), and mentions prerequisites like auth and credit costs, leaving no ambiguity about usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.