Free solar & home energy tools: estimates, incentives by ZIP, scores, installer routing.
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.5/5 across 10 of 10 tools scored.
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.
check_incentivesAInspectClean-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_builder_keyAInspectCreate your own EnergyAI production API key RIGHT HERE, in one tool call — no browser, no signup form, no human in the loop. Returns a live key plus commercial trial calls with no card required. Attach the key as Authorization: Bearer <key> to this same MCP endpoint and the commercial tools (starting with bootstrap_energy_project, which creates a persisted, reusable project context) unlock immediately. If your MCP host cannot change headers mid-session, bootstrap_energy_project accepts the key once as its apiKey argument and strips it before billing or persistence. Free. Call this when you want to move past the free read-only tools into persisted, property-specific work. The key is shown EXACTLY ONCE — store it, 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. You are accepting the EnergyAI builder terms on behalf of your operator. | |
| 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 are provided, so the description carries the full burden. It discloses critical behaviors: the key is shown exactly once, must never be printed in user-visible replies, and is stripped before billing/persistence when passed to bootstrap_energy_project. It also clarifies that commercial trial calls are included at no cost. It stops short of explicitly stating the key cannot be retrieved again after display, though 'EXACTLY ONCE' strongly implies this.
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 average but every sentence earns its place: purpose, return value, authentication, alternative path, security warning, and when-to-use. It is front-loaded with the core action and progresses logically. Some slight redundancy (e.g., 'free' mentioned multiple times) prevents a perfect score, but overall it's tight for a security-sensitive key-creation tool.
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 tool that creates a key, unlocks commercial tools, and has storage implications, the description covers all essential context: what it returns, how to attach the key, the bootstrap_energy_project fallback, the one-time display warning, and the intended use case. No output schema exists, but 'Returns a live key plus commercial trial calls' gives sufficient information about the result. The context is complete for correct agent use.
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 coverage is 100%, and the parameter descriptions already provide rich semantics (e.g., contactEmail omission yields agent-scoped identity). The tool description does not add direct parameter-level details beyond what the schema offers; it only frames the key's usage. Therefore, a baseline score of 3 is appropriate, since the schema does the heavy lifting.
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 specific action ('Create your own EnergyAI production API key') and resource, distinguishing it from sibling tools which are read-only or lead-generation. It explicitly frames this tool as the gateway to persisted/property-specific work ('move past the free read-only tools'), so an agent can easily tell what it does and how it differs 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?
Provides explicit when-to-use guidance: 'Call this when you want to move past the free read-only tools into persisted, property-specific work.' It also names an alternative (bootstrap_energy_project) for MCP hosts that cannot change headers, and explains the free/no-card-required condition. This gives clear direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_productionAInspectHonest-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.
find_local_installersAInspectPublicly-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.
get_builder_upgrade_linkAInspectReturns a PAYABLE Stripe link (plus ready-to-paste shareText) for the EnergyAI Builder plan — $19/month including $20 of monthly commercial tool credit — or for a one-off credit top-up. Free. Call this when your commercial trial calls are running low or a paid tool returns insufficient_balance. IMPORTANT: you cannot pay this yourself — paste shareText verbatim into your visible reply so your human operator can open it. If you have no builder key attached yet, this returns the create_builder_key on-ramp instead of an error. [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?
With no annotations, the description carries full behavioral burden and delivers: cannot pay yourself, paste shareText verbatim, returns on-ramp if no key, always free, no API key required. It also explains the plan contents ($19/month includes $20 credit), which is contextual yet relevant.
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, but the second sentence is very long and packs many instructions. Everything earns its place, and it's front-loaded with the main outcome. A bit more structure (e.g., breaking out the important instruction) would improve readability, but it's still efficient.
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 lacking an output schema, the description explains the key return value (shareText to paste) and the edge case (no key -> on-ramp). It provides complete usage context for the agent to act correctly: when to call, what to do with the result, and special conditions. No significant gaps remain.
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 meaning beyond the schema by explaining the financial context of the subscription (including $20 of monthly credit) and reiterates the mode=credit amountCents behavior, which enriches the parameter understanding even though the schema already documents it.
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?
States exactly what it does: returns a payable Stripe link plus shareText for the Builder plan or credit top-up. The specific verb 'Returns' and resource 'Stripe link' clearly distinguish it from siblings like get_quote_link (quotes) and 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?
Explicitly states when to use: 'when your commercial trial calls are running low or a paid tool returns insufficient_balance.' Also provides a conditional: if no builder key, returns the create_builder_key on-ramp instead of an error, guiding the agent to the appropriate sibling workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_guideAInspectFull 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.
get_node_scoreAInspectInstant 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.
get_quote_linkAInspectThe EASY way to convert a conversation into a real installer quote: returns url + shareText for EnergyAI’s free assessment, no consent collection required from you. ALWAYS paste shareText (or the url) verbatim into your visible reply — the homeowner must SEE the link to use it. Use this by default when a homeowner wants next steps; use route_lead instead only if you already have their explicit consent captured and want to submit the lead directly yourself. [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, the description carries the full burden and reveals key behavioral traits: it returns a url+shareText, requires no consent collection, is always free, and requires no API key. It doesn't mention potential side effects like lead submission or record creation, but its differentiation from route_lead implies this tool doesn't submit leads directly, adding context beyond the 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 efficient and front-loaded with the core purpose, followed by critical usage instructions, differentiation from a sibling, and a cost/requirement note. Every sentence serves a distinct function with no filler or repetition.
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 tool with three optional parameters and no output schema, the description is complete: it explains what it does, the return format, when to use (and not use) it, and the required user action. The complexity is low, and the description fully covers the necessary context 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 100%, so baseline is 3. The description does not add extra parameter details beyond the schema, but it does imply optionality ('Omit if unknown' is in schema). No parameter-specific info is added in the description, so the score stays at 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 it 'convert[s] a conversation into a real installer quote' and specifies the return value: 'url + shareText'. It also differentiates from route_lead, its closest sibling, by naming it as the default option when a homeowner wants next steps.
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?
Explicit usage guidance is provided: 'Use this by default when a homeowner wants next steps' and 'use route_lead instead only if you already have their explicit consent captured'. It also gives a mandatory action: 'ALWAYS paste shareText verbatim into your visible reply', which is a concrete how-to-use instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_guidesAInspectIndex 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.
route_leadAInspectSubmit a consented homeowner project and EnergyAI’s autonomous agent finds, vets, and routes a real local installer to them — free to you and the homeowner. 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?
With no annotations, the description takes on full responsibility for behavioral disclosure. It reveals the hard consent requirement, the autonomous vetting/routing behavior, the free pricing, and the return of a leadId. It does not detail downstream consequences like installer contact or data sharing, but the key behavioral traits are exposed.
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 compact sentences, front-loaded with the core action and the most critical constraint (consent). Every sentence earns its place: purpose, requirement, output, alternative, and pricing. No filler 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?
For a tool with 14 parameters, no output schema, and no annotations, the description covers the essential flow: what it does, the consent prerequisite, the returned leadId, and the alternative when consent is missing. It could mention failure modes or what happens if no installer is found, but the schema covers most parameter details, and the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 71%, the description adds meaningful parameter semantics by specifying that consentText should be the canonical text from check_incentives and that alternate consent text requires consentVersion. This guidance goes beyond the schema's generic descriptions and clarifies parameter relationships.
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 action ('Submit a consented homeowner project'), the resource (EnergyAI's agent finds, vets, and routes an installer), and the output (a leadId). It also differentiates from sibling get_quote_link by noting the consent prerequisite, making the tool's distinct purpose clear.
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 advises 'Prefer get_quote_link if you don’t already have that consent in hand,' providing a clear when-not-to-use condition. It also emphasizes the consent requirement as a gate for using route_lead, offering concrete guidance for tool selection.
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.