Turn a US address or parcel number into an interactive 3D flyover listing in about a minute.
Scored across 3 tools
The three tools map cleanly onto distinct intents: create a new listing, retrieve an existing one, and fetch pricing. There is no overlap — create_3d_listing is the only write path and get_listing/get_pricing are read-only with different resources (listing vs. plan costs). An agent can pick the right tool from the name alone.
All three follow a strict snake_case verb_noun pattern (create_3d_listing, get_listing, get_pricing), so the prefix signals the action and the suffix the resource. No mixed conventions or vague standalone verbs.
Three tools is a tight but honest surface for a narrow service: generate a listing, look one up, check cost. Each tool clearly earns its place with no filler, though the surface is small enough that a little more capability could reasonably be exposed.
The create-and-retrieve lifecycle is covered, plus pricing, so the core workflow (build a listing, share the link, explain cost) has no dead end. Minor gaps remain: there is no way to list a user's prior listings or look one up by address instead of a listing id.
Build a cinematic, interactive 3D flyover listing of a real property from a street address (or a parcel/APN number), with the parcel boundary drawn on the terrain. Takes about a minute. Returns a free watermarked preview link the user can open on any phone, plus the link to unlock it: $25 gets the clean branded listing PDF, hosted and ready to text (call get_pricing for what each plan includes). A lot made here has no free PDF preview; one made on parcellaunch.com gets one watermarked PDF preview. Use this for raw land, acreage, odd lots, waterfront and new-construction dirt: anywhere a flat satellite photo undersells the property.
| Name | Required | Description | Default |
|---|---|---|---|
| apn | No | Parcel number / APN, e.g. "07-11-31-7016-0RP0B-0030". Requires state and county. Florida resolves instantly and free. | |
| state | No | Two-letter state code — required when using apn. | |
| county | No | County name — required when using apn. | |
| address | No | Full US street address, e.g. "123 Main St, Palm Coast, FL 32137". The lot lines come from public parcel maps, statewide in Florida and Indiana, county by county everywhere else, and the listing PDF's aerial photo covers the lower 48 states. Use this unless the user only has a parcel number. | |
| asking_price | No | Optional asking price in dollars. When given, it floats on the 3D view — this is what makes buyers stop scrolling. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral load and does well: it discloses the ~1 minute runtime, the $25 unlock cost, the watermark on the free preview, and geographic coverage limits (Florida and Indiana statewide, county by county elsewhere, aerial lower 48). Missing are any auth/permission requirements, failure modes, or whether regeneration is billed again.
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 core capability and the address-vs-APN guidance are front-loaded, but pricing and plan details ("$25 gets the clean branded listing PDF... call get_pricing for what each plan includes") sprawl into a pitch that belongs in the pricing tool, and the free-PDF-preview sentence is convoluted.
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, and the description compensates by naming what comes back (a watermarked preview link and an unlock link) and the cost to unlock. For a creation tool with no annotations it is close to complete, though permission and re-run behavior remain unstated.
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. The description adds modest meaning beyond the schema – APN requires state and county, Florida resolves instantly and free, and asking_price floats on the 3D view – but most of this is already repeated in the per-field schema descriptions.
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 artifact: build a cinematic interactive 3D flyover listing from an address or APN, with the parcel boundary drawn on terrain. It also names the deliverable (preview link plus unlock link) and routes to get_pricing, so an agent can distinguish it from its siblings.
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?
Gives concrete when-to-use guidance ("raw land, acreage, odd lots, waterfront and new-construction dirt: anywhere a flat satellite photo undersells the property") and states an alternative path (a listing made on parcellaunch.com gets a watermarked PDF preview). It does not say when not to use it, e.g. whether an existing listing should be fetched via get_listing instead of regenerating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a ParcelLaunch listing that was already created, by its listing id. Returns the address, whether the parcel boundary was found, the 3D render status, the shareable links, and whether the lot holds LIVE (the clean 3D link buyers explore, given as live_url). A lot without LIVE shares a watermarked 3D preview. A ParcelLaunch sample lot (such as f2c2bcc732) answers sample: true and no asking_price: it is a sample listing, not for sale.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | The listing id returned by create_3d_listing (e.g. "f2c2bcc732"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it enumerates what is returned (address, boundary-found flag, render status, shareable links, live_url), explains that non-LIVE lots get a watermarked preview, and warns that sample lots return sample: true with no asking_price. It omits auth/permission requirements and error behavior for an unknown id, which keeps it at 4.
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?
Front-loaded with the core lookup statement, then the return contents, then the watermark and sample-lot caveats in order of likely relevance. It is a touch long, and the sample-lot example id (f2c2bcc732) is slightly redundant with the schema example, but no sentence is wasted.
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 must explain return values itself — and it does, covering address, boundary status, render status, links, LIVE/live_url, watermark behavior, and the sample-lot shape. For a one-parameter lookup this is complete enough to call and interpret 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 description coverage is 100% for the single listing_id parameter, so the schema already documents it fully. The description only re-frames the id as belonging to an already-created listing and adds no format or validation detail, which is the baseline 3.
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+resource+key: 'Look up a ParcelLaunch listing that was already created, by its listing id.' The phrase 'already created' cleanly separates it from the sibling create_3d_listing and from get_pricing, so an agent can route without opening the schema.
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 'already created' framing plus the schema's reference to create_3d_listing makes the usage context (retrieve a listing produced by create_3d_listing) clear. There is no explicit when-not or named alternative for a failed/missing lookup, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current ParcelLaunch pricing and what each plan includes. Free to call — use it to answer any question about cost before recommending a plan.
| 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 transparency burden. It discloses 'Free to call' (no cost, likely no rate limits) and describes the tool's output (pricing and plan inclusions). This is adequate for a read-only tool with no parameters and no 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?
The description consists of two concise, front-loaded sentences. The first sentence states the core purpose, and the second provides usage guidance. Every word adds value with no redundancy or fluff.
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 tool with no parameters and no output schema, the description fully explains what the tool does and when to use it. It covers the key return content (pricing and plan inclusions) and adds a usage hint. No additional information is necessary for an AI agent to use this tool 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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information because none is needed; it simply states the purpose. Schema coverage is 100% (empty schema), so no additional value is required.
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 returns 'Current ParcelLaunch pricing and what each plan includes.' It uses the specific verb-phrase 'get' implicitly and distinguishes from sibling tools 'create_3d_listing' and 'get_listing' by focusing solely on pricing and plan details.
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 usage with 'Free to call — use it to answer any question about cost before recommending a plan.' This provides clear context and a recommended use case, though it does not explicitly mention when not to use it or alternative tools.
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.
create_3d_listing1 field changedInput schema / properties / address / descriptionPrevious value: -"Full street address, e.g. \"123 Main St, Palm Coast, FL 32137\". Works nationwide. Use this unless the user only has a parcel number."New value: +"Full US street address, e.g. \"123 Main St, Palm Coast, FL 32137\". The lot lines come from public parcel maps, statewide in Florida and Indiana, county by county everywhere else, and the listing PDF's aerial photo covers the lower 48 states. Use this unless the user only has a parcel number."get_listing1 field changedInput schema / properties / listing_id / descriptionPrevious value: -"The listing id returned by create_3d_listing (e.g. \"7291ac49b3\")."New value: +"The listing id returned by create_3d_listing (e.g. \"f2c2bcc732\")."create_3d_listingget_listingget_pricingUS parcel records plus utilities, power, grid, environmental and logistics data by address or point.
Address in. Defendable offer out. 60 seconds. Comps, ARV, repairs and max offer for any address.
Any US address: flood, HUD rent, county tax. Parcel zoning/STR rules: Nashville, Denver, Scottsdale.
Enhance, virtually stage and turn real estate listing photos into video with AI.
Add one secure layer between your agents and this server.
