Measure property from satellite imagery, price 24 trades, and install contractor quote widgets.
Scored across 8 tools
Most tools target clearly distinct steps: account creation, install snippet, installation verification, pricing, trades, cost estimation, and lead guidance. There is mild overlap between estimate_cost, list_trades, and get_pricing because all can return cost or price information, but the descriptions mostly clarify when each applies.
Seven of eight names follow a predictable verb_noun pattern such as create_account, get_pricing, list_trades, and verify_installation. lead_playbook is the lone noun-phrase outlier, but the overall convention remains readable and consistent.
Eight tools is well within the appropriate range for this onboarding, installation, pricing, and estimation workflow. Each tool appears to serve a distinct step rather than padding the surface.
The core contractor lifecycle is covered: create account, get install snippet, verify installation, understand pricing, list trades, estimate costs, and access lead guidance. Minor gaps remain around retrieving or managing an existing account and subscription cancellation, which could create dead ends if a token is lost.
Creates a contractor account and returns their widget token and embed tag, ready to install with get_install_snippet. No password: the owner is emailed a link to choose one. The widget switches on once they sign in through it and add a card in the dashboard ($0 today, nothing charged during the free trial). Only use it when the person you are helping owns the business or has asked you to set this up for them, with their real business email; test, disposable and placeholder addresses are refused.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | No | Business phone, optional. | |
| trade | Yes | What the business quotes: roofing, gutters, gutter_guards, gutter_cleaning, siding, painting, roof_cleaning, pressure_washing, house_washing, solar, paving, sealcoating, concrete, pavers, decks, fencing, landscaping, sod, turf, irrigation, lawn_treatment, leaf_removal, mosquito_control, pools, snow_removal, land_clearing, holiday_lighting. | |
| website | No | The website the widget will go on, optional. | |
| owner_email | Yes | The owner's real email. They receive the set-password link and lead alerts here. | |
| company_name | Yes | The business name, as homeowners know it. | |
| service_area | No | Towns or region served, optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare it is a non-read-only, open-world, non-idempotent, non-destructive write; the description adds the side effects that matter: an email is sent to the owner with a set-password link, no password is set by the agent, and the widget stays off until sign-in plus card entry. The billing note ('$0 today, nothing charged during the free trial') tells the agent what to expect before the call, which is exactly the beyond-annotation context this tool needs.
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?
Four sentences, front-loaded with the action and return value, then side effects, then eligibility constraints. Every clause carries information the agent needs to either call the tool or warn the user; the billing parenthetical in particular prevents a surprise charge complaint.
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?
There is no output schema, but the description names the two returned artifacts (widget token and embed tag) and the activation condition. Combined with the annotation coverage, an agent knows the auth flow, the side effects, the eligibility limits, and what comes back — nothing material is missing for a 6-parameter mutation tool.
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 100%, so the schema already documents all six parameters and the baseline is 3. The description still adds a real constraint not present in the schema — that disposable, test, and placeholder values for owner_email are refused — which changes how the agent should source that argument. The other five parameters get no extra treatment, so it stays below a 5.
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?
States a specific verb and resource ('Creates a contractor account') and goes further by naming the return payload ('widget token and embed tag'), which an agent can act on immediately. It also disambiguates from the sibling get_install_snippet by framing it as the follow-up step rather than a competing action.
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?
Explicitly gates usage: only when the person owns the business or asked for the setup, and only with a real business email. It also states a hard exclusion ('test, disposable and placeholder addresses are refused') and points to get_install_snippet as the next tool, so the agent knows both when to call it and what to do after.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turns a measurement into a national cost range for a trade. For roof trades, pass the building footprint and the pitch - the roof surface multiplier is applied for you. Returns the range, the per-unit rates, what drives the price, and the limits of the estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| trade | Yes | Trade id or name, e.g. roofing, fencing, artificial-turf. | |
| pitch_rise | No | Roof rise per 12 inches of run, e.g. 6 for a 6/12 roof. Roof trades only. Defaults to 6. | |
| measurement | Yes | Square feet, or linear feet for perimeter trades such as fencing and gutters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It does this well by disclosing the tool's output components (range, per-unit rates, price drivers, estimate limits) and the automatic roof surface multiplier behavior. It does not mention data sources or exact calculation assumptions, but for a read-only estimation tool this is reasonably transparent.
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 three sentences with no filler: it front-loads the core purpose, then adds the critical roof-trade special case, then summarizes return value. Every sentence contributes.
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?
There is no output schema, so the description appropriately summarizes the return content. It covers the main input behavior, the roof-specific nuance, and what the caller gets back. It does not explain how to choose between this and get_pricing, but for invoking this tool correctly with the provided schema, the description is sufficient.
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 100%, so the baseline is 3. The description adds meaningful semantic value beyond the schema by clarifying that for roof trades, measurement is the building footprint and that pitch feeds into an automatically applied surface multiplier. This elevates the parameter understanding beyond raw field definitions.
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 states a specific operation: turns a measurement into a national cost range for a trade, with a clear roof-trade special case. It is clear and actionable, but it does not explicitly distinguish itself from the sibling get_pricing, so it falls just short of full sibling differentiation.
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?
The description gives clear context for when to use the tool (estimating cost from a measurement) and provides concrete usage guidance for roof trades, explaining how to pass footprint and pitch. It does not explicitly name alternative tools or state when not to use it, so it lacks exclusions but still offers solid contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The exact script tag to paste, plus ordered steps for the given platform. Pass the contractor's own token if you have it; otherwise the snippet comes back with a placeholder and instructions for finding the real one.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | inline embeds the tool in the page; modal opens it from a button; floating puts that button in the corner of every page. | |
| token | No | The contractor's public token, beginning pk_live_. | |
| service | No | Trade the widget should quote, set as data-service on the embed tag: roofing, gutters, gutter_guards, gutter_cleaning, siding, painting, roof_cleaning, pressure_washing, house_washing, solar, paving, sealcoating, concrete, pavers, decks, fencing, landscaping, sod, turf, irrigation, lawn_treatment, leaf_removal, mosquito_control, pools, snow_removal, land_clearing, holiday_lighting. Defaults to the contractor's own default trade. | |
| platform | No | Platform id or name, e.g. wordpress, squarespace, wix, webflow, shopify, godaddy, html, google-tag-manager. Omit for the generic snippet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full load. It does disclose a genuinely useful behavioral trait — the degraded path where a missing token yields a placeholder plus instructions for finding the real one — but says nothing about auth requirements, error behavior for an unrecognized platform, or whether the operation has any side effects.
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 sentences, front-loaded with the deliverable (script tag + ordered steps) followed by the one conditional the caller must decide. No filler, no restating of the tool name.
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?
With no output schema and no annotations, the description does the right work: it says what is returned and how the token affects the result. Minor gaps remain around omitted-platform behavior (generic snippet) and error handling, but an agent has enough to call this correctly.
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 100%, so the baseline is 3, and the description earns above that by explaining the consequence of omitting token (placeholder output plus recovery instructions). It doesn't add detail on mode or service beyond the schema, but the token fallback semantics are real added meaning.
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 states specifically what comes back: 'the exact script tag to paste, plus ordered steps for the given platform.' That is a concrete resource (embed snippet + install steps) and is clearly distinct from siblings like verify_installation and list_platforms, though it never names those siblings explicitly.
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?
There is clear conditional guidance for the token parameter ('pass the contractor's own token if you have it; otherwise...'), but nothing says when to reach for this tool versus list_platforms or verify_installation, or what to do if the platform id is unknown. Usage is implied by the purpose rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live plan prices, trial length, what happens to the card during the trial, and how cancellation works. Read this rather than quoting a price from memory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool's informational nature and that prices are 'live', implying a non-cached read. However, it doesn't state the return format, whether any side effects occur, or that it's read-only. For a zero-parameter lookup tool, this is adequate but not exhaustive.
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 sentences with no filler. The key content (prices, trial length, card handling, cancellation) is front-loaded, and the usage hint adds value without redundancy. It is efficiently structured and easy to scan.
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?
For a parameterless tool with no output schema or annotations, the description covers the essential information an agent needs: what data is available and the caveat to use live data. It doesn't specify return type or structure, but for a simple lookup this is not a significant gap. The description is sufficient for correct invocation.
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?
The tool has zero parameters, so the baseline is 4. There is nothing to explain about parameters, and the description correctly focuses on the content rather than any input semantics. No additional parameter detail is needed.
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 clearly states the tool retrieves live plan prices, trial length, card handling during trial, and cancellation terms. It specifies the resource (pricing) and the exact content, and the closing phrase 'Read this rather than quoting a price from memory' gives a concrete use case that distinguishes it from estimate-oriented tools like estimate_cost.
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?
The description implies when to use it: whenever current pricing or trial details are needed, explicitly cautioning against relying on memory. It doesn't name alternatives or exclusions, but the context makes the appropriate use clear, especially given the sibling list includes estimate_cost for estimates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What actually moves the needle on inbound leads for a specific contracting trade — roofing, paving, landscaping, gutters, siding, decks, pools, turf or solar — with the numbers behind each step.
| Name | Required | Description | Default |
|---|---|---|---|
| trade | No | One of: roofing, paving, landscaping, gutters, siding, decks, pools, turf, solar, general. Defaults to a general contracting playbook. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining what the tool returns. It reveals that the playbook contains steps with underlying numbers, which is useful, but it never explicitly states that this is a read-only retrieval or what the response format looks like. For a content-retrieval tool this is acceptable, but not richly transparent.
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 a single, tightly scoped sentence with no filler. It front-loads the value proposition and enumerates the trades efficiently, though it is a noun phrase rather than a full imperative sentence. Every word contributes to conveying scope and content.
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?
For a single-parameter, no-output-schema tool, the description conveys the essential context: the problem it addresses, the trades it covers, and the nature of the deliverable. The schema handles the allowed values and default. It would be marginally stronger if it mentioned the 'general' fallback trade or response format, but nothing critical blocks correct invocation.
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?
The schema already documents the single trade parameter at 100% coverage, including allowed values and the default behavior. The description repeats some trade names but adds little beyond contextual framing around contracting trades. Since schema coverage is high, the baseline of 3 is appropriate.
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 title states the action and resource clearly: 'Get a lead-generation playbook for a trade.' The description adds specific scope — inbound lead generation for contracting trades such as roofing, paving, and solar — and distinguishes this from pricing, estimation, and installation tools among the siblings. It lacks an explicit verb in the description itself, but the intent is unambiguous.
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?
The description implies when to use the tool: when the agent needs a lead-generation playbook for a specific contracting trade, with quantified steps. However, it does not explicitly discuss when not to use it or compare it to alternatives like list_trades or get_pricing. The use case is clear enough, but there is no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The website builders and CMSs there are step-by-step install instructions for, with how long each takes. Call this first when you do not know what the contractor's site is built with.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the returned content (list of platforms and time estimates) but does not explicitly state that this is a read-only operation or describe any limitations, pagination, or data source behavior. For a simple list tool this is adequate but not rich.
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 a single compact sentence that front-loads the tool's purpose. The grammar is slightly awkward ('The website builders and CMSs there are...'), but it conveys all key information without unnecessary words.
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?
With zero parameters and no output schema, the description covers the key facts: what is listed (platforms with install instructions), the time information, and when to invoke it. It could be more explicit about the return format, but it is sufficient for an agent to call it appropriately.
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?
The tool has zero parameters, so the baseline is 4. The description need not discuss parameter details, and it doesn't.
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 clearly states the tool lists website builders and CMSs that have step-by-step install instructions, along with install duration. The scope is specific and easily distinguished from siblings like get_install_snippet, get_pricing, and verify_installation.
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?
It provides explicit guidance: 'Call this first when you do not know what the contractor's site is built with.' This gives a clear trigger and ordering but does not explicitly name alternatives or when-not-to-use scenarios, so it falls slightly short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every trade the product can price from aerial measurement, with what each is measured from - roof surface, ground area, wall area or perimeter - and the national cost range per unit. Use this to answer whether a given business can be quoted this way.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Optional trade name or synonym, e.g. "fence", "blacktop", "synthetic grass". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It explains what the tool lists (trades) and the type of information included (measurement basis and cost ranges), but it does not disclose potential side effects (likely none, read-only), performance, or any error conditions. For a read-only listing tool, this is adequate but not rich.
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 two sentences: the first states the tool's output and content, the second gives a clear use case. Every word earns its place, no fluff, and the key information (what it lists and how to use it) is front-loaded.
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?
For a simple listing tool with one optional parameter and no output schema, the description is complete enough to guide an agent. It explains what is returned (trades, measurement basis, cost ranges) and the use case. It might lack detail on the exact structure of output, but for a list tool that is acceptable. The sibling tools are distinct, so the context is well-covered.
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?
The schema documentation already covers the parameter 'search' (optional trade name or synonym) with examples. The description does not add much beyond what the schema says, but it implies the search is for filtering trade names. Given 100% schema coverage, the description's marginal addition (that the list can be filtered to answer specific queries) still adds value by setting expectation that search is optional and for lookup.
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 clearly states the tool's purpose: it lists trades that can be quoted from satellite imagery, along with what each is measured from and cost ranges. It distinguishes itself from siblings by focusing on the list of priceable trades rather than cost estimation or other functions.
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?
The description explicitly guides when to use the tool: to answer whether a given business can be quoted this way. It does not name specific alternative tools, but the phrase 'Use this to answer whether a given business can be quoted this way' implies it should be used before estimating costs or getting pricing, providing clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches a public page and reports whether the embed tag is present, whether the token resolves to a real account, whether the widget is actually serving, and what to fix. Use this after the contractor says they have pasted the tag.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The public page URL to check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the operational behavior: fetching a public page, checking several conditions, and providing what to fix. It implies a read-only network operation and does not mention side effects, authentication, or rate limits, but for a verification tool these are reasonably implied. The description adds value beyond a mere 'checks installation' by enumerating the checks.
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 two sentences: one states the purpose and the checks, the second gives usage guidance. It is front-loaded with the action and outcome, with zero filler. Every word earns its place.
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 no output schema, the description provides a useful preview of the result by listing what it reports (embed tag presence, token validity, serving status, and fixes). It doesn't specify error handling or edge cases (e.g., invalid URL, network failure), but for a single-parameter read-only tool this is adequate. Slightly more detail on output format would push it to 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?
The schema covers the only parameter (url) with a clear description ('The public page URL to check.'), and coverage is 100%. The description does not add extra details like URL format requirements or validation rules, so it stays at the baseline of 3 – the schema already does the heavy lifting.
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 uses a specific verb ('fetches' and 'reports') and names the resource (public page) plus the exact checks performed (embed tag presence, token validity, widget serving, and remediation steps). It clearly distinguishes from siblings like get_install_snippet (which returns the snippet, not verification) and estimate_cost/list_trades (unrelated). The purpose is unambiguous.
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?
The description gives an explicit trigger: 'Use this after the contractor says they have pasted the tag.' This tells the agent when to invoke it. It does not explicitly name alternatives or state when not to use it, but the sibling set makes the context obvious (get_install_snippet is for obtaining the tag, not verifying it). The use case is clear enough for a 4.
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.
get_install_snippet2 fields changedInput schema / properties / mode / descriptionPrevious value: -"inline embeds the tool in the page; modal opens it from a button."New value: +"inline embeds the tool in the page; modal opens it from a button; floating puts that button in the corner of every page."Input schema / properties / mode / enumPrevious value: -[
- "inline",
- "modal"
-]New value: +[
+ "inline",
+ "modal",
+ "floating"
+]create_account1 field changedInput schema / properties / trade / descriptionPrevious value: -"What the business quotes: roofing, gutters, gutter_guards, siding, painting, roof_cleaning, pressure_washing, solar, paving, sealcoating, concrete, pavers, decks, fencing, landscaping, sod, turf, irrigation, pools, snow_removal, land_clearing, holiday_lighting."New value: +"What the business quotes: roofing, gutters, gutter_guards, gutter_cleaning, siding, painting, roof_cleaning, pressure_washing, house_washing, solar, paving, sealcoating, concrete, pavers, decks, fencing, landscaping, sod, turf, irrigation, lawn_treatment, leaf_removal, mosquito_control, pools, snow_removal, land_clearing, holiday_lighting."get_install_snippet1 field changedInput schema / properties / service / descriptionPrevious value: -"Trade the widget should quote, set as data-service on the embed tag: roofing, gutters, gutter_guards, siding, painting, roof_cleaning, pressure_washing, solar, paving, sealcoating, concrete, pavers, decks, fencing, landscaping, sod, turf, irrigation, pools, snow_removal, land_clearing, holiday_lighting. Defaults to the contractor's own default trade."New value: +"Trade the widget should quote, set as data-service on the embed tag: roofing, gutters, gutter_guards, gutter_cleaning, siding, painting, roof_cleaning, pressure_washing, house_washing, solar, paving, sealcoating, concrete, pavers, decks, fencing, landscaping, sod, turf, irrigation, lawn_treatment, leaf_removal, mosquito_control, pools, snow_removal, land_clearing, holiday_lighting. Defaults to the contractor's own default trade."create_account1 field changedInput schema / properties / trade / descriptionPrevious value: -"What the business quotes: roofing, gutters, gutter_guards, siding, painting, roof_cleaning, pressure_washing, solar, paving, sealcoating, concrete, pavers, decks, fencing, landscaping, sod, turf, irrigation, pools, snow_removal, land_clearing."New value: +"What the business quotes: roofing, gutters, gutter_guards, siding, painting, roof_cleaning, pressure_washing, solar, paving, sealcoating, concrete, pavers, decks, fencing, landscaping, sod, turf, irrigation, pools, snow_removal, land_clearing, holiday_lighting."get_install_snippet1 field changedInput schema / properties / service / descriptionPrevious value: -"Trade the widget should quote, set as data-service on the embed tag: roofing, gutters, gutter_guards, siding, painting, roof_cleaning, pressure_washing, solar, paving, sealcoating, concrete, pavers, decks, fencing, landscaping, sod, turf, irrigation, pools, snow_removal, land_clearing. Defaults to the contractor's own default trade."New value: +"Trade the widget should quote, set as data-service on the embed tag: roofing, gutters, gutter_guards, siding, painting, roof_cleaning, pressure_washing, solar, paving, sealcoating, concrete, pavers, decks, fencing, landscaping, sod, turf, irrigation, pools, snow_removal, land_clearing, holiday_lighting. Defaults to the contractor's own default trade."create_accountget_install_snippet1 field changedInput schema / properties / service / descriptionPrevious value: -"Trade the widget should quote. Currently only: roofing. For other trades, use estimate_cost for a ballpark instead."New value: +"Trade the widget should quote, set as data-service on the embed tag: roofing, gutters, gutter_guards, siding, painting, roof_cleaning, pressure_washing, solar, paving, sealcoating, concrete, pavers, decks, fencing, landscaping, sod, turf, irrigation, pools, snow_removal, land_clearing. Defaults to the contractor's own default trade."estimate_costget_install_snippetget_pricinglead_playbooklist_platformslist_tradesverify_installationReal quotes from local US contractors for property jobs, ranked in ~48h, plus fair-price checks.
Construction takeoff and estimating for AI agents. Measure a drawing PDF, export a priced estimate.
Construction takeoffs, estimates and bids: measure and count plans, price materials, draft bids.
Construction takeoffs, routes and schedules; PDF to CAD; floor plan to 3D dollhouse and room images.
Add one secure layer between your agents and this server.
