Skip to main content
Glama

Incentives for a building and its upgrades

find_incentives
Read-onlyIdempotent

Which grants, tax credits, rebates and loans apply to this building and these upgrades, and for how much: available (counted), contingent (real but not the owner's, or event-triggered — never counted), non_cash (financing, unpriced). Each carries its ref, funding state, stated conditions, who can apply and its source. Never add an incentive whose counts_toward_roi is false (paused, waitlisted, closed) or that is contingent or competitive into any total; show every stated condition beside its incentive; name incentives by their ref (e.g. US12c). Amounts are guidance to be confirmed with the grantor.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "country": "<country>",
      "segment": "<segment>",
      "upgrades": "<upgrades>"
    },
    "name": "find_incentives"
  }
}

Input Schema

NameRequiredDescriptionDefault
addressNoStreet address. Per-address hazards in US, UK, DE, FR and CH; omit it to price on country averages (the reply says which).
countryYesISO country code: US, UK, DE, FR, CH, IT, ES …
segmentYes
utilityNoElectric utility name, where a programme depends on it.
buildingNoThe building. Commercial: type (office, warehouse, retail, hotel, manufacturing, school, hospital, multifamily, data_centre …), size (small|medium|large), floor_area (sq ft in the US, m² elsewhere), owns (false for a tenant), org_type, storeys, annual_revenue (its own; else a default for the type, flagged in estimate.assumptions), installed_upgrades (ids it already has), flood_insurance (nfip|none|unknown). Residential: residential_type, tenure (own|rent|building), dwelling_units (1 for a house), foundation (slab|basement|crawlspace|pier|piling). Omitted fields use sourced defaults or public records for the address, and the reply says which.
upgradesYes
home_valueNoResidential: the home's value. Omit it and the address region's median is used (US: ACS by state), flagged in estimate.home_value as estimated.
horizon_yearsNoDefault 10.
household_sizeNo
household_incomeNoResidential, optional. Omitted = the top income band (no income-tied money is counted on a guess).
planned_install_dateNoYYYY-MM-DD. Decides which programmes are open.

Output Schema

NameRequiredDescriptionDefault
okYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / building / description
      Previous value: -"The building. Commercial: type (office, warehouse, retail, hotel, manufacturing, school, hospital, multifamily, data_centre …), size (small|medium|large), floor_area (sq ft in the US, m² elsewhere), owns (false for a tenant), org_type, storeys, installed_upgrades (ids it already has), flood_insurance (nfip|none|unknown). Residential: residential_type, tenure (own|rent|building), dwelling_units (1 for a house), foundation (slab|basement|crawlspace|pier|piling). Omitted fields use sourced defaults or public records for the address, and the reply says which."New value: +"The building. Commercial: type (office, warehouse, retail, hotel, manufacturing, school, hospital, multifamily, data_centre …), size (small|medium|large), floor_area (sq ft in the US, m² elsewhere), owns (false for a tenant), org_type, storeys, annual_revenue (its own; else a default for the type, flagged in estimate.assumptions), installed_upgrades (ids it already has), flood_insurance (nfip|none|unknown). Residential: residential_type, tenure (own|rent|building), dwelling_units (1 for a house), foundation (slab|basement|crawlspace|pier|piling). Omitted fields use sourced defaults or public records for the address, and the reply says which."
    • addedInput schema / properties / building / properties / annual_revenue
      Added value: +{
      +  "description": "Commercial: the building's own annual revenue. Every business-continuity figure scales with it.",
      +  "exclusiveMinimum": 0,
      +  "type": "number"
      +}
  2. Changed3 schema fields changed
    • changedInput schema / properties / building / description
      Previous value: -"The building. Commercial: type (office, warehouse, retail, hotel, manufacturing, school, hospital, multifamily, data_centre …), size (small|medium|large), floor_area (sq ft in the US, m² elsewhere), owns (false for a tenant), org_type, storeys, installed_upgrades (ids it already has), flood_insurance (nfip|none|unknown). Residential: residential_type, tenure (own|rent|building). Omitted fields use sourced defaults or public records for the address, and the reply says which."New value: +"The building. Commercial: type (office, warehouse, retail, hotel, manufacturing, school, hospital, multifamily, data_centre …), size (small|medium|large), floor_area (sq ft in the US, m² elsewhere), owns (false for a tenant), org_type, storeys, installed_upgrades (ids it already has), flood_insurance (nfip|none|unknown). Residential: residential_type, tenure (own|rent|building), dwelling_units (1 for a house), foundation (slab|basement|crawlspace|pier|piling). Omitted fields use sourced defaults or public records for the address, and the reply says which."
    • addedInput schema / properties / building / properties / org_type / description
      Added value: +"Who owns or runs it. A public body (local_government, state, federal, tribal) changes which incentives apply: a body that pays no tax cannot use a tax credit, and some programmes are open only to one kind of applicant."
    • addedInput schema / properties / building / properties / org_type / enum
      Added value: +[
      +  "commercial",
      +  "nonprofit",
      +  "local_government",
      +  "state",
      +  "federal",
      +  "tribal",
      +  "homeowner",
      +  "public_housing_body",
      +  "owners_association"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / home_value / description
      Previous value: -"Residential only: the home's insured value."New value: +"Residential: the home's value. Omit it and the address region's median is used (US: ACS by state), flagged in estimate.home_value as estimated."
  4. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, and the description goes well past them: it defines what each result bucket means, warns that contingent incentives are 'real but not the owner's' and must never be counted, flags amounts as guidance to be confirmed with the grantor, and states that refs and stated conditions accompany each entry. That is material behavioral context an agent cannot get from the structured fields.

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?

Dense but front-loaded: the question being answered comes first, the result taxonomy second, the counting rules third. Each clause carries a distinct rule, though the semicolon-chained aggregation constraints make it heavier to parse than a short bulleted set would be.

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 an 11-parameter tool with a nested building object and an output schema, the description covers the interpretive burden — bucket semantics, counting prohibitions, ref citations, amount caveats — while leaving field-level detail to the well-annotated schema. The only gap is the absence of explicit routing to sibling tools such as get_incentive or estimate_plan.

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

Parameters3/5

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

Schema coverage is 73%, so the schema already documents nearly all 11 parameters in depth, and the description adds essentially nothing parameter-specific beyond 'this building and these upgrades'. The rules it does add (counting, refs, confirmation of amounts) are about interpretation of results, not about how to populate address, segment, or the nested building object.

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 opening clause names a specific verb-and-resource pair: which grants, tax credits, rebates and loans apply to this building and these upgrades, plus the amount. It also enumerates the three result buckets (available/contingent/non_cash), which distinguishes this finder from the singular get_incentive lookup and from list_upgrades without requiring the agent to open a schema.

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 gives strong rules about how to consume the results (never sum contingent, competitive, or counts_toward_roi=false items; show conditions beside each incentive; cite refs), but it never says when to call this tool rather than get_incentive or estimate_plan. Selection guidance is only implied by 'this building and these upgrades'.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources