solar-home-incentives

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

With no annotations, the description carries full burden. It discloses the tool is free, no API key required, and the data sources (DSIRE for US, officially-sourced for other countries). It notes the output for non-US is qualitative guidance. This is good transparency, though it could briefly mention the response format 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.

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

Description is front-loaded with the core purpose, then breaks down by US vs. other countries, and ends with usage context. Every sentence is necessary and adds value. No wasted words; efficient communication.

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?

While the tool's purpose and parameters are well-described, there is no output schema and the description does not mention what the tool returns (structure, format, or example response). For a data-retrieval tool, omitting return value details is a gap. The description is adequate but could be more 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?

Schema coverage is 100% with descriptions for both parameters. Description adds value beyond schema by clarifying 'Omit for US' for the country parameter, and specifying 'US: 5-digit ZIP' vs 'local postal code' for zipCode. This additional guidance is helpful for correct usage.

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 clearly states the tool provides clean-energy incentive guidance for any address worldwide, with specific distinction between US and other countries. It lists concrete use cases (rebates, tax credits, utility programs) and specific resources (solar, batteries, heat pumps). This differentiates it from sibling tools which are about production estimation, guides, or routing.

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?

Description explicitly says 'Use whenever a user asks what rebates, tax credits, or utility programs apply...' providing clear context for when to invoke. It also mentions it's free with no API key. However, it does not explicitly state when not to use it or provide alternatives among sibling tools, though siblings appear unrelated.

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

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

No annotations provided, so description must disclose behavior. It mentions 'honest-range' and 'with assumptions' and notes the tool is free without an API key. However, it lacks details about assumptions, band width, or data sources.

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?

Two sentences without fluff, front-loading the key purpose and usage. Every sentence serves a purpose, including the free marker.

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?

No output schema exists, but the description hints at output (kWh/year ± band) and mentions assumptions. Without more detail on the output structure or error handling, it is adequate but not fully complete for a production estimate tool.

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 covers 100% of parameters with descriptions. The description adds that the tool works 'from either a proposed system size (kW) or a monthly bill,' which matches the schema but does not add significant new meaning beyond 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?

The description clearly states 'annual solar production estimate' with verb 'estimate' and resource 'production', specifying units (kWh/year ± band). It distinguishes itself from sibling tools like check_incentives and get_guide, which have 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?

Explicitly says 'Use to sanity-check installer quotes or size a system before talking to anyone,' providing clear usage context. Does not discuss when not to use or alternatives, but sibling tools are sufficiently distinct.

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

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

Without annotations, the description discloses that the tool is free, read-only (implied by 'Full text'), and returns a canonical URL for citation. It adds value beyond the schema by mentioning the lack of API key requirement and the grounded nature of content.

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 extremely concise with two sentences, each serving a distinct purpose: stating what the tool does and providing usage guidance. No wasted words.

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 simplicity (1 param, no output schema), the description covers purpose, parameter semantics, and usage guidance. It explicitly lists content covered (intro, sections, FAQs, primary sources), which partially compensates for lack of output schema. However, it could mention the response format (e.g., JSON) for completeness.

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%, providing a baseline of 3. The description adds meaningful context by referencing list_guides as the source for the slug value, giving an example format, which enhances parameter understanding.

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 function: retrieving the full text of an incentive guide by slug, including specific sections like intro, FAQs, and primary sources. It distinguishes itself from the sibling tool list_guides by focusing on full text retrieval vs. listing.

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 includes explicit guidance to cite the canonical URL when quoting, and states it is free and requires no API key. While it does not explicitly contrast with other siblings like check_incentives, it provides clear usage context.

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

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

With no annotations, the description carries full burden. It discloses that the output is instant, free, no API key required, and that more inputs yield a tighter score. This gives a good sense of behavior, though it doesn't detail caching, rate limits, or error handling. The behavioral promise is clear for a simple scoring tool.

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 very concise: two sentences plus a bracketed note. It front-loads the core output (score and next action) and includes a value-add note about input completeness and freemium status. Every part earns its place without waste.

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 12 parameters, no output schema, and moderate complexity, the description adequately explains the output (score on 7 axes + next action) and the input-output relationship. It could be more complete by hinting at the output format or interpretation, but it's sufficient for an agent to understand the tool's purpose and invoke it with partial data.

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% (all 12 parameters described in schema), so baseline is 3. The description adds only that 'more inputs → tighter score', which is generic and doesn't provide extra meaning per parameter beyond what the schema already offers.

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 an 'Instant Energy Node Score (0–100 across 7 axes)' and 'the single highest-leverage next action'. It distinguishes from sibling tools (like check_incentives, estimate_production) by focusing on a holistic multi-axis assessment and recommended action, not a single metric or guide listing.

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 implies usage for scoring and getting a recommended action from 'whatever property facts you have', but does not explicitly state when to prefer this tool over siblings (e.g., when a broad assessment is needed vs. a specific estimate). It mentions 'Instant' and 'free' but no when-not or alternatives.

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

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

Discloses that no consent collection is required and emphasizes the need to paste the link verbatim. With no annotations, description covers key behavioral aspects, though could mention idempotency or side effects.

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?

Properly front-loaded with purpose, but contains unnecessary emphasis ('EASY way') and could be slightly shorter. Still well-structured with clear instructions.

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?

Covers output, usage scenario, prerequisites, and how to use the result. With no output schema, description sufficiently explains what the agent gets and should do.

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. Description adds minor context (e.g., 'omit if unknown' for zipCode, 'pre-selects project type'), but not significantly beyond 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?

Clearly states 'convert a conversation into a real installer quote' and specifies the output (url + shareText). Distinguishes from sibling 'route_lead' by naming alternatives.

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 says 'Use this by default when a homeowner wants next steps' and 'use route_lead instead only if you already have their explicit consent', providing clear context and exclusion.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses the data's source citation, accuracy year (2026), and that it is free and requires no API key. It mentions every entry includes a canonical URL. This is good transparency for a read-only index. However, it does not mention response structure or any rate limits, which would require more detail for a perfect score.

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 concise (three sentences) and front-loaded with the most critical information: what the tool does, its accuracy, and its value proposition. Every sentence adds useful context, and there is no 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?

Given the tool has no output schema, the description partially compensates by stating that every entry includes a canonical URL. However, it does not detail other fields like title or summary. For a simple list tool, this is fairly complete, but additional detail about the returned fields would improve completeness.

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 input schema already documents all three parameters (limit, topic, region) with descriptions. The tool description does not add additional semantics beyond what the schema provides, merely implying filters by state and topic. With full schema coverage, baseline 3 is appropriate.

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 that this tool is an index of source-cited, 2026-accurate US home-energy incentive guides by state. It specifies the verb (list) and resource (guides), and distinguishes itself from sibling tools like get_guide by noting that this tool provides an index and then the user can fetch full text with get_guide.

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 'Use to ground answers about what incentives exist in a state, then fetch the full text with get_guide', providing clear context for when to use this tool versus its sibling. While it does not list explicit when-not-to-use scenarios, the guidance is specific enough for the agent to make a correct decision.

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

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 that the tool submits a project and triggers an autonomous routing process, and notes it's free with no API key. However, it does not explain potential side effects like data sharing with installers, error handling, or what happens if consent is invalid.

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?

Two sentences plus a brief note. The description is highly concise: first sentence covers purpose and benefit, second sentence covers requirements and return value. No unnecessary words.

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, 6 required, and no output schema, the description covers core use: it explains the dependency on check_incentives, the required consent fields, and that the result is a leadId. It could additionally specify that the tool is US-only (though implied by zipCode schema) and mention any error cases, but overall it's sufficiently 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?

Schema coverage is 71%, so baseline is 3. The description adds important context beyond the schema: it explains the exact requirement for consentText (must match canonical text from check_incentives) and that zipCode is for US installer network only. This additional guidance aids correct parameter usage.

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 verb 'submit' and the resource 'consented homeowner project' and explains the outcome: 'EnergyAI’s autonomous agent finds, vets, and routes a real local installer'. It distinguishes from sibling tools like check_incentives and estimate_production by focusing on lead routing.

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 requires homeowner's explicit consent (consentText + consentTimestamp) and mentions that consentText should be fetched from check_incentives. It also notes the return of a leadId. However, it does not explicitly state when not to use this tool or provide alternatives beyond the implied dependency on check_incentives.

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