Skip to main content
Glama
Sign In

AtlasAdapt

by com.atlasadapt
OverviewDiscussionsAdmin

Compare upgrade options side by side

compare_plans
Read-onlyIdempotent

Price 2 to 5 options (sets of upgrades) for the SAME building on the same basis and return them side by side: cost, incentives counted, net upfront, annual benefit, yearly loss avoided, payback, net over the horizon. Our recommended plan is added as an extra option unless include_recommended is false. One estimate per option, each billed as one request. 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>",
      "options": "<options>"
    },
    "name": "compare_plans"
  }
}

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 …
optionsYes
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.
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
include_recommendedNoAdd our recommended plan as an option. Default true.
planned_install_dateNoYYYY-MM-DD. Decides which programmes are open.

Output Schema

NameRequiredDescriptionDefault
okYes
optionsYes

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 / include_recommended / description
      Previous value: -"Commercial: add our recommended plan as an option. Default true."New value: +"Add our recommended plan as an option. Default true."
  5. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world, but the description adds substantial non-obvious context: each estimate is billed as one request, non-counting/contingent/competitive incentives must be excluded from totals, conditions must be shown alongside each incentive, incentives referenced by ref, and amounts are guidance to be confirmed with the grantor.

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?

Purpose and returned metrics are front-loaded in the first sentence, with rules following. It is dense but every clause (billing, incentive exclusion, refs, disclaimer) carries real information; only the enumeration of return fields is slightly redundant given the output schema.

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 nested objects and an output schema, the description covers the critical behavioral hazards (incentive counting rules, per-option billing, guidance-only amounts) and defers return-value detail to the schema. Minor gaps remain around pricing basis defaults and discount/horizon handling, which the schema partly covers.

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 69%, so the schema does most of the work on address, building, home_value and org_type semantics. The description adds meaning only for include_recommended and for what 'options' means; it also says '2 to 5 options' while the schema allows minItems 1, a small inconsistency an agent must resolve themselves.

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?

States a specific verb (price, side by side) and resource (2–5 options/sets of upgrades for the same building on the same basis) and enumerates exactly what comes back: cost, incentives counted, net upfront, annual benefit, loss avoided, payback, net over horizon. The 'multiple options side by side vs one estimate' framing implicitly but clearly separates it from single-estimate siblings.

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?

Makes the use case explicit ('2 to 5 options for the SAME building on the same basis'), and gives the conditional behavior of include_recommended. It doesn't name estimate_plan as the alternative for a single option or state when-not to use it, so it stops short of full routing guidance.

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