Integrates with Google Cloud's Geocoding API and Solar API to retrieve address geocoding and 3D building elevation data for roof measurements.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@RoofMeasure MCP Measure the roof at 123 Elm Street"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Free EagleView-style satellite roof measurements plus modular Xactimate-style estimating, packaged as an MCP server and CLI for any LLM or agent.
What it measures (from Google Solar API 3D elevation data):
Total roof area (sq ft and squares), with and without waste (0-32% waste table, squares rounded up to 1/3 SQ)
Facet count, per-facet area, pitch, and slope direction
Predominant pitch and areas-per-pitch table
Ridges, hips, valleys, rakes, and eaves lengths (slope-corrected)
Drip edge (eaves + rakes), steep-slope area split for labor surcharges
Suggested waste factor from roof complexity
What it generates:
EagleView-style measurement report (Markdown)
Xactimate-style insurance estimate (.docx) with line items, material sales tax, per-structure summaries, tax recap, and grand total. Fully modular: company name/logo, estimator, homeowner, claim info, pricing rules, tax rate, waste %, component counts, and O&P toggle are all configurable.
Get a free Google Cloud API key with the Geocoding API and Solar API enabled (console.cloud.google.com). The $200/month free credit covers roughly 1,000 roof lookups.
Install:
pip install git+https://github.com/thegimmieapp/roofmeasureMCP.git
# or from a local clone:
pip install -e .Set your key:
export GOOGLE_MAPS_API_KEY="your_key_here"Related MCP server: EnergyAI MCP
Add to your MCP config (e.g. claude_desktop_config.json):
{
"mcpServers": {
"roofmeasure": {
"command": "roofmeasure-mcp",
"env": {
"GOOGLE_MAPS_API_KEY": "your_key_here",
"ROOFMEASURE_OUT_DIR": "/path/for/reports",
"ROOFMEASURE_LOGO": "/path/to/company_logo.png"
}
}
}
}Claude Code: claude mcp add roofmeasure -e GOOGLE_MAPS_API_KEY=your_key -- roofmeasure-mcp
Tool | Purpose |
| Full JSON measurements |
| EagleView-style Markdown report file |
| Xactimate-style .docx estimate |
The estimate tool enforces contractor intake: if homeowner name or date of
loss are missing it returns needs_info so the agent asks the user before
generating.
roofmeasure measure "3708 Ebony Hollow Pass, Austin, TX 78739"
roofmeasure report "3708 Ebony Hollow Pass, Austin, TX 78739" -o report.md
roofmeasure estimate "3708 Ebony Hollow Pass, Austin, TX 78739" # prompts for homeowner, date of loss, claim #Geocodes the address, pulls Google Solar API buildingInsights and
dataLayers (0.1 m/px digital surface model + roof mask GeoTIFFs).
Segments the DSM into planar facets (region growing on slope + aspect).
Classifies every facet boundary: shared boundaries become ridges, hips, or valleys (by relative elevation and facing); perimeter boundaries become eaves or rakes (by edge direction vs the facet's downslope direction). Sloped edge lengths are slope-corrected in 3D.
If high-resolution DSM data is not available for an address, it falls back to roof-segment statistics and clearly flags edge lengths as ESTIMATED.
This tool is free and uses the best publicly available elevation data. It is strong on areas, pitch, and squares; edge classification is measured from the DSM but can be affected by tree cover, imagery age, and resolution. It does not carry an accuracy guarantee - field verify before ordering material, as you would with any measurement report.
Architectural laminated shingles + synthetic 30# felt only
1:1 replacement of existing components
~$550/SQ blended target across core roofing components (shingle unit price back-solved)
Steep-roof labor surcharges at 8/12-9/12 and 10/12+ tiers from the measured pitch table
Material sales tax applied to the material fraction of each line item
Overhead & Profit OFF by default (include_op: true to add 10/10)
MIT license.
Generate an EagleView-style roof measurement report (Markdown file) for an address. Returns JSON with the saved file path and a summary.
Args: address: Full property address. company: Company name stamped on the report. contact: Contact person shown on the report (optional). phone: Contact phone shown on the report (optional).
| Name | Required | Description | Default |
|---|---|---|---|
| phone | No | ||
| address | Yes | ||
| company | No | Stronghouse Solutions | |
| contact | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description reveals it saves a file and returns path/summary, but lacks details like file location, overwrite behavior, or external dependencies.
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 informative sentences plus an args list. No redundant or irrelevant information. Well-structured.
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?
Has output schema, so return value description is sufficient. 1 required param, all explained. Minor lack of usage context prevents a 5.
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 0%, but description provides clear semantics for all 4 parameters (address, company, contact, phone), including optionality and defaults, adding value over 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 verb 'generate', resource 'roof measurement report', format 'Markdown', and return value. Distinct from siblings like 'generate_xactimate_estimate' and 'measure_roof'.
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?
No guidance on when to use this tool vs siblings. Does not indicate prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an Xactimate-style insurance roofing estimate (.docx).
INTAKE: homeowner name and date_of_loss are REQUIRED for a complete estimate. If missing, this tool returns needs_info listing what to ask the user for; collect it and call again.
Args: address: Full property address (required). homeowner: Homeowner's full name (required; ask the user if unknown). homeowner_phone: Homeowner's phone number. date_of_loss: Date of loss, e.g. 5/14/2026 (required; ask the user). claim_number: Insurance claim number if available. policy_number: Insurance policy number if available. type_of_loss: e.g. Wind/Hail (default), Wind, Hail, Tree/Impact. tax_rate: Combined LOCAL sales tax rate as a decimal (e.g. 0.0825 for Austin TX). If 0, the agent should research the property's combined city/county/state rate and pass it in. price_list: Xactimate price list code, e.g. TXAU8X_JUL26. If empty, one is generated from the state and current month. waste_pct: Shingle waste percent. If 0, the suggested waste factor from the measurement's complexity analysis is used. components_json: JSON object of component counts, e.g. {"pipe_jacks": 3, "turtle_vents": 4, "ridge_vent_lf": 40, "exhaust_caps": 1, "skylights_flash": 1, "chimneys": 1}. company_name/company_tagline/company_city/estimator_name: Branding overrides so any contractor can use this tool. include_op: Include 10/10 Overhead & Profit (OFF by default). measurements_json: Optional pre-computed output of measure_roof to avoid re-measuring.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| tax_rate | No | ||
| homeowner | No | ||
| waste_pct | No | ||
| include_op | No | ||
| price_list | No | ||
| claim_number | No | TBD | |
| company_city | No | ||
| company_name | No | Stronghouse Solutions | |
| date_of_loss | No | ||
| type_of_loss | No | Wind/Hail | |
| policy_number | No | TBD | |
| estimator_name | No | Stronghouse Solutions | |
| company_tagline | No | Roofing & Exteriors | |
| components_json | No | {} | |
| homeowner_phone | No | ||
| measurements_json | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It reveals that missing required fields triggers a needs_info response, and that defaults are applied for tax_rate, price_list, waste_pct. It also notes the output format (.docx). Missing: description of any side effects or state changes, but the tool is likely read-only for generation. Overall, good coverage.
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 well-structured: a one-line purpose, followed by a critical note on required fields, then a detailed Args list. Each sentence adds value. It is relatively long (17 parameters explained), but the information density justifies the length. Minor redundancy: some parameter names are repeated, but it remains clear.
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 17 parameters, no annotations, and presence of output schema (not used for return info), the description covers nearly all aspects: required fields, defaults, optional overrides, integration with measure_roof (measurements_json), and edge case handling. The agent has sufficient information to invoke the tool correctly, including what to ask the user and when to retry.
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 description coverage is 0%, so the description must fully compensate. The 'Args:' section explains each parameter in detail: what it is, default behavior, how to obtain values (e.g., 'ask the user'), and dependencies. For example, tax_rate explains researching the rate, price_list explains auto-generation. This adds significant meaning beyond the schema's bare property names.
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 starts with a clear verb and outcome: 'Generate an Xactimate-style insurance roofing estimate (.docx).' It specifies the output format and distinguishes from siblings (generate_roof_report, measure_roof) by focusing on estimate generation. It also clarifies required fields and edge cases (missing info returns needs_info).
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?
Provides explicit guidance on required fields (homeowner name, date_of_loss) and how to handle missing info (returns needs_info, collect and call again). Mentions optional pre-computed measurements from measure_roof to avoid re-measuring. Could improve by explicitly stating when not to use this tool versus siblings, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measure a roof from satellite data. Returns full JSON measurements: total area (sq ft + squares), facet count and detail, predominant pitch, areas per pitch, ridges/hips/valleys/rakes/eaves lengths (ft), waste table (squares with 0-32% waste), suggested waste factor, and steep-slope split.
Args: address: Full property address (street, city, state, zip).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only lists outputs and args. It does not disclose whether the operation is read-only, requires authentication, has rate limits, or what happens on invalid addresses.
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 main action and then details output. It is appropriately sized, though the long list of output fields could be slightly condensed.
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 complexity of roof measurement, the description covers return values well and has an output schema. However, it lacks behavioral context (idempotency, prerequisites, cost) and does not leverage annotations.
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 0%, but description fully explains the 'address' parameter: 'Full property address (street, city, state, zip).' This adds necessary meaning beyond the bare schema type.
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 measures a roof from satellite data and lists detailed output. It distinguishes from siblings (generate_roof_report, generate_xactimate_estimate) by focusing on raw measurements rather than reports or estimates.
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?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when to prefer measure_roof over generate_roof_report or generate_xactimate_estimate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0generate_roof_reportgenerate_xactimate_estimatemeasure_roofEach tool serves a distinct purpose: measuring roofs, generating markdown reports, and creating Xactimate estimates. There is no overlap or ambiguity.
All tool names follow the snake_case verb_noun pattern consistently. Two start with 'generate_' and one with 'measure_', which is a clear and predictable convention.
With only 3 tools, the server is lean but covers the essential functions for roof measurement and estimate generation. Each tool earns its place, though a few more complementary tools might be expected.
The tool set covers the full workflow: measure roof, generate a report, and create a detailed estimate. No critical gaps are apparent, and missing inputs are handled gracefully.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
One-call installer quote review plus energy incentives, estimates, scores, and routing for agents.
Turn construction drawings into takeoffs, measured routes, schedules and estimates.
Free solar & home energy tools: estimates, incentives by ZIP, scores, installer routing.
Construction takeoff and estimating for AI agents. Measure a drawing PDF, export a priced estimate.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/thegimmieapp/roofmeasureMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
