Skip to main content
Glama

solar-home-incentives

by com.energyaisolution

estimate_production

Honest-range annual solar production estimate (kWh/year ± band, with assumptions) for a ZIP code, from either a proposed system size (kW) or a monthly bill. Use to sanity-check installer quotes or size a system before talking to anyone. [20 anonymous calls/caller/24h; then 100 free calls/key/30d; active Builder required for sustained informational use]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countryNoISO 3166-1 alpha-2 country code. Omit for US. Non-US estimates use a default solar resource and say so honestly.
zipCodeNoOptional postal code of the property. US: 5-digit ZIP. Other countries: your local postal code (pass country too). Omit it to use documented national assumptions.
systemKwNoProposed solar system size in kW-DC. Omit to have a size recommended from the bill.
monthlyBillUsdNoAverage monthly electric bill in USD (used to size a system when systemKw is omitted).

TDQS

A4.5/5.0
Behavior4/5

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 that estimates are honest-range with assumptions, includes rate limits (20 anonymous calls/caller/24h, 100 free calls/key/30d), and notes the Builder requirement for sustained use. This goes beyond basic functionality and covers usage constraints, though it doesn't explicitly state read-only behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a rate-limit note, with the main purpose front-loaded. Every sentence earns its place, including the usage guidance and rate limit disclosure. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description tells the user what to expect (kWh/year ± band) and covers both input modes. It also addresses limitations (non-US assumptions) and usage policies, making it complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 clarifying the either/or relationship between systemKw and monthlyBillUsd, which is not evident from the schema alone. It also implies zipCode is central to the estimate, reinforcing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool produces an annual solar production estimate in kWh/year with a range and assumptions, for a ZIP code, from either system size or bill. This specific verb+resource+scope distinguishes it from sibling tools like check_incentives or get_quote_link, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use it for sanity-checking installer quotes or sizing a system before talking to anyone, providing clear context. It doesn't name alternative tools, but the use cases are definitive and distinguish this tool's role from siblings.

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

All solar-home-incentives toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation4/5

Most tools are clearly distinct, but the three installer-related tools (find_local_installers, get_quote_link, route_lead) share the purpose of connecting users to installers and require careful reading of descriptions to avoid misselection. Other overlapping pairs like get_guide/list_guides and check_incentives are well differentiated by dynamic vs. static content.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in lowercase snake_case (check, create, estimate, find, get, list, route). Multiple get_* tools are uniform, and the naming makes the action and object clear. No mixed conventions or vague verbs.

Tool Count5/5

With 10 tools, the server is well-scoped. Each tool serves a distinct role: informational lookup, estimation, guide access, installer connection, and commercial account management. The count is within the ideal 3–15 range and matches the server's broad but coherent purpose.

Completeness5/5

The tool surface covers the core workflows: incentive checks, production estimates, guide exploration, installer discovery/quoting/lead routing, and commercial key management. No significant gaps are apparent; the only minor limitation is that installer tools are US-focused, but that seems intentional given the US-based guides and incentives data.

Resources