Skip to main content
Glama

contractors.fyi

by fyi.contractors
OverviewDiscussionsAdmin

Solar size, price and payback

solar_estimate
Read-onlyIdempotent

Size a home solar system from the monthly electric bill (or its kWh, or, with neither, the home and what runs on electricity), plus anything the home plans to add such as electric cars, then give the price range homeowners in that city paid for a system that size (Berkeley Lab records, before any tax credit, no battery), yearly savings and payback. Output per kW, heating and cooling use and the default price per kWh are rough city figures.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityYes
usesNoWhat runs on electricity besides lights, fridge and outlets
home_sizeNosmall: under 1,500 sq ft; medium: 1,500 to 3,000; large: over 3,000medium
monthly_kwhNoFrom the bill; replaces the estimate
monthly_billNoMonthly electric bill in dollars
electric_carsNo
miles_per_carNoMiles a year, each car
price_per_kwhNoDollars per kWh from the bill; default is a typical city figure

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / uses / items / enum
      Previous value: -[
-  "Central air conditioning",
-  "Heat pump or electric heat",
-  "Electric water heater",
-  "Electric dryer",
-  "Electric stove and oven",
-  "Pool pump",
-  "Hot tub"
-]New value: +[
+  "Central air conditioning",
+  "Heat pump or electric heat",
+  "Heat pump water heater",
+  "Electric dryer",
+  "Electric stove and oven",
+  "Pool pump",
+  "Hot tub"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / monthly_bill
      Added value: +{
+  "description": "Monthly electric bill in dollars",
+  "maximum": 5000,
+  "minimum": 1,
+  "type": "number"
+}
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable behavioral context: it discloses that output figures are 'rough city figures,' specifies the data source (Berkeley Lab records), and clarifies exclusions ('before any tax credit, no battery'). It also explains the fallback logic for inputs (bill, kWh, or home details). These details go beyond the annotations and help the agent understand approximation and scope.

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

Conciseness4/5

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

The description is a few sentences but packs substantial information without redundancy. It front-loads the core purpose ('Size a home solar system') and then details inputs, outputs, and caveats. Each clause contributes unique information (inputs, add-ons, price source, exclusions, rough figures). It is appropriately concise for a tool with 8 parameters, though it could be slightly more structured with bullet points, but the current flow is logical.

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?

Given the tool's complexity (8 parameters, no output schema), the description is quite complete. It explains what outputs to expect (price range, savings, payback, per kW, heating/cooling use, default price) and clarifies limitations (rough city figures, no battery, pre-tax credit). It also covers the input fallback logic. The only missing element is a detailed description of the return format, but since there is no output schema, the description adequately covers what the agent needs to know to invoke it correctly.

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 75%, so the schema already documents most parameters. The description adds semantic meaning by explaining how parameters interact: the fallback from monthly_bill to monthly_kwh to home_size/uses, and the inclusion of electric_cars as an add-on. This clarifies the relationship between parameters beyond their individual descriptions, adding value over the schema. It does not repeat schema details but explains the decision logic.

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

Purpose5/5

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

The description clearly states the tool's function: size a home solar system from various inputs (bill, kWh, home details) and output price range, savings, payback, and per-kW figures. It specifies the resource (home solar) and the action (sizing and estimating costs), making it distinct from sibling tools like check_solar_quote or project_cost. The verb 'size' and resource 'home solar system' are explicit, and the description covers the full scope of what the tool does.

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

Usage Guidelines3/5

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

The description implies the use case—when you need to estimate solar system size and costs—but it does not explicitly state when to use this tool versus alternatives. It neither names sibling tools nor provides exclusionary conditions (e.g., 'use this when you have a bill, otherwise use X'). The context is clear from the content, but guidance on choosing among alternatives is absent, so it falls short of explicit usage guidance.

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

All contractors.fyi toolsInspect
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.

Resources