solar-home-incentives

route_lead

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]

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No
`state`	No	Two-letter state code. Derived from ZIP when omitted.
`apiKey`	No	Optional existing EnergyAI key for hosts that cannot change Authorization headers. Use it to retain account identity for discovery and get_builder_upgrade_link after a trial. Removed before tool execution and persistence. Omit when the Bearer header is attached; never show the key to the user.
`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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 13, 2026

addedInput schema / properties / apiKey

Added value: +{
+  "description": "Optional existing EnergyAI key for hosts that cannot change Authorization headers. Use it to retain account identity for discovery and get_builder_upgrade_link after a trial. Removed before tool execution and persistence. Omit when the Bearer header is attached; never show the key to the user.",
+  "type": "string"
+}

Changed1 schema field changedJul 17, 2026

changedInput schema / properties / zipCode / description

Previous value: -"5-digit US ZIP code of the project."New value: +"5-digit US ZIP code of the project (route_lead dispatches into a US installer network only today)."

Changed1 schema field changedJul 12, 2026

addedInput schema / examples

Added value: +[
+  {
+    "consentText": "<canonical text returned by check_incentives.consentTextForRouting, shown to and accepted by the homeowner>",
+    "consentTimestamp": "2026-07-12T19:00:00Z",
+    "contactEmail": "jane@example.com",
+    "contactName": "Jane Doe",
+    "contractorCategory": "solar_installation",
+    "monthlyBillRange": "150_250",
+    "timeline": "3_months",
+    "zipCode": "59715"
+  }
+]

First observedJul 5, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Discloses key behaviors: free, no API key required, immediate screening/routing, unmatched projects recorded for follow-up, and returns a leadId. No annotations exist, so the description carries the load and does it well, though it doesn't mention rate limits or error handling.

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

Conciseness5/5

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

Front-loads the action, then constraints, then return value, then alternative and cost note. Every sentence earns its place with no redundancy.

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

Completeness4/5

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

For a mutation tool with 15 params, no annotations, and no output schema, the description covers consent requirements, return value, and sibling routing. It could add more on error cases or what happens post-submission, but is largely complete.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 73% (baseline 3), but the description adds critical meaning: the consentText must be the exact text shown, fetched from check_incentives or requiring consentVersion, and consentTimestamp is required. It also explains the leadId return value.

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

Purpose5/5

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

Specific verb+resource ('Submit a consented homeowner project') with the exact workflow named ('installer-matching'). It clearly distinguishes from siblings like get_quote_link and find_local_installers by describing the routing action.

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

Usage Guidelines5/5

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

Explicitly states 'Prefer get_quote_link if you don’t already have that consent in hand' and names the required precondition (homeowner explicit consent). This is a clear when-to-use vs alternative rule.

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

All solar-home-incentives tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

route_lead

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources