AtlasAdapt

Recommend and price a resilience plan

estimate_plan

Read-onlyIdempotent

For one building: the upgrades we RECOMMEND (commercial, when upgrades is omitted) or the ones you name; each upgrade's cost; the yearly loss per hazard without and with the plan (the owner's share, after deductible and insurer); incentives counted; net upfront cost; annual benefit; payback; net over the horizon. Same engine as the AtlasAdapt product. 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": "estimate_plan"
  }
}

Input Schema

Name	Required	Description
`address`	No	Street address. Per-address hazards in US, UK, DE, FR and CH; omit it to price on country averages (the reply says which).
`country`	Yes	ISO country code: US, UK, DE, FR, CH, IT, ES …
`segment`	Yes
`utility`	No	Electric utility name, where a programme depends on it.
`building`	No	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.
`upgrades`	No	Upgrade ids to price. Omit to get our recommended plan (a home or a building).
`recommend`	No	Price the recommended plan. Default true when `upgrades` is omitted.
`home_value`	No	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.
`horizon_years`	No	Default 10.
`household_size`	No
`household_income`	No	Residential, optional. Omitted = the top income band (no income-tied money is counted on a guess).
`discount_rate_pct`	No	% real. 0 = undiscounted.
`planned_install_date`	No	YYYY-MM-DD. Decides which programmes are open.

Output Schema

Name	Required	Description	Default
`ok`	Yes
`estimate`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 12, 2026

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"
+}

Changed3 schema fields changedNov 12, 2026

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"
+]

Changed1 schema field changedNov 12, 2026

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."

Changed2 schema fields changedNov 12, 2026

changedInput schema / properties / recommend / description

Previous value: -"Commercial: price the recommended plan. Default true when `upgrades` is omitted."New value: +"Price the recommended plan. Default true when `upgrades` is omitted."

changedInput schema / properties / upgrades / description

Previous value: -"Upgrade ids to price. Omit (commercial) to get our recommended plan."New value: +"Upgrade ids to price. Omit to get our recommended plan (a home or a building)."

First observedNov 11, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, and the description adds genuinely non-obvious behavior: incentives flagged counts_toward_roi=false or contingent/competitive must never enter totals, amounts are guidance to confirm with the grantor, and losses are the owner's share after deductible and insurer. It omits anything about determinism or cost/latency for what is clearly a heavy open-world calculation.

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

Conciseness3/5

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

Front-loaded with scope, but the long semicolon chain enumerating return values is wasted effort because an output schema exists. The important guardrails (exclude paused/contingent incentives, amounts are guidance) are buried at the tail of a run-on sentence rather than structured as rules.

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 13-parameter tool with a nested building object and an output schema, the description covers the crucial domain constraints (incentive eligibility, defaults flagged in assumptions, per-address vs country-average pricing) without needing to explain return shapes. The main gap is the absence of guidance on when to use a sibling instead.

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 85%, so the schema already carries parameter meaning, and the description largely restates it (omitting `upgrades` yields the recommended plan). Marginal added value comes from framing owner's-share losses and incentive refs, but it does not clarify interactions such as how `recommend` behaves when `upgrades` is supplied.

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 states the scope ('For one building'), the two modes (recommended vs named upgrades), and enumerates the concrete outputs (cost, yearly loss with/without plan, incentives, net upfront, payback). An agent can tell this apart from estimate_portfolio purely from the 'one building' scoping.

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

Usage Guidelines4/5

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

It clearly states the selection rule between modes: omit `upgrades` for the recommended plan, or name ids to price those. It also gives the residential/commercial branches. It never names a sibling alternative (compare_plans, find_incentives, list_upgrades), so the agent must infer routing from the sibling list.

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

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

Resources

Need Help?