Your Favorite Software Has Gaps. MCP Fills Them.
How I used Claude and a Model Context Protocol to solve a problem my property management software couldn't — and why this pattern matters for every SaaS tool you use.
Prefer to watch? I walked through this in a 2 minute Loom video — it’s a summarized version. The companion slides go deeper than the video. The full story is below.
My wife and I run a small Airbnb in my backyard in Ruston, Louisiana. It’s a guest favorite and my wife has been a superhost since 2021.
The reason I’m writing this: I recently closed a gap in our property management software in about 20 minutes, without writing a line of code, using an MCP server. What I got back wasn’t really the feature — it was peace of mind. I’m no longer the middleware of worry between two systems, tracking what might fall through the cracks. That trade alone is worth the whole article.
We use Hospitable as our property management system. It’s genuinely excellent software. Automated messaging, calendar sync across different STR platforms, task management, direct booking — it handles the heavy lifting of running a short-term rental without requiring us to babysit it constantly.
But it has a gap, like any software.
The Gap
During the summer, we don’t want same-day turnovers. When a guest checks out at 10 AM, we need that day for cleaning and prep before the next guest checks in at 3 PM. We can normally swing that, but we are traveling this summer for 6 weeks, and need at least a day for turnover. My mother in love will be our POC for clients and I want her to have this extra margin.
Hospitable has a turnover time setting — but it’s all or nothing. You either enforce a buffer between every reservation year-round, or you don’t. There’s no way to say “block same-day turnovers only between July 7 and August 14.”
This is a reasonable product decision. Most hosts either want a buffer or they don’t. Building date-range-specific turnover policies adds complexity for a niche use case. I get it.
But I still needed the feature.
The Old Way
Before MCP, my options were:
Manual calendar management. Every time a new booking came in during the summer window, I’d check the checkout date and manually block that day from check-in. This works until you forget — and you will forget, because it depends on a human remembering to do a thing every time a booking arrives.
Set the buffer year-round. This costs occupancy during months when same-day turnovers are fine. For a property that generates roughly $10K/year before fees, every lost night matters.
Live with it. Accept the occasional stressful same-day turnover and hope it doesn’t tank a review, stress out my mother in love, etc.
None of these are great. The first doesn’t scale, the second costs money, and the third is a gamble.
The MCP Way
Model Context Protocol is an open standard that lets AI agents interact with software through structured tool calls. Think of it as giving Claude (or any AI) the ability to press buttons in your software — not by clicking around a screen, but by talking directly to the application’s API through a standardized interface.
Hospitable has an MCP server. So does my calendar, my email, my iMessage, and dozens of other tools.
Setting one up isn’t a developer project. Adding Hospitable to Claude took me about a minute: click connect, an OAuth window pops up in the browser, I authorize, and Claude can see my reservations. No API key to generate, no credentials to copy-paste, no integration code to write. If you’ve ever signed into a website with “Continue with Google,” you already know how this feels.
Here’s what I built in about 20 minutes with Claude:
Fetch reservations from Hospitable with checkout dates in my summer window (July 7 – August 14)
Filter to only newly booked reservations (so it doesn’t reprocess ones already handled)
Check the calendar to see if the checkout date is already blocked for check-in
Block check-in on checkout dates that aren’t already blocked
Handle cancellations — if a reservation gets cancelled, check whether the block is still needed (another reservation might share that checkout date), and unblock if it’s safe
Notify Ashley via iMessage if any changes were made
The whole thing runs as a scheduled task, once a day at 8 AM. No human in the loop. No forgetting. No spreadsheet to maintain.
The first time I ran it, Claude pulled my reservations through the Hospitable MCP server, identified four in the window, blocked check-in on each checkout date, and confirmed the calendar updates. It took about 30 seconds.
This Isn’t About Airbnb
The pattern here is bigger than short-term rentals. Every piece of software you use has gaps — features that almost do what you need, but not quite. Settings that are too coarse. Workflows that require manual steps between two systems.
Consider these analogies:
CRM that can’t do conditional follow-ups. Your CRM sends automated sequences, but you want to pause a sequence if the prospect opened a specific email and didn’t click — and then route to a different cadence. The CRM has sequences and it has analytics, but the two don’t talk to each other the way you need.
Project management with rigid automation. Your PM tool can auto-assign tasks based on status changes, but you need it to also check the assignee’s calendar and redistribute if they’re on PTO. The PM tool and the calendar tool both have APIs, but nobody’s connected them for your specific workflow.
Accounting software with inflexible categorization. Your bookkeeping tool auto-categorizes transactions, but your business has edge cases — a single vendor that supplies both office supplies and equipment, and you need the categorization to depend on the invoice amount. The rules engine can’t express that condition.
In every case, the software is good. The gap is small. But the gap is exactly where manual work, errors, and inconsistency creep in.
MCP turns those gaps into solvable problems. Instead of waiting for the vendor to build the feature, or hiring a developer to write a custom integration, you describe the logic to an AI agent that already speaks the language of both systems.
Why This Matters Now
Three things are converging:
MCP adoption is accelerating. More software vendors are shipping MCP servers because they recognize that AI interoperability is becoming table stakes. Hospitable, Slack, Google Calendar, Gmail, HubSpot, Jira — the list grows weekly.
AI agents are getting reliable enough. A year ago, I wouldn’t have trusted an automated agent to modify my Airbnb calendar unsupervised. Today, with structured tool calls, idempotent operations, and clear guardrails, the reliability is there. My skill checks the calendar before making changes, cross-references accepted and cancelled reservations, and only messages Ashley when something actually changed.
The economics favor automation. The Cozy Cottage is a $10K/year side business. I can’t justify hiring a developer to build a custom Hospitable integration. But I can spend 20 minutes describing the logic to Claude and have a working, scheduled solution that runs indefinitely.
Always UAT — Even When the Agent Says It’s Done
I was feeling pretty good about all of this — until my wife Ashley looked at the calendar and said: “That’s awesome. But what about the front end? You blocked check-in on checkout days, but you didn’t block checkout on days where we have an existing check-in.”
She was right. I’d only handled one direction. If a guest was checking in on a Saturday, nothing prevented a different guest’s reservation from ending that same Saturday morning. Same-day turnover, just from the other side.
The fix was straightforward. I opened a new Cowork session, edited the skill to block in both directions (check-in on checkout dates and checkout on check-in dates), and tested until the calendar showed restrictions on both ends of every reservation.
Here’s the part that made me smile: the scheduled task didn’t need to change at all. The prompt I’d written was simply “read the skill file and follow it.” The skill file is the source of truth. Update the file, and every future run picks up the new logic automatically. No redeployment. No reconfiguration. Just edit the instructions and the agent adapts.
The incremental operating cost of all of this? Zero. My Hospitable plan already includes MCP access. Claude Cowork starts at $20/month. The automation itself costs nothing to run.
A Note on Trust
Reasonable question if you’re new to this: should I be worried about an AI agent operating my software?
A few guardrails I follow that should give you some comfort.
Stick to first-party MCP servers. I use the MCP server published by Hospitable — the company that builds my property management software — and MCP integrations published by Anthropic, the company that builds Claude. I don’t install random third-party MCP servers from the internet. The trust model is simple: the people who build the software, or the people who build the AI, are the right people to write the bridge between them. Anyone else is asking for trust they haven’t earned.
Claude asks before it acts. The first time Claude tries to use an MCP tool, it pauses and asks me. I get three choices: deny it, approve just this once, or approve for future runs. Nothing happens silently. I read what it’s about to do and decide.
Drafts, not sends. For anything sensitive — outbound messages, calendar invites, anything client-facing — I tell Claude to draft, not send. It does 95% of the work: writes the message, attaches the right context, formats it correctly. I review the last 5% and hit send myself. That’s the right division of labor, especially early on while you’re building trust with the agent.
Pro tip for scheduled tasks. If you’re scheduling something to run unattended (like my 8 AM daily run), trigger it manually once right after you create it. Claude will prompt you to approve the tool calls, and once you approve “for future runs,” the scheduled run won’t get stuck waiting for permission later. Save yourself the head-scratching when you find out the next morning that nothing fired.
The Mindset Shift
The real unlock isn’t technical — it’s a shift in how you think about software limitations.
The old mindset: “This software doesn’t support what I need. I’ll submit a feature request, find a workaround, or switch products.”
The new mindset: “This software doesn’t support what I need. I’ll describe the gap to an AI agent that can operate the software on my behalf.”
The gap between what software does and what you need it to do is where MCP lives. It’s not replacing your tools — it’s making them work the way you actually need them to.
What to Try First
If you want to feel this for yourself, don’t start with a big project. Pick one tool you use every day, check if it has an MCP server, and ask Claude to do the next thing on your to-do list inside that tool. Watch it work. Then ask, “what’s the next gap?”
Many of the SaaS products you already pay for have MCP servers ready to go. A non-exhaustive list of popular ones: Notion, Slack, GitHub, Stripe, Sentry, HubSpot, PayPal, Asana, Linear, Atlassian — plus, for the finance-and-ops crowd, QuickBooks, Sage, and NetSuite. (Anthropic maintains a directory, though it isn’t exhaustive — Hospitable, for example, isn’t on Anthropic’s list yet but has its own MCP server, which is exactly why I’m writing this. Check your vendor’s docs.)
Want help applying AI and MCP to your business workflows? McCandless Consulting offers AI enablement training and strategy for teams that want to close their own software gaps.
P.S. — If you’re a host (or thinking about becoming one). My wife and I have coached four other hosts into becoming superhosts themselves. We do it for free — Airbnb gives us a referral incentive, and all four of our referees have become superhosts and/or hosts of guest favorites. If you want to chat about hosting, two pieces I’ve written:
People ask me about running an Airbnb… — what I tell folks who ask whether they should try it
How Airbnb hosts can analyze their listings with Tableau — for the data-curious hosts
Below is a public version of the skill used.
---
name: cozy-cottage-turnover-buffer
description: |
Block same-day check-ins on cottage checkout dates AND block same-day checkouts on
check-in dates to enforce a one-day turnover buffer in both directions.
Runs against Hospitable MCP to find newly booked reservations (booked 5/9/2026 or later) with
dates in the summer 2026 window (July 7 – August 14), then closes those checkout dates for
check-in AND check-in dates for checkout so no back-to-back same-day turnovers can occur.
Also handles cancellations by re-opening dates when no other accepted reservation needs the
block. Use this skill whenever the scheduled task fires, or when the owner asks to enforce
turnover buffers, block same-day turnovers, or apply checkout-day check-in restrictions for
the cottage.
MANDATORY TRIGGERS: turnover buffer, block check-in, same-day turnover, checkout buffer,
cottage turnover
---
# Cottage Turnover Buffer
Enforce a one-day buffer between guests at the cottage by blocking in **both directions**:
1. **Block check-in on checkout dates** — no new guest can check in the same day another checks out
2. **Block checkout on check-in dates** — no departing guest can check out the same day a new guest checks in
This prevents back-to-back same-day turnovers during peak summer season, giving time for
cleaning and turnover without relying on Hospitable's all-or-nothing turnover policy.
Also monitors for cancelled reservations and re-opens dates when the block is no longer needed.
## Property
- **Name:** <COTTAGE_NAME>
- **UUID:** `<HOSPITABLE_PROPERTY_UUID>`
- **Platform:** Airbnb
## Policy Window
- **Checkout date range:** 2026-07-07 through 2026-08-14
- **Booking date filter:** Only process reservations with `booking_date` on or after 2026-05-09
---
## Part A — Block check-in on checkout dates AND checkout on check-in dates
### Step 1 — Fetch accepted reservations (checkout query)
Call the Hospitable `get-reservations` tool to find reservations checking out in the window:
```
Tool: get-reservations
Parameters:
properties: ["<HOSPITABLE_PROPERTY_UUID>"]
start_date: "2026-07-07"
end_date: "2026-08-14"
date_query: "checkout"
status: ["accepted"]
per_page: 100
```
### Step 1b — Fetch accepted reservations (checkin query)
Also fetch reservations checking in during the window:
```
Tool: get-reservations
Parameters:
properties: ["<HOSPITABLE_PROPERTY_UUID>"]
start_date: "2026-07-07"
end_date: "2026-08-14"
date_query: "checkin"
status: ["accepted"]
per_page: 100
```
Deduplicate results from Step 1 and Step 1b by reservation ID to build a single list of
accepted reservations.
### Step 2 — Filter to qualifying bookings
From the deduplicated results, keep only reservations where `booking_date >= 2026-05-09T00:00:00Z`.
### Step 3 — Identify dates to block
For each qualifying reservation, extract:
- **`departure_date`** (checkout date) → this date needs `closed_for_checkin: true`
- **`arrival_date`** (check-in date) → this date needs `closed_for_checkout: true`
Only include dates that fall within the policy window (2026-07-07 through 2026-08-14).
### Step 3b — Check calendar before updating
Before blocking, call `get-property-calendar` to check the current state of each date.
This makes the skill idempotent — safe to run repeatedly without side effects.
```
Tool: get-property-calendar
Parameters:
uuid: "<HOSPITABLE_PROPERTY_UUID>"
start_date: <earliest_date>
end_date: <latest_date>
```
For checkout dates: if the day already has `closed_for_checkin: true`, skip it.
For check-in dates: if the day already has `closed_for_checkout: true`, skip it.
### Step 4 — Apply calendar blocks
For dates that need blocking, call `update-property-calendar`. You can batch all dates into
a single call (up to 1095 dates).
**CRITICAL API REQUIREMENT:** The Hospitable `update-property-calendar` API requires **both**
`closed_for_checkin` and `closed_for_checkout` in every date object. Sending only one field
will return an error. Always read the current calendar state from Step 3b and carry forward
the existing value for whichever field you are NOT changing.
For **checkout dates** (block check-in) — preserve existing `closed_for_checkout`:
```
dates:
- date: <checkout_date>
closed_for_checkin: true
closed_for_checkout: <current value from calendar>
```
For **check-in dates** (block checkout) — preserve existing `closed_for_checkin`:
```
dates:
- date: <checkin_date>
closed_for_checkin: <current value from calendar>
closed_for_checkout: true
```
If a single date needs both restrictions (e.g., one reservation checks out and another checks
in on the same day), set both to `true`:
```
dates:
- date: <date>
closed_for_checkin: true
closed_for_checkout: true
```
Do NOT overwrite a restriction that should remain. Always merge restrictions by reading the
current calendar state first.
You can batch all dates into a single `update-property-calendar` call.
---
## Part B — Unblock dates for cancelled reservations
### Step 5 — Fetch cancelled reservations
Call the Hospitable `get-reservations` tool for cancelled reservations in the same window,
using both checkout and checkin queries (same as Step 1 / 1b):
```
Tool: get-reservations
Parameters:
properties: ["<HOSPITABLE_PROPERTY_UUID>"]
start_date: "2026-07-07"
end_date: "2026-08-14"
date_query: "checkout"
status: ["cancelled"]
per_page: 100
```
```
Tool: get-reservations
Parameters:
properties: ["<HOSPITABLE_PROPERTY_UUID>"]
start_date: "2026-07-07"
end_date: "2026-08-14"
date_query: "checkin"
status: ["cancelled"]
per_page: 100
```
Deduplicate by reservation ID.
### Step 6 — Filter and identify candidate dates to unblock
From the cancelled results, keep only reservations where `booking_date >= 2026-05-09T00:00:00Z`.
For each cancelled reservation, collect two candidate dates:
- **`departure_date`** → candidate to unblock `closed_for_checkin`
- **`arrival_date`** → candidate to unblock `closed_for_checkout`
Only include dates within the policy window (2026-07-07 through 2026-08-14).
### Step 7 — Cross-check against accepted reservations
Before unblocking, verify that no other **accepted** reservation (from Steps 1/1b) still
needs the block. This is critical — if two reservations shared a date and only one was
cancelled, the block must remain for the other.
For each candidate **checkout date** to unblock check-in:
- If any accepted reservation has the same `departure_date`, do NOT unblock — skip it
For each candidate **check-in date** to unblock checkout:
- If any accepted reservation has the same `arrival_date`, do NOT unblock — skip it
### Step 8 — Unblock safe dates
For each date that is safe to unblock, first check the calendar to confirm it is currently
blocked. If it's already open, skip it.
Then call `update-property-calendar`. Remember: **both `closed_for_checkin` and
`closed_for_checkout` must be included** in every date object (see Step 4 note). Read the
current calendar state and carry forward the value for whichever field you are NOT changing.
For checkout dates (unblock check-in) — preserve existing `closed_for_checkout`:
```
dates:
- date: <checkout_date>
closed_for_checkin: false
closed_for_checkout: <current value from calendar>
```
For check-in dates (unblock checkout) — preserve existing `closed_for_checkin`:
```
dates:
- date: <checkin_date>
closed_for_checkin: <current value from calendar>
closed_for_checkout: false
```
**Important:** Same merge logic as Step 4 — if a date still needs one restriction (e.g., it's
a checkout date for an accepted reservation but the check-in reservation was cancelled), only
remove the restriction that's no longer needed. Never blindly set both to `false`.
---
## Part C — Notify and report
### Step 9 — Notify the co-host via iMessage (only if changes were made)
If any dates were newly blocked (Step 4) or unblocked (Step 8), send the co-host a single
iMessage summarizing all changes. Do not message if no changes were made.
```
Tool: send_imessage
Parameters:
phone_or_email: "<COHOST_EMAIL_OR_PHONE>"
body: <see message format below>
```
**Message format** — keep it short and practical:
```
Cottage turnover buffer update:
[If checkout dates were blocked for check-in:]
Blocked check-in on [date(s)] (checkout day):
- [date] checkout → earliest new check-in [next day]
[If check-in dates were blocked for checkout:]
Blocked checkout on [date(s)] (check-in day):
- [date] check-in → no other guest can check out that day
[If dates were unblocked:]
Re-opened [date(s)] (reservation cancelled):
- [date] is now available again
No action needed on your end — just FYI!
```
Example with multiple actions:
```
Cottage turnover buffer update:
Blocked check-in on 7/30 (checkout day). Earliest new check-in → 7/31+
Blocked checkout on 7/18 (check-in day). No other guest can check out 7/18.
Re-opened 8/3 for check-in (reservation cancelled, no longer needed).
No action needed on your end — just FYI!
```
### Step 10 — Report results
Summarize what was done:
- How many accepted reservations were found in the window
- How many were filtered out (booked before 2026-05-09)
- How many checkout dates were already blocked for check-in (skipped)
- How many checkout dates were newly blocked for check-in
- How many check-in dates were already blocked for checkout (skipped)
- How many check-in dates were newly blocked for checkout
- How many cancelled reservations were found
- How many dates were unblocked (and which restriction was removed)
- Whether the co-host was notified
If no changes were needed, report that everything is up to date.
## Example Output
```
Turnover Buffer Report — 2026-05-15
ACCEPTED reservations in window (7/7–8/14): 6
Qualifying (booked 5/9+): 6
Checkout dates → block check-in:
Already blocked: 4
Newly blocked: 2
✓ 2026-07-30 (HMXXXXXXXX) — closed for check-in
✓ 2026-08-10 (HMYYYYYYYY) — closed for check-in
Check-in dates → block checkout:
Already blocked: 4
Newly blocked: 2
✓ 2026-07-18 (HMXXXXXXXX) — closed for checkout
✓ 2026-08-05 (HMYYYYYYYY) — closed for checkout
CANCELLED reservations in window: 1
Unblocked: 1
✓ 2026-08-03 (HMZZZZZZZZ) — re-opened for check-in (no other checkout on this date)
✓ Notified the co-host via iMessage
```
## Notes
- This skill only affects the **check-in and checkout restrictions** on specific dates. It does
not change availability, pricing, minimum stay, or any other calendar setting.
- The booking_date filter (`>= 2026-05-09`) is a permanent cutoff, not a rolling window.
- The cancel-unblock logic is conservative: it only unblocks a date if NO accepted reservation
shares that checkout date. When in doubt, the block stays.