AirDNA MCP Server (Beta)

Connect

Add AirDNA to your AI assistant, then sign in with your AirDNA account. The assistant gets tools scoped to your plan and connected properties — see Access.

Add AirDNA from the Claude directory

One click from the connector directory, then sign in with AirDNA.

Add AirDNA to Claude →

Or add it manually:

Settings → Connectors → Add custom connector, then fill in both fields and sign in:

Remote MCP server URL	`https://mcp.airdna.co`
OAuth Client ID (under Advanced settings)	`478a2ed7-0d70-4feb-a340-d8c96dcd4c2b`

claude mcp add --transport http \
  --client-id 478a2ed7-0d70-4feb-a340-d8c96dcd4c2b \
  airdna https://mcp.airdna.co

claude mcp login airdna

A browser opens to sign in with AirDNA. The client ID is public; no secret required.

codex mcp add airdna \
  --url https://mcp.airdna.co \
  --oauth-client-id 478a2ed7-0d70-4feb-a340-d8c96dcd4c2b

codex mcp login airdna --scopes mcp,offline_access

A browser opens to sign in with AirDNA. The client ID is public; no secret required.

Support for Cursor, VS Code and other MCP clients is on the way. Check back soon.

After connecting

Ask your assistant: what AirDNA tools do you have? If no tools appear, sign out and authenticate again. Access is based on your AirDNA plan and connected properties.

Access & plans

What you can do depends on your AirDNA account. Two tiers:

Any AirDNA account

For-sale data, on every plan, no properties required. The for-sale tools cover MLS inventory with AirDNA's short-term-rental projections attached, and for now they are the only data tools available without Adapt — plus submit_feedback, open to everyone for sharing feedback or reporting issues.

AirDNA Adapt users

Listings, pricing, rules, comps and portfolio tools require AirDNA Adapt with connected properties. Once your properties are onboarded to Adapt these tools light up; until then they return a “no connected properties” message. Pushing rates to your PMS requires a trial or paid Adapt plan.

Each tool below is labeled with the entitlement component it needs. Tools you don't have access to are simply hidden from your assistant.

Recipes

Starting prompts for your own assistant. Open one to see the full prompt, copy it, fill in the brackets, and send it. Each names the tools it needs, so a client that has them will route straight there.

The chips on each card are the entitlement components it uses. A + chip is optional — the recipe works without it and says which section to drop, so the same prompt suits any plan. A tool your plan doesn't cover is hidden from your assistant rather than returning an error, so each recipe says what to do when a tool simply isn't there.

Show coming-soon recipes (6)

Your properties

Strategy & Rules Overview adapt rms_read A plain-English read on what your pricing setup actually does — not which preset you picked.

list_my_listings get_listing_details preview_strategy

Explain what my pricing setup is actually doing, in plain English.

Start with list_my_listings using view="full". If I have more than one listing, show me the list and ask which one I mean before going further. Then call get_listing_details with include=["rules"] for that listing.

Give me these sections:

- Posture — one sentence naming what my setup effectively does, for example "a premium hold with strong far-out protection but soft last-minute pricing."
- Active rules — a table: what each rule does, the dates it covers, and what it means for my nightly rate in practice.
- Conflicts — any rules that contradict each other, cancel out, or will never fire. Name them directly.
- Gaps — anything I would reasonably expect to have set and don't: a price floor, a ceiling, weekend minimum stays.

Use section headings, not numbered sections. Translate settings into rate outcomes. Don't just list the fields back to me or restate the strategy's name. This is read-only: don't change anything.

Portfolio Check-In adapt rms_read How the next few months are pacing versus the same point last year, and where the gaps are.

get_portfolio_performance list_my_listings

Show me how my portfolio is pacing compared with this point last year.

Call get_portfolio_performance twice with view="pacing_metrics": once with as_of_date set to today, and once with as_of_date set to the same day one year ago. Compare the two.

Give me these sections:

- Month by month — a table: revenue, occupancy, and ADR on the books now versus the same point last year, with the difference.
- Behind and ahead — the two or three months furthest behind, and the two or three ahead.
- Rate or occupancy — for each month that's behind, which of the two is the problem.
- Verdict — on track or not, and what I should look at first.

Use section headings, not numbered sections. If a month has very little on the books yet, say so rather than reading a trend into it. Use list_my_listings if you need to name specific listings.

Listing Benchmarking adapt rms_read One listing measured against its own prior year and against what its comps are charging.

list_my_listings get_portfolio_performance get_listing_comps get_listing_comp_performance get_listing_comp_rates

Benchmark one of my listings against last year and against its comps.

Use list_my_listings to find the listing — ask me which one if I have more than one. Then pull:
- get_portfolio_performance with view="pacing_metrics" and listing_ids set to that listing, once with as_of_date today and once with as_of_date one year ago
- get_listing_comp_performance and get_listing_comp_rates for the next 90 days

Give me these sections:

- Month by month — a table: my occupancy and ADR on the books, mine at this point last year, and what my comps are charging for the same dates.
- Out of line — specific dates or weekends where my rates are clearly off the comps, in either direction.
- What last year says — for each of those, what my prior-year booking behaviour suggests I should do.
- Act on first — the three dates worth acting on, numbered in priority order.

Use section headings, not numbered sections; Act on first is the only numbered list, and the numbers there mean priority. Be concrete about dates and dollar amounts, and state which currency you're reporting in. If this listing has no comps stored, tell me that instead of substituting market averages.

Last-Minute Rescue adapt rms_readrms_write Open dates in the next two weeks, and whether I should decrease the rates.

get_listing_details get_listing_comp_rates get_listing_comp_performance save_listing_rules

Find revenue I'm leaving on the table in the next two weeks.

For [LISTING NAME], call get_listing_details with include=["calendar","reservations","rules"], calendar_start_date today and calendar_end_date 14 days out. Then call get_listing_comp_rates and get_listing_comp_performance for the same window.

For each open date, work out whether comps are booked or also sitting open, and how late bookings usually arrive for this listing based on my reservation history.

Give me these sections:

- Headline — whether I have open dates that should see a price decrease. If none do, say so and stop there; skip the rest.
- Dates — a table of available dates, my price, my comps' booked rates, and a suggested price.
- Rules to change — any rule I have set that's working against me, for example a minimum-night stay that could orphan a night.
- Suggested changes — a bulleted list. Require my explicit approval before using save_listing_rules to apply them.

Use section headings, not numbered sections. State which currency you're reporting in. Keep the output simple, approachable, and concise.

Research

Market Scan any account basic_researchcoming soon A shortlist of markets worth investing in, from a long list you can actually sort.

rank_markets compare_markets find_similar_markets resolve_market

Help me build a shortlist of markets to invest in. My criteria: [e.g. United States, mid-size markets, strong occupancy, ADR above $200].

Work in this order:

- rank_markets to build the long list. Sort on one of market_score, revenue_ltm, occupancy_ltm or adr_ltm — those are the only sortable metrics. If my criteria point at something else (investability, regulation, seasonality, rental demand, listing count), use it as a filter or a tiebreaker rather than the sort. Narrow with filters on country_code, market_type, adr_ltm, occupancy_ltm, revenue_ltm, listing_count or market_score, and keep limit at 25 or below.
- compare_markets on the five to eight most promising. It takes combined_market_id values, not names, and between two and ten of them — run resolve_market first if all I gave you were names.
- find_similar_markets on my favourite, to surface anything my filters excluded.

Give me these sections:

- Shortlist — a table: market, country, listing count, market score, ADR, occupancy and annual revenue.
- Head to head — where each shortlisted market wins and loses, using the winner-per-metric and deltas the comparison returns. Regulation is scored so that lower is better; say so if it decides anything.
- Wildcards — markets from find_similar_markets that weren't on the shortlist, and what makes them close.
- Where I'd look first — two or three markets, and what to check next about each.

Use section headings, not numbered sections. State which currency you're reporting in. Every figure is trailing twelve months unless the tool says otherwise. Use only the figures the tools return, and if a metric comes back empty for a market, leave the cell blank and say why rather than filling it.

Market Deep Dive any account basic_research+standard_researchcoming soon One market read end to end — profile, how guests book, trend, and what's on the books.

resolve_market get_market_metrics get_booking_patterns +get_market_timeseries +get_market_pacing

Give me a full read on [MARKET NAME] as a short-term rental market.

Start with resolve_market to get its combined_market_id — get_booking_patterns and get_market_pacing take ids only. Then call get_market_metrics for the profile, and get_booking_patterns for how guests actually book there.

Then deepen it where my plan allows. A tool my plan doesn't cover is hidden from your tool list rather than erroring, so if one of these isn't available to you — or a call comes back as a plan denial — skip that section, name the capability it needs, and carry on:

- get_market_metrics with include=["summary"] for the paid performance rollup. Needs standard_research, and requires both start_date and end_date.
- get_market_timeseries for revenue, occupancy and adr_by_bedroom over the last 24 months. Needs standard_research, which reaches back 36. period_months cannot go below 12, and a series is trimmed to its 200 most recent points — say so if the response is marked truncated.
- get_market_pacing with view="performance_metrics" for what's on the books ahead. Needs standard_research. This is the only forward-looking tool here; everything else is history.

Give me these sections:

- Verdict — three or four sentences: is this a market worth entering, and for whom.
- Profile — the market grade and score, listing count, ADR, occupancy and annual revenue, plus the highlights the tool returns.
- How guests book — average lead time, typical length of stay, and the channel mix.
- Trend — what the timeseries shows over the window you got. Skip if it wasn't available.
- On the books — how the months ahead are pacing. Skip if it wasn't available.
- Guest experience — the common guest profiles, frequently praised amenities and complaint themes the profile returns.

Use section headings, not numbered sections. State which currency you're reporting in, and be explicit about which window each number covers — mixing a trailing-twelve-month figure with a single month's without saying so is worse than leaving it out.

Neighborhood Picker any account basic_research+standard_researchcoming soon Which submarket inside a market to buy in, and what to check before you do.

get_submarket_metrics +rank_submarkets +compare_submarkets +get_submarket_timeseries

Help me pick the right neighbourhood to buy in inside [MARKET NAME].

Submarket names repeat across markets, so always pass market alongside submarket.

If my plan reaches them, start broad:

- rank_submarkets for that market, sorted on market_score, revenue_ltm, occupancy_ltm or adr_ltm — those four only. Needs standard_research. It returns at most 50 rows with a has_more flag and there is no paging, so narrow with filters rather than asking for the next page.
- compare_submarkets on the three to ten strongest, by combined_submarket_id. Needs standard_research.

If those two tools aren't in your list, my plan doesn't include standard_research. Say so, then fall back: ask me which neighbourhoods I'm already considering and profile them one at a time.

Either way, call get_submarket_metrics for the finalists, and get_submarket_timeseries (needs standard_research) for revenue or occupancy over the last 24 months if you can.

Give me these sections:

- Shortlist — a table of the finalists: submarket score, plus ADR, occupancy and annual revenue where you can read them. At the unlocked baseline the score may be the only number available — leave the rest blank and say that's why, rather than guessing.
- Why each one — two sentences per submarket, using the demand drivers and highlights the profile returns.
- Trend — which finalists are improving and which are flattening. Skip if the timeseries wasn't available.
- Where I'd buy — one submarket, one runner-up, and what would change your mind.

Use section headings, not numbered sections. State which currency you're reporting in. Never substitute the parent market's numbers for a submarket's.

Listing Cohort Benchmark any account standard_research+advanced_researchcoming soon How different kinds of rental actually perform in a market — 2BR versus 4BR, pool versus none.

get_str_listing_metrics compare_str_listings +get_str_listing_timeseries

Compare how different kinds of short-term rental perform in [MARKET NAME]. The split I care about: [e.g. 2BR vs 3BR vs 4BR, or pool vs no pool].

Every cohort must be scoped to an area, so include a combined_market_id filter — or combined_submarket_id. Both need standard_research, as the cohort tools themselves do. Resolve the market by name first if you need the id.

Call compare_str_listings with two to five cohorts covering that split, over a full twelve months that has already finished. start_date must be in the past.

Cohorts can be built from bedrooms, bathrooms, accommodates, rating, reviews_count, host_unit_count, channel_mix, market_type and amenities, and a paid research plan adds listing_type, real_estate_type, price_tier, days_available, professionally_managed and submarket scope. All of them need standard_research, the same component the cohort tools do. Amenities use the has_* form, for example {"field":"amenities","type":"jsonb_boolean","value":{"has_pool":true}}. Listing types are home_apartment, private_room and shared_room.

Then, if my plan reaches it, call get_str_listing_timeseries for the two most interesting cohorts — needs advanced_research. If that tool isn't in your list, say my plan doesn't cover it and skip the seasonality section.

Give me these sections:

- Headline — one sentence naming which cohort performs best, and by how much.
- Cohort table — one row per cohort: listing count, net ADR, adjusted occupancy, adjusted RevPAR, and revenue per listing. net_revenue is the total across every listing in the cohort, not what one property earns — divide it by listing_count and label the column so a market-wide total is never read as one property's income. If length of stay or the night counts come back empty, that's a plan limit rather than a data gap — say so.
- Rate or occupancy — for the biggest gap between cohorts, which of the two explains it.
- Seasonality — when each cohort peaks and troughs. Skip if the timeseries wasn't available.
- What this means for me — three or four sentences.

Use section headings, not numbered sections. State which currency you're reporting in, and give the exact date range every figure covers. These are observed results for listings already operating in the market, not a projection for any one property.

Top Performers any account basic_researchstandard_researchadvanced_researchcoming soon The highest-earning listings in an area, and what they have in common.

get_str_listing_table get_listing_detail get_str_listing_metrics +get_listing_history

Show me the top-performing short-term rentals in [MARKET OR SUBMARKET NAME] and what they have in common.

Call get_str_listing_table with a combined_market_id or combined_submarket_id filter — the area anchor is required. Sort on revenue_ltm descending with limit 25. There is no offset parameter, so if I want more, raise the limit (up to 100) rather than paging.

If get_str_listing_table isn't in your tool list, my plan doesn't include advanced_research. Say so, then fall back to get_str_listing_metrics over the same filters to give me the cohort averages — and if that one is missing too, my plan doesn't reach listing research at all. Either way, tell me the per-listing rows are the part I'm missing.

sort_by is separately gated. revenue_ltm, occupancy_rate_ltm, revenue_potential_ltm and days_a_ltm need the paid columns; average_daily_rate_ltm, rating_overall, reviews_count, bedrooms and accommodates are readable at the baseline. If a sort is denied, fall back to average_daily_rate_ltm and say that's what you sorted on.

Then pick the two or three most interesting rows and call get_listing_detail on each. If get_listing_history is available (needs advanced_research), pull 24 months for the single best one — it returns monthly points only.

Give me these sections:

- Leaderboard — a table: title, bedrooms, accommodates, rating, review count, ADR, occupancy and annual revenue, in the order the tool returned them.
- What the winners share — bedroom count, capacity, amenities, review volume. Be specific about how many of the rows share each trait.
- Standouts — any listing earning well above what its size and rating would predict, and a guess at why.
- Track record — how the best one has trended over the last two years. Skip if it wasn't available.
- What I'd copy — three concrete things.

Use section headings, not numbered sections. State which currency you're reporting in. Say which metric you sorted on, and that these are the top rows of that sort rather than the top of the whole market. All figures are trailing twelve months.

Value Markets any account basic_researchfor_salecoming soon Markets where cheaper housing more than offsets lower revenue — the trade revenue alone hides.

rank_markets get_market_metrics get_for_sale_metrics get_for_sale_listings

Find markets where property is cheap enough that lower revenue still beats an expensive market. My criteria: [e.g. United States, budget under $500k, at least 300 active listings].

Revenue alone will mislead you here. rank_markets can only sort on market_score, revenue_ltm, occupancy_ltm or adr_ltm, none of which know what a house costs — so a revenue sort hands back the most expensive markets in the country. The cost side comes from the for-sale data instead.

So if get_for_sale_metrics isn't in your tool list, my plan doesn't include for-sale data and the cost half of this question cannot be answered. Say so and stop. Do not hand me the revenue ranking on its own — that ranking is the exact error this recipe exists to correct.

Work in this order:

- rank_markets for a long list of 15 to 25 candidates, sorted on revenue_ltm or market_score and filtered to my criteria. If I've already named the markets I'm weighing, use mine and skip this.
- Narrow to five to eight before going further. For-sale data is fetched one market at a time, so this is the step that keeps the run affordable — tell me which you dropped and why.
- For each survivor, call get_for_sale_metrics scoped to that market, grouped by bedrooms, over list_price, estimated_yield and estimated_revenue. The market filter takes a name or an id, so no separate resolve step is needed.
- Call get_market_metrics on the finalists for what the for-sale data doesn't carry: market grade, regulation, seasonality, listing count.

Hold bedroom count constant when you compare. A market that is mostly 2BR condos against one that is mostly 4BR cabins is a category difference, not a comparison. Pick one bedroom count present in every market with at least three listings, lead with that, and note separately where the picture changes at other sizes.

Give me these sections:

- The trade — a table, one row per market at the chosen bedroom count: median list price, median and mean estimated yield as separate numbers, estimated annual revenue, and the market's observed revenue_ltm for context.
- Where cheap wins — markets whose yield beats a higher-revenue market's, with the gap stated both ways: how much less revenue, how much less it costs.
- Where cheap doesn't win — markets that look affordable but don't convert it into yield, and whether price or revenue is the reason.
- Other sizes — where the ranking flips at a different bedroom count.
- Watch-outs — regulation, seasonality and thin cohorts among the leaders. A group under three listings returns a count with null metrics; report the count and call the market untested at that size rather than dropping it silently.
- Where I'd look — two markets, and the one thing that would disqualify each.

Then call get_for_sale_listings for my top market, sorted on estimated_yield descending, limit 10. Every row must carry its disclaimer, brokerage_name and brokerage_phone — a licensing requirement, not a formatting preference.

Use section headings, not numbered sections. State which currency you're reporting in.

About the yield figure: estimated_yield is projected annual short-term-rental revenue as a percent of asking price. It is gross — no taxes, insurance, HOA, management, maintenance or financing — so it is not a cap rate and not cash-on-cash. Use it to rank markets against each other, not as a return I would collect. Listings with no asking price or an incomplete projection are excluded from the cohort, so these figures describe priced, projectable inventory rather than everything for sale. Don't build your own yield by dividing a market's observed revenue by a for-sale price: the two come from different sources and won't agree.

For-Sale Buy Box any account for_sale For-sale inventory screened against what each property would earn as a short-term rental.

get_for_sale_metrics get_for_sale_listings

Screen for-sale properties in [MARKET OR SUBMARKET NAME] against what they would earn as short-term rentals.

This is MLS inventory with AirDNA's STR projections attached. The estimated_ fields are projections for a property that isn't operating yet, not observed performance — never present them as actuals.

If the for-sale tools aren't in your tool list, my plan doesn't include for-sale data. Tell me that and stop. Don't substitute observed short-term-rental performance or market averages: neither carries an asking price, so neither can answer this.

Start with get_for_sale_metrics for the area (a combined_market_id or combined_submarket_id filter is required — a market or submarket name works, an id is not needed), grouped by bedrooms, over list_price, estimated_yield, estimated_revenue and estimated_daily_rate. group_by takes exactly one field, so run it again with property_type if I ask for that cut. Any group with fewer than three listings comes back with a count and null metrics — report the count, say the group is too small, and don't interpolate.

Read that aggregate out loud before you pull a single listing, because the listings call returns only the top rows of a yield sort and I can't tell what's typical without it. Tell me, per bedroom count: how many listings are in the group, the mean and the p50 as two separate numbers, and the p25-to-p75 yield spread. Where mean and p50 diverge sharply, say which one you're using and why. If p25, p50 and p75 come back identical the group is effectively a single data point — say so rather than reporting a zero spread as consensus.

Then commit to the one or two bedroom counts worth shopping, and say what a normal yield looks like there. Anything in the listings below that sits above the p75 for its group is projecting earnings that are uncommon in the area — say so alongside it, so I read it as an upside case rather than the going rate.

Then call get_for_sale_listings over the same filters, sorted on estimated_yield descending, limit 10 (maximum 100).

Give me these sections:

- Where the value is — which bedroom counts carry the best yield.
- Candidates — a table: address, bedrooms, bathrooms, square footage, list price, estimated annual revenue, estimated occupancy and estimated yield.
- Attribution — every listing you show must carry its disclaimer, brokerage_name and brokerage_phone. This is a licensing requirement, not a formatting preference: if you shorten the table, keep these.
- What I'd look at — two or three listings, and what to verify about each.

Use section headings, not numbered sections. State which currency you're reporting in. There is no history for for-sale inventory, so don't describe a price trend or how long the market has been moving. Yield is a projection over an asking price; treat both as estimates.

Tools

27 tools live today. Click a tool for its parameters.

The tool set is growing fast — the market, submarket and STR listing research tools (research any market, not just your own properties) are next, with many more on the way. They are listed here but not callable yet: switch the status filter to coming soon to preview them, or the four research domains will look empty. What a tool returns then depends on your plan — a component you don't hold hides its tools from your assistant rather than erroring, and a wider one adds columns and history to the tools you already have.

Tool Domain Access Status What it does

get_listing_details Listings & Portfolio read-only live Everything about one of your listings — calendar, reservations, rules, market enrichment.

rms_read

Detailed view of one of the caller's listings. Always returns the listing summary (full view with enrichment). Use `include` to request additional sections: `calendar` (per-day availability/price/min-stay, default 90-day window, max 366), `reservations` (bookings, filterable by status/date), `rules` (pricing rules, filterable by category/enabled/date-window), `rate_push_history` (automated price push log). Each section has its own optional filter parameters. Omit `include` for just the listing summary.

Parameter	Type	Required	Description
`calendar_end_date`	object	no	Calendar window end, `YYYY-MM-DD`. Defaults to 90 days after start. Max window 366 days. Only used when `include` contains `calendar`.
`calendar_start_date`	object	no	Calendar window start, `YYYY-MM-DD`. Defaults to today (or 90 days before `calendar_end_date`). Only used when `include` contains `calendar`.
`check_in_after`	object	no	Only reservations checking in on or after this date, `YYYY-MM-DD`.
`check_in_before`	object	no	Only reservations checking in on or before this date, `YYYY-MM-DD`.
`include`	object	no	Sections to include in the response. Valid values: `calendar`, `reservations`, `rules`, `rate_push_history`. Omit for basic listing info only.
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`).
`rate_push_limit`	object	no	Max rate push history entries (default 20, max 200).
`rate_push_status`	object	no	Filter push history by status: `pending`, `pushed`, or `failed`.
`reservation_status`	object	no	Filter reservations by status (e.g. `confirmed`, `cancelled`). Only used when `include` contains `reservations`.
`rule_category`	object	no	Filter rules by category (e.g. `day_override`, `min_stay`). Only used when `include` contains `rules`.
`rule_enabled`	object	no	Filter rules by enabled state.
`rule_window_end`	object	no	See `rule_window_start`. `YYYY-MM-DD`.
`rule_window_start`	object	no	With `rule_window_end`, switches rules to "applicable" mode: only rules that affect days in this window. `YYYY-MM-DD`.

get_portfolio_performance Listings & Portfolio read-only live Revenue, occupancy and ADR across your portfolio, historical or pacing.

rms_read

Portfolio performance across the caller's listings. Views: past_metrics (historical revenue, ADR, occupancy KPIs), pacing_metrics (forward-looking pacing aggregate — one figure per KPI over the range), pacing_rates (pacing as a time series bucketed by granularity, for trends and charts), bookings (paged booking list). Pacing views accept as_of_date ('what was on the books as of' — defaults to today; call twice with different dates for today-vs-last-year). pacing_rates takes an optional granularity (daily/weekly/monthly/quarterly/yearly), auto-picked from the range when omitted. Optionally restrict to specific listing ids.

Parameter	Type	Required	Description
`as_of_date`	object	no	Pacing views only: the "as of" date (`YYYY-MM-DD`) — what was on the books as of this date. Defaults to today. Call twice with different values for today-vs-last-year comparisons.
`currency`	object	no	3-letter ISO currency code. Defaults to USD.
`end_date`	object	no	Range end, `YYYY-MM-DD`. Defaults: past/bookings → start of current month; pacing → 3 months from today.
`granularity`	object	no	`pacing_rates` view only: time bucket — `daily`, `weekly`, `monthly`, `quarterly`, or `yearly`. Omit to auto-pick a sensible bucket from the date range.
`listing_ids`	object	no	Restrict to specific listing ids (UUIDs). Omit for the whole portfolio.
`page`	object	no	Page number for the `bookings` view.
`start_date`	object	no	Range start, `YYYY-MM-DD`. Defaults: past/bookings → 12 months ago; pacing → today.
`view`	object	no	`past_metrics` (historical KPIs, default), `pacing_metrics` (forward-looking pacing aggregate), `pacing_rates` (pacing as a time series over the range, for trends/charts), or `bookings` (booking list with paging).

list_my_listings Listings & Portfolio read-only live The properties you've connected, with location, capacity and pricing status.

rms_read

List the caller's connected short-term rental listings. Default `basic` view returns id, name, location, capacity, and whether price sync is on — enough to pick a listing; `view=full` adds property/room type, strategy, integration, and market enrichment. Set include_summaries=true to add per-listing revenue and occupancy summaries. Paginated via limit/page. Returns listing ids (UUIDs) used by the other listing tools.

Parameter	Type	Required	Description
`currency`	object	no	3-letter ISO currency code for summaries. Defaults to USD.
`include_summaries`	object	no	Also fetch per-listing revenue and occupancy summaries (slower).
`limit`	object	no	Max listings per page (default 100, max 200).
`page`	object	no	Page number, starting at 1.
`status`	object	no	Comma-separated integration statuses to include: `active` (default), `inactive`, `unknown` — e.g. `"active,inactive"`.
`view`	object	no	`basic` (default): id, name, location, capacity, and price-sync flag — enough to pick a listing. `full`: adds property/room/listing type, strategy, integration, and market enrichment.

apply_strategy Pricing & Rules destructive live Install a previewed strategy as the listing's default. Requires a confirmation step.

rms_write

Apply a previously previewed strategy to a listing — installs the previewed rules and sets the listing's default strategy. Requires the single-use confirmation_token from preview_strategy; only call after the user explicitly approved the previewed rules. This replaces the listing's strategy-managed rules. The host's own base price, price limits, day overrides, length-of-stay discounts and event-scoped rules are kept.

Parameter	Type	Required	Description
`confirmation_token`	string	yes	The confirmation token returned by `preview_strategy`. Single-use, valid 10 minutes. Only call this after the user has reviewed the previewed rules and explicitly approved.
`listing_id`	string	yes	The listing id (UUID) the preview was generated for.

delete_listing_rules Pricing & Rules destructive live Remove pricing rules from a listing.

rms_write

Delete one or more pricing rules from one of the caller's listings. Unknown rule ids are reported back as not_found rather than failing the call. Deletion cannot be undone.

Parameter	Type	Required	Description
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`).
`rule_ids`	string[]	yes	Rule ids (UUIDs) to delete. Unknown ids are reported back as not_found rather than failing the call.

get_comp_set Pricing & Rules read-only live One comp set: its name, source and member properties.

airdna_comp_sets

Get one comp set by id: name, source (custom or recommended), its members (listed by title — member property ids are never returned), and which listings it's connected to.

Parameter	Type	Required	Description
`comp_set_id`	integer	yes	The comp set id (from `list_my_comp_sets`).

get_comp_set_metrics Pricing & Rules read-only live Aggregate ADR, occupancy and revenue across a comp set over a date range.

airdna_comp_sets

Aggregate performance metrics for a comp set's member properties over a date range: ADR, occupancy, RevPAR, gross/net revenue, length of stay, guest nights. Defaults to the last 12 complete months in USD. Composes the comp set's member list with AirDNA's listing performance data. Set per_member=true to also get the same metrics broken down per member (labeled by property title) — use for ranking/leaderboard questions. `members_with_data` is how many members had data in the window; hedge when it is well below member_count. UNITS: every monetary figure (net_adr, adjusted_revpar, net_revenue, base_revenue, base_adr) is in whole units of `currency` as a decimal — e.g. 231.5 means $231.50 — whereas get_portfolio_performance and get_listing_details report cents as integers; divide those by 100 before comparing.

Parameter	Type	Required	Description
`comp_set_id`	integer	yes	The comp set id (from `list_my_comp_sets`).
`currency`	object	no	3-letter ISO currency code. Defaults to USD.
`end_date`	object	no	Range end, `YYYY-MM-DD` (exclusive). Defaults to the start of the current month.
`per_member`	object	no	Also return the same metrics per member (labeled by property title), for ranking members against each other. Default false.
`start_date`	object	no	Range start, `YYYY-MM-DD`. Defaults to 12 months ago.

get_listing_comp_performance Pricing & Rules read-only live How the comp set you benchmark against is performing.

rms_read

Performance of a listing's ACTIVE comp set — the one comp set the user designated for benchmarking (custom or recommended). Read-only. Returns per-member ADR, occupancy, RevPAR, gross revenue, length of stay, and guest nights (members labeled by title) plus a set-level aggregate, over a date window (default: last 12 complete months). Use this to answer 'how am I doing vs my comps' — compare against the listing's own metrics from get_portfolio_performance. UNITS: every monetary figure here (net_adr, adjusted_revpar, net_revenue, base_revenue, base_adr) is in whole units of `currency` as a decimal — e.g. 231.5 means $231.50 — whereas get_portfolio_performance and get_listing_details report cents as integers; divide those by 100 before comparing. Errors explicitly when the listing has no active comp set; do not substitute recommended comps (get_listing_comps) for benchmarks.

Parameter	Type	Required	Description
`currency`	object	no	3-letter ISO currency code. Defaults to the listing currency, then USD.
`end_date`	object	no	Window end, `YYYY-MM-DD` (exclusive month boundary). Defaults to the start of the current month.
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`).
`start_date`	object	no	Window start, `YYYY-MM-DD`. Defaults to the start of the 12 complete months ending at the current month.

get_listing_comp_rates Pricing & Rules read-only live Day-by-day rate bands across your active comp set, next to your own prices.

rms_read

Per-day rate bands over a listing's ACTIVE comp set — for judging the listing's pricing position on the calendar. Read-only. For each day in the window (default today +180 days, max 365) returns the comps' booked-price band (comp_median_booked, comp_p25, comp_p75), the median asking price of still-available comp nights (comp_median_ask), and how many comps each side is based on (comp_booked_count / comp_available_count — hedge when these are low). Days where no comp has calendar data are omitted from the response. Join against the listing's own prices from get_listing_details (calendar) or preview_listing_rates, not get_predicted_rates, which is the model's output before the host's rules. UNITS: the comp bands here are in whole units of `currency` as decimals — e.g. 240.0 means $240.00 — whereas the calendar's price_cents and the price_cents column of preview_listing_rates' days rows are integer cents; divide those by 100 before comparing. Errors explicitly when the listing has no active comp set.

Parameter	Type	Required	Description
`currency`	object	no	3-letter ISO currency code. Defaults to the listing currency, then USD.
`end_date`	object	no	Window end, `YYYY-MM-DD`. Defaults to 180 days after start. Max window 365 days.
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`).
`start_date`	object	no	Window start, `YYYY-MM-DD`. Defaults to today (or 180 days before `end_date`).

get_listing_comps Pricing & Rules read-only live AI-recommended comparable properties near one of your listings.

rms_read

AI-recommended comparable properties (comps) for one of the caller's listings — similar nearby STRs rms-platform ranked by amenity/structural similarity, each with a similarity score and a plain-language reason. Read-only. Returns comp-sets grouped by comp_type; each comp carries title, structure (bedrooms/bathrooms/accommodates), distance_km, price_tier, rating, and shared amenities. An empty result means comps have not been generated for this listing yet, not that none exist.

Parameter	Type	Required	Description
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`).

get_predicted_rates Pricing & Rules read-only live Adapt's nightly price suggestions for a listing, before your rules. Does not take into account any custom rules you have set.

rms_read

Raw output of Adapt's pricing model for one of the caller's listings: the per-day base rate plus market factors (seasonality, demand, lead time, events), BEFORE any of the host's pricing rules (day-of-week, gap-night, min-stay, pricing limits, Model Impact, Base Price overrides, seasons and events, etc.). They are not necessarily what guests pay and not necessarily what gets pushed to the PMS, because they do not factor in the user's custom rules. Do not use them to answer what a stay costs, what the listing charges, or what a push would change. Use `preview_listing_rates` for that, since it applies the host's rules and shows exactly what would be pushed. Use this tool only to explain what the model recommends, or how much the host's rules move prices away from it. Read-only: nothing is pushed. Default 90-day window from today, max 366 days. A cold cache miss can take a few seconds.

Parameter	Type	Required	Description
`end_date`	object	no	Window end, `YYYY-MM-DD`. Defaults to 90 days after start. Max window 366 days.
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`).
`start_date`	object	no	Window start, `YYYY-MM-DD`. Defaults to today (or 90 days before `end_date`).

list_my_comp_sets Pricing & Rules read-only live All your comp sets — custom ones and system-recommended ones.

airdna_comp_sets

List the caller's comp sets (sets of comparable properties), including custom sets created by them or teammates and system-recommended sets on their listings. Returns a paginated summary per set (id, name, source, member count, connected listings); call get_comp_set for a set's members. Ids are usable with get_comp_set and get_comp_set_metrics.

Parameter	Type	Required	Description
`limit`	object	no	Max comp sets per page (default 50, max 200).
`page`	object	no	Page number, starting at 1.

preview_custom_strategy Pricing & Rules read-only live Preview a rule set you assembled yourself before applying it.

rms_read

Preview a rule set the user assembled themselves as a custom strategy, and get a single-use confirmation_token (valid 10 minutes) for apply_strategy. Use this instead of preview_strategy when the user wants their own combination of rules rather than one of the prepackaged strategies. `rules` is the listing's COMPLETE desired state, not a delta: read the current rules first (get_listing_details with include=rules), then echo every rule the listing should keep with its rule_id, add new ones without a rule_id, and name every rule to remove in delete_rule_ids. A current rule left out of both is rejected — this is how the call avoids deleting a rule the user never saw. The result reports will_create, will_update and will_delete: show all three to the user, then only call apply_strategy after they explicitly approve. Applying clears the listing's prepackaged-strategy label. Prices are in CENTS; base_price and pricing_limits directly set prices, so state those numbers back to the user.

Parameter	Type	Required	Description
`delete_rule_ids`	object	no	Rule ids (UUIDs) to remove. Every current rule not echoed in `rules` belongs here.
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`).
`rules`	array	yes	The listing's complete desired rule set.

preview_listing_rates Pricing & Rules read-only live Your nightly prices with your rules applied, before PMS fees and taxes: exactly what would be pushed. Nothing is sent.

rms_read

Preview the rates that WOULD be pushed to a listing's PMS: Adapt's predicted rates with all of the host's current pricing rules applied. These are the user-facing nightly prices, so this is also the tool for what the user's prices are or will be, or what a stay would cost — not get_predicted_rates, which is the model's output before rules. Prices exclude PMS-side fees, taxes and channel fees. Weekly/monthly length-of-stay discounts and check-in/out restrictions are applied by the PMS at booking, so they appear under `booking_rules` rather than in the day prices; apply them when totalling a stay. Pass `start_date`/`end_date` to list the prices for just those dates (omit both for the first 14 days), and request only the dates you need. Each `days` row is `[date, price_cents, min_nights]`. `window` echoes the requested dates; if `days` is empty, they fall outside `first_date`–`last_date`, so there is no price for them yet. The summary stats (`day_count`, `first_date`/`last_date`, min/max/avg) cover every day a push would send, not just the rows listed. To compare against current calendar prices, call get_listing_details with include=`calendar` and compare its `price_cents` by date. Nothing is sent anywhere. Also returns a single-use confirmation_token (valid 10 minutes) for push_listing_rates; only push after the user explicitly approves.

Parameter	Type	Required	Description
`end_date`	object	no	Window end, `YYYY-MM-DD`. Defaults to 90 days after start. Max window 366 days.
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`).
`start_date`	object	no	First date to list prices for, `YYYY-MM-DD`. Omit both dates for the first 14 days. Defaults to today (or 90 days before `end_date`).

preview_strategy Pricing & Rules read-only live Browse the preset pricing strategies, or preview what one would do to a listing.

rms_read

List available pricing strategies or preview a specific one. Omit strategy_id to list all strategies for the listing (id, display name, description, active status, rule count). Provide strategy_id to preview its concrete rules and get a single-use confirmation_token (valid 10 minutes) — present the rules to the user and only call apply_strategy after they explicitly approve. The host's own base price, price limits, day overrides, length-of-stay discounts and event-scoped rules are kept.

Parameter	Type	Required	Description
`listing_id`	string	yes	The listing id (UUID) to evaluate strategies against.
`strategy_id`	object	no	The strategy id (UUID) to preview. Omit to list all available strategies for the listing instead.

push_listing_rates Pricing & Rules destructive live Push previewed rates to your connected PMS. Requires a confirmation step.

rms_sync

Push previously previewed rates to the listing's connected PMS. Requires the single-use confirmation_token from preview_listing_rates — only call this after the user explicitly approved that preview. This changes live prices on the user's channels and is billed as metered usage. The push sends exactly the previewed rates. Returns a summary of the outcome: `sent_day_count` with the date and price range sent, to check against the approved preview, and `skipped` for any days not sent (past dates are dropped by design). These counts describe what was sent to the PMS, which can differ from what it accepted: `status` is `pushed` when days landed and `failed` when none did, and a `push_error` alongside `pushed` means the PMS rejected some days and says how many. Tell the user when a push was partial or failed instead of reporting a clean success.

Parameter	Type	Required	Description
`confirmation_token`	string	yes	The confirmation token returned by `preview_listing_rates`. Tokens are single-use and expire after 10 minutes. Only call this after the user has reviewed the preview and explicitly approved the push.
`listing_id`	string	yes	The listing id (UUID) the preview was generated for.

save_listing_rule Pricing & Rules mutating live Create or update a single pricing rule on one of your listings.

rms_write

Create a new pricing rule or update an existing one on the caller's listing. Provide rule_id to update (full replacement); omit to create. spec is {"type": "<category>", "config": {...}} — categories include day_override (needs calendar_date), min_stay, length_of_stay_discount, checkin_checkout_restriction (optionally scoped to a calendar event), gap_night, adjacent_night, last_minute, far_out, date_range_impact, day_of_week_price, and the HIGH-IMPACT price controls base_price and pricing_limits (these directly set the listing's prices — state the numbers back to the user before saving). The platform validates the config shape and reports per-item failures.

Parameter	Type	Required	Description
`calendar_date`	object	no	Required for `day_override` rules: the date the override applies to, `YYYY-MM-DD`.
`enabled`	object	no	Whether the rule starts enabled (default true).
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`).
`rule_id`	object	no	The rule id (UUID) to update. Omit to create a new rule.
`spec`	object	yes	The rule as a tagged spec: `{"type": "<category>", "config": {...}}`. All prices are in CENTS, and the price field is `amount_cents` — never `price_cents`. rms-platform validates the config but does NOT reject unknown fields: a misspelled or wrong-named field is silently dropped, leaving an empty config that fails validation ("must set at least one…"). So the field names below must match exactly. Weekday values are lowercase strings (`sun`,`mon`,`tue`,`wed`,`thu`,`fri`,`sat`). Percent fields are signed and (unless noted) bounded to [-99, 200]. `config` shape per category: - `day_override` (one day's price; `calendar_date` required): `{"price": {"kind": "fixed", "amount_cents": 70000}}`, `{"price": {"kind": "pct", "pct": 10.0}}`, a min-stay pin alone `{"min_stay": 3}`, or both together. `price` and `min_stay` are independent — set either or both, at least one required (`amount_cents` >= 1000, `pct` in [-99, 200], `min_stay` in [1, 365]). - `base_price` (HIGH IMPACT): `{"amount_cents": 25000}` (>= 100). - `pricing_limits` (floor/ceiling, HIGH IMPACT): `{"min_price_cents": 8000, "max_price_cents": 50000}` — each optional (>= 100, min <= max); optional per-weekday tables `day_of_week_min`/`day_of_week_max`, each `{"fri": 12000, "sat": 12000, ...}`. - `min_stay`: `{"default": 2}`, a per-weekday table `{"dow": {"fri": 3, "sat": 3}}`, and/or lead-time rules `{"lead_time_rules": [{"direction": "within"\|"after", "threshold_days": 7, "min_stay": {"kind": "single", "nights": 4}}]}` (`min_stay` may instead be `{"kind": "day_of_week", "fri": 4, ...}`). At least one of default/a dow cell/a rule; nights in [1, 365]. NOTE: there is no `min_nights` field. - `length_of_stay_discount`: `{"weekly_pct": 10.0, "monthly_pct": 18.0}` — at least one, each in [0, 99]. - `checkin_checkout_restriction`: `{"allowed_checkin_days": ["fri", "sat"], "allowed_checkout_days": ["sun"]}` — at least one, non-empty, no duplicates; optional `description`. Seasonal variants scope via `user_event_id`. - `day_of_week_price`: all seven required — `{"sun": 0, "mon": -5.0, "tue": 0, "wed": 0, "thu": 0, "fri": 15.0, "sat": 15.0}` (each pct in [-99, 200]). - `date_range_impact`: `{"pct": 20.0}` (required; usually seasonal, so pass `user_event_id`). - `gap_night`: `{"rules": [{"max_gap_nights": 2, "discount_pct": -10.0, "min_stay": 1, "enabled": true}]}` — `max_gap_nights` 1-30, `min_stay` >= 1 and <= `max_gap_nights`; optional `lead_days_threshold`, `dow_filter`. - `adjacent_night`: `{"rules": [{"window": 3, "adjustment_pct": 10.0, "direction": "before"\|"after"\|"both", "enabled": true}]}` — `window` 1-30; optional `dow_filter`. - `last_minute`: `{"mode": "step"\|"gradual", "step_zones": [{"days_min": 0, "days_max": 7, "price_pct": -10.0}], "gradual": {"start_days": 14, "peak_pct": -15.0}}` — `mode` required; `step_zones` used when step, `gradual` when gradual (`days_max` optional = unbounded). - `far_out`: `{"mode": "step"\|"gradual", "step_zones": [{"days_min": 180, "days_max": 365, "price_pct": 10.0}], "gradual": {"start_days": 180, "ramp_over_days": 180, "peak_pct": 15.0}}` — like `last_minute` but `gradual` also needs `ramp_over_days`. - `model_impact`: `{"level": "lower"\|"standard"\|"higher"}`.
`user_event_id`	object	no	Scopes the rule to one season or event (UUID, from `list_user_events`) instead of the whole calendar. Optional on `pricing_limits`, `checkin_checkout_restriction`, `day_of_week_price`, `min_stay`, `gap_night`, `adjacent_night`, `last_minute` and `far_out` — omit for the year-round version, pass an id for the seasonal one. REQUIRED on `date_range_impact`, which exists only to price a season. Rejected on `day_override` (use `calendar_date`), `base_price`, `length_of_stay_discount` and `model_impact`, which are always global.

save_listing_rules Pricing & Rules destructive live Apply several pricing-rule changes to a listing in one call.

rms_write

Apply several pricing-rule changes to one of the caller's listings in a single call: create many rules at once and, optionally, delete rules first to replace them. Use when the user asks for multiple changes together (e.g. several day overrides). delete_rule_ids are removed before the new rules are created, so a replacement (swap a day's override) is one call. Each rule is created independently — partial success is possible. The result is a structured record you must read and relay accurately: `created` (rules saved), `failed` (rejected, each with index/code/message), `deleted` (rule ids removed), `not_found` (delete ids that didn't exist), and `create_error` (present only if the create request failed to reach the service). Empty `created` with a non-empty `failed` or `create_error` means nothing new was saved — and if `deleted` is non-empty in that case, tell the user the old rule(s) were removed but the replacement was not saved. Prices are in CENTS. The HIGH-IMPACT categories base_price and pricing_limits directly set prices — state the numbers back to the user before saving. spec shape per category is documented on save_listing_rule.

Parameter	Type	Required	Description
`delete_rule_ids`	object	no	Rule ids (UUIDs) to delete before creating — use to replace an existing rule (e.g. swap a day's override): delete the old id, create the new one in the same call. Unknown ids come back as not_found.
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`).
`rules`	array	yes	New rules to create. May be empty if only deleting.

set_revenue_goal Pricing & Rules mutating live Set the annual revenue target a listing is tracked against.

rms_write

Set (or update) an annual revenue goal for one of the caller's listings, in whole cents. Used to track portfolio performance against targets.

Parameter	Type	Required	Description
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`).
`revenue_target_cents`	integer	yes	Annual revenue target in whole cents (e.g. 12000000 for $120,000).
`year`	integer	yes	Calendar year the goal applies to (e.g. 2026).

delete_user_events Seasons & Events destructive live Remove seasons or events. Their pricing is deleted with them.

rms_write

Delete seasons or one-off events from one of the caller's listings. THIS ALSO DELETES THEIR PRICING: every rule attached to a deleted window goes with it, and none of it can be recovered. Before calling, read the window's rules with get_listing_details (include=["rules"], matching on user_event_id) so the user knows what they are losing when they approve. The result then reports per id what was actually removed: `cascaded_rules` lists it, or `cascaded_rules_unknown` says the check failed and the user should be told the pricing is gone but not what it was. If they only want to pause a window, set enabled to false with save_user_event instead, which silences it and its pricing without destroying anything. Ids that are not on this listing come back under not_found rather than failing the call.

Parameter	Type	Required	Description
`event_ids`	string[]	yes	Ids (UUIDs) to delete, from `list_user_events`. Ids that don't exist are reported back as not_found rather than failing the call.
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`) the events belong to.

list_user_events Seasons & Events read-only live See the seasons and one-off events set up on your listings.

rms_read

List the seasons and one-off events on the caller's listings. A season is a long window (a summer, a shoulder season) that carries seasonal pricing; an event is a short dated occurrence (a festival, a race weekend). Both are the scope a seasonal pricing rule attaches to: take an id from here and pass it as `user_event_id` on save_listing_rule to price that window. Scope is not nested — pass listing_id for that listing's own seasons and events, omit it for everything on the account including every listing's. Empty means none are set up yet.

Parameter	Type	Required	Description
`category`	object	no	Only this category. Omit for both.
`end_before`	object	no	Only events ending on or before this date, `YYYY-MM-DD`.
`listing_id`	object	no	Restrict to one listing (UUID, from `list_my_listings`). The two scopes are not subsets of each other: with `listing_id` you get that listing's own seasons and events and NOT the account-wide ones; omit it and you get everything on the account, including every listing's.
`start_after`	object	no	Only events starting on or after this date, `YYYY-MM-DD`.

save_user_event Seasons & Events mutating live Create a season or event, or change one. Sets the window, not the prices.

rms_write

Create a season or one-off event on one of the caller's listings, or change an existing one. Provide event_id to change one (fields you leave out keep their current value); omit it to create, which needs listing_id, title, category, start_date and end_date. This writes only the window itself — it sets no prices. To price it, follow with save_listing_rule carrying the returned id as `user_event_id`: a date_range_impact rule for a percentage uplift, or min_stay / last_minute / far_out / gap_night / adjacent_night / day_of_week_price / pricing_limits / checkin_checkout_restriction for a seasonal version of that rule. A season's dates may not overlap another season on the same listing. Two things cannot be changed after creation, by design: which listing it belongs to, and whether it is a season or an event — delete and recreate instead.

Parameter	Type	Required	Description
`category`	object	no	`season`: a long window (a summer, a shoulder season) that carries seasonal pricing; seasons on one property may not overlap each other. `event`: a one-off dated occurrence (a festival, a race weekend); events may overlap each other and overlap seasons, and `priority` breaks the tie. Required when creating. Cannot be changed afterwards — delete and recreate to turn a season into an event or the reverse.
`enabled`	object	no	Whether it takes effect. Defaults to true. Setting it false is a reversible off switch for the window and everything priced against it, and is the gentler alternative to deleting.
`end_date`	object	no	Last day, inclusive, `YYYY-MM-DD`. Required when creating. Must be on or after `start_date`.
`event_id`	object	no	The id (UUID) of the season or event to change, from `list_user_events`. Omit to create a new one.
`listing_id`	object	no	The listing id (UUID, from `list_my_listings`). Required when creating. Cannot be sent when changing an existing one — a season cannot be moved between properties; delete it and create a new one instead.
`priority`	object	no	Tie-break between overlapping events on the same night; higher wins. Defaults to 0 and is irrelevant to seasons, which cannot overlap.
`recurring`	object	no	Whether the same month-and-day window applies every year. Defaults to false. A named season like "Summer" almost always wants `true` — left false it covers only the one year you dated it, which is rarely what "our summer season" means. A one-off event usually wants false.
`start_date`	object	no	First day, `YYYY-MM-DD`. Required when creating.
`title`	object	no	What the host calls it, e.g. "Summer" or "Harvest weekends". Required when creating.

compare_my_markets Market Context read-only live Benchmark the markets your own listings sit in against each other.

rms_read

Compare the AirDNA markets across two or more of the caller's listings. Each listing is resolved to its market via enrichment; listings in the same market are grouped. At least two distinct markets are required. Returns metric panels, winner per metric, and per-market deltas vs. the leader. Optionally restrict to a subset of canonical metric keys.

Parameter	Type	Required	Description
`listing_ids`	string[]	yes	Two or more listing ids (UUIDs) to compare. Listings in the same market are grouped together. At least two distinct markets are required for a comparison.
`metrics`	object	no	Subset of canonical metric keys to compare (e.g. `["adr_ltm", "occupancy_ltm"]`). Omit to compare all metrics.

get_listing_market_context Market Context read-only live The AirDNA market profile around one of your listings.

rms_read

Look up the AirDNA market profile for one of the caller's listings. Returns the market's metrics (ADR, occupancy, revenue, investability, etc.), qualitative overview, guest profiles, praised amenities, and complaint themes. The market is resolved from the listing's enrichment data — no coordinates or manual market ID needed.

Parameter	Type	Required	Description
`listing_id`	string	yes	The listing id (UUID, from `list_my_listings`).

compare_markets Market Research read-only coming soon Investment metrics for up to 10 markets, side by side.

basic_research

Compare 2 to 10 markets side-by-side across investment metrics. Pass combined_market_id values (use resolve_market first if you only have names). Returns each market's metric panel, the winner per metric, and per-market deltas vs. the leader. For `regulation`, lower is better. To screen a wider set, use rank_markets with filters first, then compare the finalists.

Parameter	Type	Required	Description
`market_ids`	string[]	yes	Two to ten `combined_market_id` values to compare side-by-side. To screen a wider set, use `rank_markets` with filters first, then compare the finalists.
`metrics`	object	no	Optional subset of metrics to compare. When omitted, the full canonical set is returned. Valid values: `adr_ltm`, `occupancy_ltm`, `revenue_ltm`, `market_score`, `investability`, `rental_demand`, `regulation`, `seasonality`, `revenue_growth`, `listing_count`.

find_similar_markets Market Research read-only coming soon Markets with a profile like one you already know you like.

basic_research

Find markets with a similar profile to an anchor market, given by name or combined_market_id. Similarity is z-score Euclidean distance across five core metrics (ADR LTM, occupancy LTM, revenue LTM, listing count, market score). Use filters to constrain the candidate pool. Anchor is excluded from results.

Parameter	Type	Required	Description
`filters`	object	no	Narrow the candidate pool the anchor is compared against.
`k`	object	no	Number of similar markets to return (default 10, max 50).
`market`	string	yes	Anchor market — a name ("Denver") or a `combined_market_id`.

get_booking_patterns Market Research read-only coming soon Booking lead time, length of stay and channel mix for a market.

basic_research

Get guest booking behavior for a market or submarket: average booking lead time, average length of stay, and channel mix (share of properties on Airbnb / Vrbo / Booking.com, including multi-channel overlap and price variability). Provide exactly one of combined_market_id or combined_submarket_id.

Parameter	Type	Required	Description
`combined_market_id`	object	no	Market to fetch booking patterns for. Provide exactly one of `combined_market_id` or `combined_submarket_id`.
`combined_submarket_id`	object	no	Submarket to fetch booking patterns for. Provide exactly one of `combined_market_id` or `combined_submarket_id`.

get_market_metrics Market Research read-only coming soon The full profile of one market — scores, metrics and narrative.

basic_research

Everything known about one market. Pass a market name or combined_market_id. Sections via `include`: `profile` (default) is the metric panel plus the qualitative write-up — narrative overview, grade, highlights, guest profiles, praised amenities, complaint themes; `summary` adds an aggregate performance rollup (ADR, occupancy, RevPAR, revenue potential, listing counts, professional share, length of stay, year-over-year changes) and requires start_date and end_date.

Parameter	Type	Required	Description
`currency`	object	no	3-letter ISO currency code for `summary`. Defaults to USD.
`end_date`	object	no	Summary window end, `YYYY-MM-DD` (exclusive). Required with `summary`.
`include`	object	no	Sections to return. `profile` (default) is the qualitative write-up and metric panel; `summary` adds an aggregate performance rollup over `start_date`..`end_date`, which are then required.
`market`	string	yes	Market name ("Denver") or `combined_market_id`.
`start_date`	object	no	Summary window start, `YYYY-MM-DD`. Required with `summary`.

locate_point Market Research read-only coming soon Find which market and submarket contain a lat/lng coordinate.

basic_research

Find which AirDNA market and submarket contain a lat/lng coordinate. Returns combined_market_id / combined_submarket_id values usable with all other market tools. This tool takes coordinates only, not street addresses.

Parameter	Type	Required	Description
`lat`	number	yes	Latitude in decimal degrees (-90 to 90).
`lng`	number	yes	Longitude in decimal degrees (-180 to 180).

rank_markets Market Research read-only coming soon Rank markets by any metric — screen for an investment thesis.

basic_research

Rank markets by a chosen metric, optionally narrowed by filters — this is also how you screen for an investment thesis (e.g. investability gte 70 plus regulation lte 30, sorted by market_score). Rankable metrics: market_score, revenue_ltm, occupancy_ltm, adr_ltm. The other canonical metrics (investability, regulation, revenue_growth, seasonality, rental_demand, listing_count) can be filtered on and are returned in every result's metric panel, but cannot be sorted on.

Parameter	Type	Required	Description
`filters`	object	no	Narrow the markets considered. Use this to express an investment thesis — e.g. high investability, low regulation, a minimum ADR.
`limit`	object	no	Maximum number of results to return (default 10, max 50).
`metric`	string	yes	Metric key to rank by. One of: `adr_ltm`, `occupancy_ltm`, `revenue_ltm`, `market_score`, `investability`, `rental_demand`, `regulation`, `seasonality`, `revenue_growth`, `listing_count`. For `regulation`, lower is better (sorted ascending); all others sort descending.

resolve_market Market Research read-only coming soon Turn a market name like “Nashville” into AirDNA market ids.

basic_research

Resolve a market name (e.g. 'Nashville', 'Austin TX') to one or more candidate combined_market_id values. Returns ranked candidates so the caller can disambiguate before calling other market tools. When the result has a single candidate it is treated as an exact match.

Parameter	Type	Required	Description
`country_code`	object	no	Optional ISO country code filter (e.g. "US", "MX"). Reduces ambiguity for names that exist in multiple countries (e.g. "Springfield").
`limit`	object	no	Maximum number of candidate matches to return (default 5, max 25).
`query`	string	yes	Free-text market or city name to look up (e.g. "Nashville", "Austin TX").

compare_submarkets Submarket Research read-only coming soon Metrics for up to 10 submarkets, side by side.

standard_research

Compare 2 to 10 submarkets side-by-side across the canonical metrics. Returns each submarket's metric panel, the winner per metric, and per-submarket deltas vs. the leader. For `regulation`, lower is better. Use rank_submarkets to shortlist first.

Parameter	Type	Required	Description
`metrics`	object	no	Optional subset of metrics to compare. When omitted, the full canonical set is returned.
`submarket_ids`	string[]	yes	Two to ten `combined_submarket_id` values to compare side-by-side. Use rank_submarkets to find candidates first.

get_submarket_metrics Submarket Research read-only coming soon The full profile of one submarket, down to guest praise and complaints.

basic_research

Everything known about one submarket: metric panel, demand drivers, narrative overview, grade, highlights, guest profiles, praised amenities and complaint themes. Pass a submarket name plus its parent `market`, or a combined_submarket_id on its own.

Parameter	Type	Required	Description
`market`	object	no	Parent market, to disambiguate a submarket name. Names repeat across markets, so this is usually needed unless you pass an id.
`submarket`	string	yes	Submarket name ("Downtown") or `combined_submarket_id`.

get_submarket_timeseries Submarket Research read-only coming soon A submarket's metrics over time, ready for charting.

standard_research

Historical timeseries for one submarket — same metric vocabulary and row budget as get_market_timeseries. Pass a submarket name plus its parent `market`, or a combined_submarket_id on its own.

Parameter	Type	Required	Description
`currency`	object	no	3-letter ISO currency code. Defaults to USD.
`granularity`	object	no	`monthly` (default); `revpar` also supports `daily`; `revenue` and `revpar` also support `yearly`.
`market`	object	no	Parent market, to disambiguate a submarket name.
`metric`	string	yes	Metric series to fetch — same vocabulary as get_market_timeseries.
`period_months`	object	no	How many months of history (12-120, default 24). The ceiling depends on the plan — a longer ask is clamped and `period_capped_by` names the capability that would widen it.
`submarket`	string	yes	Submarket name ("Downtown") or `combined_submarket_id`.

rank_submarkets Submarket Research read-only coming soon Rank neighbourhoods and areas by a metric, within one market or across all.

standard_research

Rank submarkets (neighbourhoods and areas) by a metric, optionally within one market and narrowed by filters. Pass `market` as a name or combined_market_id to get that market's submarkets. Rankable metrics: market_score (default), revenue_ltm, occupancy_ltm, adr_ltm — the other canonical metrics can be filtered on and appear in each metric panel. Returns at most 50 (default 25), with `has_more` when the filters matched more; narrow with filters rather than paging.

Parameter	Type	Required	Description
`filters`	object	no	Narrow the submarkets considered.
`limit`	object	no	How many submarkets to return (default 25, max 50). The response sets `has_more` when the filters matched more than this; narrow with filters rather than paging.
`market`	object	no	Restrict to the submarkets of one market — a name ("Denver") or a `combined_market_id`. Omit to rank across all markets.
`metric`	object	no	Metric to rank by: `market_score` (default), `revenue_ltm`, `occupancy_ltm`, or `adr_ltm`. Other canonical metrics can be filtered on and appear in each result's metric panel, but cannot be sorted on.

compare_str_listings STR Listing Research read-only coming soon Compare cohorts of listings — say 2-bedroom vs 3-bedroom in one market.

standard_research

Compare 2 to 5 groups of short-term rental listings side-by-side over the same window — e.g. 2-bedroom vs 3-bedroom in one market, or with a pool vs without. Each cohort is a label plus its own filters, and every cohort must scope to a market or submarket. Returns each cohort's aggregate metrics and listing count. This compares SETS of listings, not individual properties.

Parameter	Type	Required	Description
`cohorts`	array	yes	Two to five groups to compare side-by-side.
`currency`	object	no	3-letter ISO currency code. Defaults to USD.
`end_date`	string	yes	Window end, `YYYY-MM-DD`.
`start_date`	string	yes	Window start, `YYYY-MM-DD` (must be in the past).

get_listing_detail STR Listing Research read-only coming soon The full record for any observed STR listing, by id.

basic_research

One short-term rental listing's record by id — attributes, ADR and reviews at every plan level; revenue, occupancy and days available on a paid plan; revenue potential and the guest AI summary on a full research plan. Get an id from `get_str_listing_table`.

Parameter	Type	Required	Description
`property_id`	string	yes	The listing's `static_combined_property_id`, as returned by `get_str_listing_table`.

get_listing_history STR Listing Research read-only coming soon Monthly revenue, occupancy and ADR history for one observed listing.

advanced_research

Monthly revenue, occupancy and ADR history for ONE listing, by id — the series the Explorer listing panel charts. Monthly only. Get an id from `get_str_listing_table`. For a filtered SET of listings use `get_str_listing_timeseries` instead.

Parameter	Type	Required	Description
`currency`	object	no	3-letter ISO currency code. Defaults to USD.
`period`	object	no	Months of history, 12-60. Defaults to 24.
`property_id`	string	yes	The listing's `static_combined_property_id`, as returned by `get_str_listing_table`.

get_str_listing_metrics STR Listing Research read-only coming soon Aggregate performance for any filtered cohort of STR listings.

standard_research

Aggregate performance for a filtered set of short-term rental listings — ADR, occupancy, RevPAR and revenue at every plan level, plus length of stay and night counts on a paid research plan, and how many listings matched. Answers questions like 'what does a 3-bedroom with a pool in Nashville earn?'. Filters must scope to a market or submarket. Covers any observed STR, not the caller's own listings — for those use the listing tools.

Parameter	Type	Required	Description
`currency`	object	no	3-letter ISO currency code. Defaults to USD.
`end_date`	string	yes	Window end, `YYYY-MM-DD`.
`filters`	array	yes	Which listings to aggregate over. Must include `combined_market_id` or `combined_submarket_id` to scope the set; add attribute filters (bedrooms, amenities, price_tier…) to narrow it.
`start_date`	string	yes	Window start, `YYYY-MM-DD` (must be in the past).

get_str_listing_table STR Listing Research read-only coming soon Rank individual listings in a market, one row per listing.

advanced_research

Rank individual short-term rental listings in a market — one row per listing with its id, title, attributes, ADR and rating, ordered by a metric. Answers 'what is the best 2-bedroom in Miami?'. Filters must scope to a market or submarket. Pass a returned id to `get_listing_detail` for one listing's full record.

Parameter	Type	Required	Description
`descending`	object	no	`true` (default) for highest first.
`filters`	array	yes	Which listings to return. Must include `combined_market_id` or `combined_submarket_id` to scope the set; add attribute filters (bedrooms, amenities, price_tier…) to narrow it.
`limit`	object	no	Rows to return, 1-100. Defaults to 25.
`sort_by`	object	no	Column to order by, e.g. `revenue_ltm`, `occupancy_rate_ltm`, `average_daily_rate_ltm`, `rating_overall`. Defaults to `revenue_ltm`.

get_str_listing_timeseries STR Listing Research read-only coming soon A listing cohort's rates and occupancy over time, ready for charting.

advanced_research

Historical timeseries for a filtered set of short-term rental listings — rates and occupancy over time, for charting. Granularity: monthly (default), weekly, or daily. Filters must scope to a market or submarket. At most 200 of the most recent points are returned; `truncated` says when the window held more.

Parameter	Type	Required	Description
`currency`	object	no	3-letter ISO currency code. Defaults to USD.
`end_date`	string	yes	Window end, `YYYY-MM-DD`.
`filters`	array	yes	Which listings to aggregate over. Must scope to a market or submarket.
`granularity`	object	no	`monthly` (default), `weekly`, or `daily`.
`start_date`	string	yes	Window start, `YYYY-MM-DD` (must be in the past).

get_for_sale_listings For-Sale Research read-only live Homes for sale in a market, each with AirDNA's STR revenue projection.

for_sale

List individual homes for sale in a market — one row per MLS listing with its address, asking price, attributes and AirDNA's projected short-term-rental revenue, occupancy, ADR and yield. Answers 'which properties for sale here would work as a rental?'. Filters must scope to a market or submarket, given as a name ("Albuquerque") or an id — you do not need to resolve it first. When you pass a name, `area` in the response says which market or submarket it resolved to; check it before reporting, since a name can resolve into a different market than you expected. Every row carries the MLS disclaimer and brokerage attribution, which must be shown with the listing. The estimated_* values are projections for a property that is not yet a rental, not observed performance — use `get_str_listing_table` for actual rental results.

Parameter	Type	Required	Description
`descending`	object	no	`true` (default) for highest first.
`filters`	array	yes	Which listings to return. Must include `combined_market_id` or `combined_submarket_id` to scope the set; add attribute filters (`list_price`, `bedrooms`, `square_footage`, `estimated_yield`…) to narrow it.
`limit`	object	no	Rows to return, 1-100. Defaults to 10.
`sort_by`	object	no	Column to order by: `list_price`, `estimated_yield`, `estimated_revenue`, `estimated_occupancy`, `estimated_daily_rate`, `listing_date`, `bedrooms` or `square_footage`. Defaults to `list_price`.

get_for_sale_metrics For-Sale Research read-only live Price and projection statistics across a market's for-sale inventory.

for_sale

Summarize the homes for sale in a market — per metric a count, mean, min, max and the requested percentiles, plus the cohort size. Answers 'what does it cost to buy here, and what would it yield?'. Scope it with a market or submarket name or id. When you pass a name, `area` in the response names what it resolved to — an aggregate has no rows to reveal the location, so state the resolved area alongside the numbers. Computed over the whole matching cohort in the database, so it is not limited to a page of rows; use `get_for_sale_listings` for the individual properties. Optionally split by bedrooms, property type or market type. Report mean and p50 as distinct numbers — asking prices are right-skewed, so they differ. Groups below the minimum cohort size report a count with null metrics rather than a median over a handful of listings.

Parameter	Type	Required	Description
`filters`	array	yes	Which listings form the cohort. Must include `combined_market_id` or `combined_submarket_id`.
`group_by`	object	no	Split the cohort by one attribute: `bedrooms`, `property_type` or `market_type`. Omit for a single summary over the whole cohort.
`metrics`	object	no	Metrics to summarize: `list_price`, `estimated_yield`, `estimated_revenue`, `estimated_occupancy`, `estimated_daily_rate`, `square_footage`. Defaults to all of them.
`percentiles`	object	no	Whole percentiles to report, e.g. `[25, 50, 75]` (the default). `50` is the median.

get_market_pacing Market Trends read-only coming soon Forward-looking rates and occupancy for the months ahead.

standard_research

Forward-looking (pacing) data for a market or submarket. Views: rates (per-day booked vs available rates, future occupancy/revpar), performance_metrics (min/mean/p10/p90 distributions for ADR, RevPAR, occupancy, revenue), lead_times (upcoming reservations bucketed by booking lead time). Default: 3 months ahead. The rates view is always per-day, so at most 200 days are returned, counting forward from today, and `truncated` says when the window was longer than that.

Parameter	Type	Required	Description
`combined_market_id`	object	no	Market to query. Provide exactly one of `combined_market_id` or `combined_submarket_id`.
`combined_submarket_id`	object	no	Submarket to query. Provide exactly one of `combined_market_id` or `combined_submarket_id`.
`currency`	object	no	3-letter ISO currency code. Defaults to USD. Ignored by `lead_times`.
`granularity`	object	no	`performance_metrics` and `lead_times` accept `monthly` (default) or `daily`; `rates` is always daily.
`period_months`	object	no	How many months ahead (1-12, default 3).
`view`	string	yes	Forward-looking view: `rates` (daily booked vs available rates, occupancy, revpar), `performance_metrics` (distribution stats for ADR/RevPAR/occupancy/revenue), or `lead_times` (reservation counts by booking lead-time bucket).

get_market_timeseries Market Trends read-only coming soon A market's metrics over time, ready for charting.

standard_research

Historical timeseries for a market — ideal for charting trends. Pass a market name or combined_market_id. Metrics: revenue, occupancy, revpar (supports daily/yearly too), adr_by_bedroom, length_of_stay, active_listing_count, reservations_by_lead_time, channel_distribution (current snapshot). Default: 24 months, monthly, USD. period_months is always in MONTHS even at daily granularity, so daily+24 months is ~730 points; at most 200 of the most recent points are returned and `truncated` says when that happened. Prefer monthly granularity unless you need day-level detail. For a submarket use get_submarket_timeseries.

Parameter	Type	Required	Description
`currency`	object	no	3-letter ISO currency code. Defaults to USD.
`granularity`	object	no	`monthly` (default) for all metrics; `revpar` also supports `daily`; `revenue` and `revpar` also support `yearly`.
`market`	string	yes	Market name ("Denver") or `combined_market_id`.
`metric`	string	yes	Metric series to fetch. One of: `revenue`, `occupancy`, `revpar`, `adr_by_bedroom`, `length_of_stay`, `active_listing_count`, `reservations_by_lead_time`, `channel_distribution` (snapshot — ignores granularity/period).
`period_months`	object	no	How many months of history (12-120, default 24). The ceiling depends on the plan — a longer ask is clamped and `period_capped_by` names the capability that would widen it.

submit_feedback Feedback mutating live Send the AirDNA team a bug, a data problem or a feature request.

support

Send the AirDNA team a bug report, a data-quality problem, or a feature request. Put the user's own words in `message` — do not paraphrase, and do not infer what they expected. Add `related_tool` when it concerns a specific tool and, if you received one, the verbatim `tool_error`. Only call this when the user actually wants to report something.

Parameter	Type	Required	Description
`kind`	string	yes	A bug, a feature request, a data-quality problem, or something else.
`message`	string	yes	The user's feedback in their own words. Submit what they said, not a paraphrase.
`related_tool`	object	no	The tool this feedback is about, if any.
`tool_error`	object	no	The error text or unexpected result the tool returned, quoted verbatim. Omit unless you actually received one.

Canonical Metric Keys

Used by compare_markets, rank_markets, rank_submarkets, compare_my_markets and related tools.

Key	Direction	Description
`adr_ltm`	Higher is better	Average daily rate (last 12 months)
`occupancy_ltm`	Higher is better	Occupancy rate (last 12 months)
`revenue_ltm`	Higher is better	Total revenue (last 12 months)
`market_score`	Higher is better	Overall market score
`investability`	Higher is better	Investment attractiveness
`rental_demand`	Higher is better	Demand for short-term rentals
`regulation`	Lower is better	Regulatory restrictiveness
`seasonality`	Higher is better	Seasonality score
`revenue_growth`	Higher is better	Revenue growth rate
`listing_count`	Higher is better	Number of active listings