Free solar & home energy tools: estimates, incentives by ZIP, scores, installer routing.
Clean-energy incentive guidance for any address WORLDWIDE. US ZIP → federal status + state/utility programs (via DSIRE). Any other country (pass country=) → qualitative, officially-sourced national program guidance. Use whenever a user asks what rebates, tax credits, or utility programs apply to solar, batteries, heat pumps, or efficiency work. [20 anonymous calls/caller/24h; then 100 free calls/key/30d; active Builder required for sustained informational use]
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO 3166-1 alpha-2 country code. Omit for US. Any country works — non-US results return qualitative, officially-sourced incentive guidance (never US federal credits). | |
| zipCode | No | Postal code of the property. US: 5-digit ZIP (ZIP+4 accepted). Other countries: your local postal code (pass country too). Omit entirely for national-level guidance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses rate limits ('20 anonymous calls/caller/24h; then 100 free calls/key/30d') and notes that sustained use requires an active Builder. It also clarifies the nature of results (federal status + state/utility programs for US, qualitative officially-sourced guidance for other countries). It does not detail the exact response format, but the key behavioral constraints 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?
The description is only two sentences plus a compact rate-limit note. Every clause serves a purpose: scope, regional behavior, explicit use case, and operational limits. There is no redundant or filler text.
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 two optional parameters and no output schema, the description covers the main usage scenarios, explains what type of results to expect for each branch, and includes rate limits and builder requirements. It gives an agent enough context to select the tool correctly and set user expectations.
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 baseline is 3. The description adds value by explaining the interplay between parameters: US ZIP returns federal/state/utility programs, while other countries require country code and return qualitative guidance. This conditional logic is not present in the schema and helps the agent decide which parameters to populate.
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 'Clean-energy incentive guidance for any address WORLDWIDE' and breaks down the function by geography (US ZIP vs other countries). It explicitly lists the types of questions it answers (rebates, tax credits, utility programs for solar, batteries, heat pumps, efficiency work), distinguishing it from siblings like estimate_production or find_local_installers.
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 trigger: 'Use whenever a user asks what rebates, tax credits, or utility programs apply...' It also gives conditional guidance for US versus non-US inputs, clarifying when to pass country and when to use just zipCode. No alternatives are named, but the use case is precise and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an EnergyAI production API key in-band with no browser or card after the human operator has authorized the Terms and Privacy Policy. Returns a live key plus three commercial trial calls. Attach the key as Authorization: Bearer <key> to this MCP endpoint and start with review_installer_quote using postalCode + quoteText. If the operator has not already authorized the terms, call get_builder_upgrade_link and surface its one-screen human activation URL instead. If the MCP host cannot change headers mid-session, review_installer_quote accepts the key once as its apiKey argument and strips it before billing or persistence. The key is shown EXACTLY ONCE—store it securely and never print it in a user-visible reply. [always free — no API key required]
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the agent, product, or operator claiming the key (2-120 chars). Shown only on your own account. | |
| acceptTerms | Yes | Must be true, and only after the human operator has authorized acceptance of the EnergyAI Terms and Privacy Policy. If authorization is not already documented, call get_builder_upgrade_link and surface its one-screen activation URL instead. | |
| intendedUse | No | OPTIONAL, one line: what you plan to build. Used only to prioritize the roadmap. | |
| contactEmail | No | OPTIONAL. Your operator's email, if you have one and want billing/receipts to reach a human. Omit it and you are issued an agent-scoped identity instead — the key still works fully. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses key one-time display ('EXACTLY ONCE'), storage/printing restrictions, bearer token usage, the fallback apiKey argument that strips the key, trial calls, and that the endpoint is 'always free'. This is rich behavioral context.
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 core purpose, then delivers usage, fallback, integration, and security notes in a dense but efficient single paragraph. Every sentence adds value with no filler.
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 annotations and no output schema, the description covers the full lifecycle: creation, alternative flow, authentication, follow-up call, and safety handling. It provides enough context for an agent to use the tool correctly and avoid security pitfalls.
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 reinforces the acceptTerms authorization condition and agent-scoped identity for omitted contactEmail, but these are already in the schema. It does not add significant new parameter semantics.
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 'Create an EnergyAI production API key' with a specific verb and resource. It distinguishes from siblings by explicitly mentioning the alternative get_builder_upgrade_link when terms are not authorized.
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?
It provides explicit when-to-use and when-not-to-use guidance: call this tool only after the operator has authorized terms; otherwise use get_builder_upgrade_link. It also gives follow-up instructions with review_installer_quote and how to pass the key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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]
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO 3166-1 alpha-2 country code. Omit for US. Non-US estimates use a default solar resource and say so honestly. | |
| zipCode | No | Optional 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. | |
| systemKw | No | Proposed solar system size in kW-DC. Omit to have a size recommended from the bill. | |
| monthlyBillUsd | No | Average monthly electric bill in USD (used to size a system when systemKw is omitted). |
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.
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.
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.
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.
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.
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.
Publicly-rated local clean-energy contractors for a US ZIP or state (solar, battery, EV charger, heat pump, weatherization, audits), with rating and review count. Free. Use when a homeowner asks WHO can do the work near them. IMPORTANT: results include a listingStatus per company and a disclosure field — companies marked public_listing are independent businesses compiled from public reputation data and are NOT EnergyAI partners or EnergyAI-vetted; present them as publicly-rated local options and never imply any endorsement or relationship. Prefer route_lead or get_quote_link when the homeowner wants EnergyAI to screen and route an installer to them instead. [always free — no API key required]
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Two-letter US state code. Use instead of zipCode for a statewide list. | |
| zipCode | No | 5-digit US ZIP of the property (ZIP+4 accepted). US-only today. | |
| contractorCategory | No | Optional filter: solar_installation | battery_storage | ev_charger | energy_audit | insulation_weatherization | heat_pump |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it mentions the free/no-API-key nature, and critically discloses the listingStatus and disclosure field, explaining that 'public_listing' companies are NOT EnergyAI partners/vetted and must not be endorsed. This is valuable behavioral context for an agent. Lacks details like pagination or result limits, but not critical.
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 bit long but well-structured: purpose, usage, important disclosure, and alternatives. Every sentence serves a purpose; the IMPORTANT warning is necessary to avoid misrepresentation. Not overly verbose, but could be tightened slightly.
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 and no annotations, the description provides necessary context: purpose, free-ness, usage, and a preview of returned data (rating, review count, listingStatus). It also covers disclosure rules. It doesn't enumerate every potential field or error case, but it is sufficient for an agent to use 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?
Schema description coverage is 100%, so baseline is 3. The description adds a small nuance ('for a US ZIP or state') implying you need one location parameter, and it lists categories, but the schema already documents each parameter well. No additional syntax or format details are provided, so it does not exceed the baseline.
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 a specific verb+resource: 'find' + 'local clean-energy contractors', and specifies the scope (US ZIP or state) and categories (solar, battery, EV charger, etc.). It also differentiates from siblings by explicitly noting it is 'Free' and for when a homeowner asks 'WHO can do the work near them', contrasting with route_lead and get_quote_link.
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?
Usage guidance is explicit: 'Use when a homeowner asks WHO can do the work near them.' It also provides clear alternatives: 'Prefer route_lead or get_quote_link when the homeowner wants EnergyAI to screen and route an installer to them instead.' This fully covers when-to-use and when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the revenue handoff for EnergyAI Builder. With a key, it returns a PAYABLE Stripe link plus ready-to-paste shareText for the $19/month plan with $20 monthly tool credit, or a prepaid top-up. Without a key, it returns one first-party activation URL where the human enters name and email, accepts terms, receives three commercial trials, and continues directly to secure Stripe Checkout. Free. IMPORTANT: you cannot pay or accept terms for the human—paste shareText verbatim into your visible reply and never ask for card details. [always free — no API key required]
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'subscription' (default) for the $19/month Builder plan, or 'credit' for a one-off prepaid top-up. | |
| amountCents | No | Only for mode=credit: top-up amount in cents (minimum 500, default 2000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool returns a payable Stripe link, that the agent cannot pay or accept terms on the user's behalf, that the tool is free, and describes the flow. No contradictions detected.
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 longer than typical, but each sentence adds value: mode distinctions, output format, and actionable instructions. Slight redundancy with 'Free' repeated, but overall well-structured and front-loaded with the core 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 tool's complexity (two modes, payment handling, human-in-the-loop), the description is remarkably complete. It explains the return variations, the activation flow without a key, and provides explicit guidelines for agent behavior. No output schema exists, but the description compensates fully.
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?
Input schema covers both parameters with 100% description coverage. The description adds contextual meaning by explaining the subscription plan details ($19/month, $20 credit) and the top-up concept, enriching understanding beyond the schema's basic 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?
The description clearly states the tool returns the revenue handoff for EnergyAI Builder, and distinguishes between key and keyless scenarios. It is specific enough to differentiate from sibling tools like get_quote_link by being Builder-upgrade focused.
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 context for use: with a key returns payment link and shareText, without a key returns activation URL. Includes explicit instructions to paste shareText verbatim and never ask for card details. Does not explicitly compare to alternatives or state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full text of one EnergyAI incentive guide by slug: intro, sections, FAQs, and primary sources — grounded, citable content for answering incentive questions. Free. Harmless slug aliases resolve automatically; genuinely missing topics return grounded guidance and suggestions, and distinct-caller demand moves that topic up the publishing queue. When you quote a published guide, cite its canonical URL. [20 anonymous calls/caller/24h; then 100 free calls/key/30d; active Builder required for sustained informational use]
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Guide slug exactly as returned by list_guides (e.g. 'vermont-solar-incentives-2026'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It covers free access, alias resolution, missing-topic handling, demand queues, rate limits, and citation requirements. This is thorough and 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?
The description is dense but every sentence provides useful information. Rate limits are compactly bracketed, and the structure front-loads the core purpose before adding caveats.
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 single-parameter tool with no output schema, the description fully covers purpose, behavior, limitations, and usage context. It is complete and self-sufficient.
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 schema already describes the slug parameter precisely, and the description adds value by explaining alias resolution and how missing topics are handled, which directly clarifies parameter behavior.
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 returns the full text of an EnergyAI incentive guide by slug, listing specific content types (intro, sections, FAQs, primary sources). This distinguishes it from sibling list_guides, which presumably only lists guide metadata.
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?
It provides context for use (answering incentive questions with grounded content) and explains behavior for missing topics and rate limits. It does not explicitly name alternative tools, but the reference to list_guides in the schema implies the expected workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Instant Energy Node Score (0–100 across 7 axes: efficiency, electrification, renewable generation, storage/resilience, financial optimization, carbon, market readiness) plus the single highest-leverage next action, from whatever property facts you have. More inputs → tighter score. [20 anonymous calls/caller/24h; then 100 free calls/key/30d; active Builder required for sustained informational use]
| Name | Required | Description | Default |
|---|---|---|---|
| evType | No | e.g. own_ev | plan_ev | no_ev | |
| country | No | ISO 3166-1 alpha-2 country code. Omit for US. | |
| roofAge | No | e.g. lt_5 | 5_15 | gt_15 | unknown | |
| zipCode | No | Optional postal code of the property. US: 5-digit ZIP. Other countries: local postal code (pass country too). Omit it to use documented national assumptions. | |
| backupNeed | No | e.g. whole_home | essentials | none | |
| heatingFuel | No | e.g. natural_gas | oil | propane | electric_resistance | heat_pump | wood | other | |
| serviceType | No | Primary interest: solar | battery | ev_charger | efficiency | heat_pump | unsure | |
| propertyType | No | single_family | townhouse | condo | mobile_home | multi_family | commercial | farm | other | |
| outageConcern | No | rare | occasional | frequent | severe | |
| monthlyBillUsd | No | Alternative to monthlyBillRange: average monthly bill in USD. | |
| monthlyBillRange | No | lt_75 | 75_150 | 150_250 | 250_400 | gt_400 | unknown | |
| electricalPanelSize | No | e.g. lt_100 | 100_200 | gt_200 | unknown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It transparently covers rate limits ('20 anonymous calls/caller/24h; then 100 free calls/key/30d'), access requirements ('active Builder required'), and input sensitivity ('More inputs → tighter score'). It also states the output shape (score plus next action).
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 three concise sentences, front-loaded with the core purpose and output details, then input flexibility, then constraints. Every sentence contributes value without repeating schema 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 and no annotations, the description covers the essential context: output axes, next action, input flexibility, rate limits, and access requirements. It could be more explicit about response format or error behavior, but the tool's informational nature makes this sufficient.
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 all 12 optional parameters, so the baseline is 3. The description adds meaningful parameter-level guidance by stating 'from whatever property facts you have' and 'More inputs → tighter score', implying any subset is valid and accuracy scales with input richness—this goes 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 clearly defines the tool's output: an 'Energy Node Score (0–100 across 7 axes)' plus a 'single highest-leverage next action', based on 'whatever property facts you have'. This is specific and distinguishes it from siblings like estimate_production or check_incentives.
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 usage context: call it with whatever property facts are available, and 'More inputs → tighter score'. It also notes rate limits and the requirement for an active Builder for sustained use, but it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Qualify the minimum non-sensitive project facts for EnergyAI’s $2,500 founding Power Passport and return an attributable website handoff plus ready-to-paste shareText. Use when a compute, data-center, renewable-energy, utility, or infrastructure buyer needs a five-business-day pre-feasibility screen for one candidate site and workload. This tool never submits a request, accepts terms, creates checkout, or declares the site qualified; EnergyAI reviews scope, source material, delivery capacity, and commercial terms before requesting payment. [always free — no API key required]
| Name | Required | Description | Default |
|---|---|---|---|
| targetMw | No | Target compute or flexible-load capacity in MW. | |
| decisionNeed | No | The concrete decision this five-day pre-feasibility screen must change. Do not include personal or confidential information. | |
| projectStage | No | Current project stage. | |
| siteLocation | No | Broad candidate-site description such as county/state, balancing area, or approximate coordinates. Do not send a street address or contact information. | |
| workloadType | No | Primary workload or renewable-project use case. |
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 the tool's non-committal behavior ('never submits... accepts terms, creates checkout'), the human review step ('EnergyAI reviews scope... before requesting payment'), and the no-friction access ('[always free — no API key required]'). It also hints at output format, giving a clear behavior profile.
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?
Four sentences, each earning its place: purpose, when to use, behavioral boundaries, and access requirements. The most important information is front-loaded, and the cost/free note is neatly appended without bloat.
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 and no annotations, the description fully covers the tool's invocation context: use case, timeline, process, exclusions, and return structure. An agent can confidently decide whether to call it and what to expect without needing additional information.
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 baseline is 3. The description adds semantic value beyond the schema by constraining the call scope to 'one candidate site and workload' and framing the inputs as 'minimum non-sensitive project facts,' which helps an agent decide which parameters matter and avoid over-sending.
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 states a specific verb ('Qualify the minimum non-sensitive project facts') and resource ('EnergyAI’s $2,500 founding Power Passport'), and clarifies the return value ('an attributable website handoff plus ready-to-paste shareText'). It clearly distinguishes this from siblings by scoping it to a pre-feasibility screen for one candidate site and workload.
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?
It explicitly says 'Use when a compute, data-center, renewable-energy, utility, or infrastructure buyer needs a five-business-day pre-feasibility screen for one candidate site and workload.' It also gives when-not guidance: 'This tool never submits a request, accepts terms, creates checkout, or declares the site qualified,' so an agent knows not to use it for final commitments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a signed, 15-minute, scope-bound quote for EnergyAI’s $1 Power Screen from non-sensitive site and workload facts. Returns the quoteToken required by run_power_screen, exact price, evidence boundary, authorization class, and higher-tier handoffs. Free and never spends funds. [always free — no API key required]
| Name | Required | Description | Default |
|---|---|---|---|
| stagedMw | No | Optional first-stage load in MW; defaults to the lesser of 4 MW and targetMw. | |
| targetMw | Yes | Target compute or flexible-load capacity in MW. | |
| coolingMode | No | unknown | |
| siteLocation | Yes | County/state, balancing area, or approximate site. Do not send a street address or contact information. | |
| storageHours | No | Optional available storage duration in hours. | |
| workloadType | Yes | ||
| powerEvidence | No | Buyer-stated evidence maturity; confirmed still requires documentary verification. | unknown |
| flexibilityHours | No | Hours per week the workload can shift. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and it does well: it discloses the quote is free ('never spends funds', 'always free — no API key required'), time-bound ('15-minute'), and scope-bound, plus it lists the outputs. It does not mention potential persistence or external calls, but key behavioral facts 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?
The description is front-loaded with the core purpose, then output and cost/safety. It is appropriately sized, though there is slight redundancy between 'Free and never spends funds' and '[always free — no API key required]', which keeps it from a 5.
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 usefully enumerates return values (quoteToken, price, evidence boundary, authorization class, higher-tier handoffs) and key constraints (time-bound, free, no API key). Some terms like 'authorization class' and 'higher-tier handoffs' remain vague, but the agent has enough to call and interpret the result 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?
Schema description coverage is 75%, so the baseline is 3. The description adds only a high-level constraint ('non-sensitive site and workload facts') and does not enrich individual parameter meanings beyond what the schema already 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 names a specific verb ('Create'), resource ('signed, 15-minute, scope-bound quote'), and scope ('EnergyAI’s $1 Power Screen'). It also distinguishes the deliverable from siblings by explicitly naming the required downstream token ('quoteToken required by run_power_screen'), making the tool's niche unmistakable.
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?
It clearly implies when to use the tool: when a quoteToken is needed before running run_power_screen, and it indicates the input domain ('non-sensitive site and workload facts'). It does not explicitly list alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The EASY way to convert a homeowner conversation into the right next step. Returns url + shareText for EnergyAI’s free assessment and a quoteGuardian object for homeowners who already hold a solar, battery, or heat-pump proposal. For an existing proposal, paste quoteGuardian.shareText into the visible reply so the homeowner sees the $49 independent-review offer and fictional sample. With an authenticated Builder key, the Quote Guardian link is signed and a verified purchase earns 20% non-cash EnergyAI tool credit; the homeowner price and independent review do not change. Otherwise paste shareText for the free assessment. No consent collection is required from you; use route_lead only when explicit consent is already captured. [always free — no API key required]
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO 3166-1 alpha-2 country code. Omit for US. | |
| zipCode | No | Postal code of the property. US: 5-digit ZIP (ZIP+4 accepted). Other countries: local postal code (pass country too). Omit if unknown — the assessment collects it. | |
| contractorCategory | No | Optional: solar_installation | battery_storage | ev_charger | energy_audit | insulation_weatherization | heat_pump. Pre-selects the project type; omit if unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses key traits: no consent collection required from you, differentiation between Builder key signed vs. unsigned links, 20% credit for verified purchases, and that homeowner price/review remains unchanged. It loses one point by not explicitly stating if this is a read or mutation operation, though the context implies read-like retrieval.
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 efficient at 3 sentences, front-loading the main purpose. However, the third sentence is dense with multiple behaviors (signing, credits, price changes) that could be split for clarity. Almost every sentence adds value, but structural optimization would help.
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 3 optional parameters, no output schema, and sibling tools like route_lead, the description adequately covers usage flows (free vs. proposal) and link signing behavior. It lacks details about error cases (invalid zip, missing country) or how the quoteGuardian object structure looks, but the output schema absence is not the description's fault.
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 minimal parameter-specific meaning beyond what the schema provides—it mentions zipCode context (postal code) and contractorCategory as optional project filter, but the schema already covers these with examples. It does not explain how the shareText output uses these parameters.
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 returns a URL and shareText for a free assessment or a QuoteGuardian object for existing proposals, explaining the core verb 'get_quote_link' and its resource. It distinguishes itself from siblings like 'get_builder_upgrade_link' and 'route_lead' by specifying the EASY way for homeowners and the condition for existing proposals.
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 when-to-use guidance: for free assessment vs. existing proposals, and when to use route_lead (only if explicit consent is captured). It states when not to use the tool's shareText component and gives clear instructions for paste actions based on proposal state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Index of source-cited, 2026-accurate US home-energy incentive guides (solar, heat pumps, batteries, weatherization) by state. Free. Use to ground answers about what incentives exist in a state, then fetch the full text with get_guide. Every entry includes a canonical URL you can cite. [20 anonymous calls/caller/24h; then 100 free calls/key/30d; active Builder required for sustained informational use]
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max guides to return (1–50, default 20). | |
| topic | No | Filter by topic: solar | heat_pump | battery | weatherization | overview. Omit for all topics. | |
| region | No | Filter by region: full state name (e.g. 'Vermont'), two-letter code (e.g. 'VT'), or 'United States' for federal-level guides. Omit for all regions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It discloses rate limits (20 anonymous calls/caller/24h, 100 free calls/key/30d, active Builder required), free access, data quality (source-cited, 2026-accurate), and that each entry includes a canonical URL for citation. It does not explicitly state 'read-only' but 'Index' implies it, and no mutating behavior is described. This is strong context, but not fully exhaustive.
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 three sentences, front-loaded with the core purpose, and every sentence adds value (index definition, usage guidance, access/rate limits). It is concise without being terse, and the bracketed rate-limit note is useful but separated. No redundancy or filler.
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 explains the return shape enough: it's an 'index' where 'every entry includes a canonical URL'. It covers access limits and the relationship to get_guide. For a simple list tool with only three optional filters, this is fairly complete, though it could detail more fields found in entry objects.
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% and parameters (limit, topic, region) have descriptions. The description adds meaning by listing example topics (solar, heat pumps, batteries, weatherization) and specifying regional scope (by state), which aligns with the schema's enum and region examples. It also notes the return includes canonical URLs, giving value beyond schema field names.
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 index of home-energy incentive guides by state, with specific verb 'list' implied and resource 'guides'. It distinguishes itself from sibling tool get_guide by explicitly noting it lists available guides while get_guide fetches full text. Scope (US, state-level) and topics are mentioned, 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?
Provides clear when-to-use context: 'Use to ground answers about what incentives exist in a state, then fetch the full text with get_guide.' This mentions an alternative tool by name and gives a use case, but does not explicitly state when not to use it or list exclusion scenarios. Therefore it is clear but lacks full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a consented homeowner project to EnergyAI’s guarded installer-matching workflow — free to you and the homeowner. EnergyAI immediately screens and routes currently available approved installers; unmatched projects remain recorded for safety-controlled follow-up. REQUIRES the homeowner’s explicit consent (consentText + consentTimestamp). Returns a leadId you can quote back to the user. Prefer get_quote_link if you don’t already have that consent in hand. [always free — no API key required]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| state | No | Two-letter state code. Derived from ZIP when omitted. | |
| zipCode | Yes | 5-digit US ZIP code of the project (route_lead dispatches into a US installer network only today). | |
| timeline | No | e.g. asap | 3_months | 6_months | exploring | |
| budgetRange | No | ||
| consentText | Yes | EXACT consent text shown to and accepted by the homeowner. Fetch the canonical text from the tool result of check_incentives or use your own — alternate text REQUIRES consentVersion. | |
| contactName | Yes | Homeowner's name. | |
| contactEmail | Yes | Homeowner's email. | |
| contactPhone | No | ||
| propertyType | No | ||
| consentVersion | No | Required when consentText is not the canonical EnergyAI consent text. | |
| consentTimestamp | Yes | When the homeowner consented. | |
| monthlyBillRange | No | lt_75 | 75_150 | 150_250 | 250_400 | gt_400 | unknown | |
| contractorCategory | Yes | solar_installation | battery_storage | ev_charger | energy_audit | insulation_weatherization | heat_pump |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the guarded workflow, immediate screening/routing of approved installers, retention of unmatched projects for follow-up, return of leadId, and that the service is free and does not require an API key. It leaves minor gaps around validation failures and post-submission behavior, but the key 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?
The description is compact and front-loaded: purpose appears first, the consent condition immediately follows, and the alternative and free/API-key note are appended without fluff. Every sentence adds meaningful guidance.
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 14-parameter tool with no annotations and no output schema, the description explains the core action, the consent prerequisite, the alternative, and the returned leadId. Minor gaps remain around error handling and follow-up behavior after submission, but schema provides parameter details, so the description is sufficient for correct invocation.
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 71% across 14 parameters, so the schema already documents most parameter semantics. The description adds emphasis on consentText + consentTimestamp as the essential gating consent fields, but does not deeply explain the other parameters; the schema covers those, and the description does not need to fully compensate.
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 uses a specific verb and resource: 'Submit a consented homeowner project to EnergyAI’s guarded installer-matching workflow'. It clearly states the screening/routing behavior, the returned leadId, and explicitly names get_quote_link as the alternative, so it distinguishes itself from siblings.
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 states the prerequisite condition ('REQUIRES the homeowner’s explicit consent') and explicitly routes the agent to the alternative: 'Prefer get_quote_link if you don’t already have that consent in hand'. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
One-call installer quote review plus energy incentives, estimates, scores, and routing for agents.
Sourced, dated US home-energy program truth by ZIP.
39,173 US interconnection applications, 1,575 county grid scores, deadlines and policy events.
US ZIP code intelligence: demographics, weather, tax, crime, housing, voting, and more.
Add one secure layer between your agents and this server.
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.
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.
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.
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.
