Skip to main content
Glama
Sign In

AtlasAdapt

by com.atlasadapt
OverviewDiscussionsAdmin

Full resilience report for a building

building_report
Read-onlyIdempotent

The complete answer for one building in one call: the climate hazards at the address (with sources), the upgrades we recommend with each one's cost, the yearly loss per hazard without and with the plan, net upfront cost after incentives, payback, net over the horizon, and the incentives for that plan with their conditions and funding state. Uses ONE report from the key's allowance. Prefer this to calling assess_risk, estimate_plan and find_incentives separately. 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>"
    },
    "name": "building_report"
  }
}

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.
upgradesNoOmit for our recommended plan (a home or a building).
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).
discount_rate_pctNo
planned_install_dateNoYYYY-MM-DD. Decides which programmes are open.

Output Schema

NameRequiredDescriptionDefault
okYes
planYes
hazardsNo
incentivesNo

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. Changed1 schema field changed
    • changedInput schema / properties / upgrades / description
      Previous value: -"Omit (commercial) for our recommended plan."New value: +"Omit for our recommended plan (a home or a building)."
  5. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds non-obvious behavior beyond that: it consumes exactly 'ONE report from the key's allowance' (quota cost) and it aggregates three separate computations into a single call. It does not cover latency or partial-failure behavior, which keeps it short of a 5.

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?

One front-loaded paragraph that leads with the value proposition, then output contents, then quota cost, then sibling routing, then output-handling rules. Dense but every sentence carries information; slight run-on quality and the long output enumeration cost it a point.

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 12-parameter, nested-object tool, the definition covers cost/quota, aggregation of sibling tools, and how to treat incentive amounts. An output schema exists, so the description arguably over-explains return values, but nothing an agent needs to invoke it correctly is missing.

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 description coverage is 75% and the schema text is unusually rich (address coverage by country, org_type tax-credit effects, annual_revenue scaling, home_value median fallback). The description adds essentially no per-parameter meaning beyond 'the climate hazards at the address', so the schema is doing the heavy lifting; baseline 3 is right.

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 ('The complete answer for one building in one call') and then enumerates exactly what is returned: hazards with sources, recommended upgrades with cost, loss per hazard with/without plan, net upfront cost, payback, net over horizon, incentives with conditions. It is clearly distinguishable from assess_risk, estimate_plan and find_incentives, which it names.

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?

Explicit routing guidance: 'Prefer this to calling assess_risk, estimate_plan and find_incentives separately.' It also gives downstream rules for handling results (never total paused/waitlisted/closed or contingent/competitive incentives; show every condition; name incentives by ref). Little is left to inference about when and how to use it.

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

All AtlasAdapt 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