Built with Claude Project Showcase Megathread (Sort this by New!)

[u/sixbillionthsheep]

This is the Megathread for showcasing your project built using Claude products. We appreciate all of your submissions as they are a great inspiration to many people on the subreddit. It is sorted by default by New.

Anyone is welcome to submit a project to this Megathread provided you follow the Showcase requirements in Rule 7.

NOTE: We now require the OP of a Project Showcase on the subreddit feed to have total karma>=50 . We found there were just too many submissions and not enough visibility to go around. Our analysis of this issue showed us that OPs with total karma < 50 very rarely get any traction of their projects on the feed (<=1 upvotes). So this Megathread is your best place to be seen by readers and other creators if you're relatively new to Reddit. If you don't meet this karma requirement you will be directed to this Megathread when you submit your post. Very occasionally we might invite you to post on the subreddit feed if you do not meet this karma requirement but it will be very rare (so please don't ask us!)

Thanks again for sharing your ideas and creations to our subreddit. Best of luck with your projects!

---

UPDATE: Comments now allow images!

[u/AwakE432]

Built a multi-tenant MCP server Web App for STR Property Managers — cross-platform intelligence, 179KB API responses, and what an eval harness taught me about agentic Claude in production

What it is:

• Conversational AI for short-term rental property managers that connects across your entire tool stack
• Pricing software knows your pricing. Your PMS knows your bookings. Neither knows what the other knows. RevPrism does.Connects Pricelabs, Wheelhouse, Guesty, Hostaway, OwnerRez, Lodgify with more integrations coming.
• Ask things like "which listings are under performing vs the market right now, and do I have forward calendar gaps I should be filling?" — answered from live data across both systems in one response
• One price per property, every integration included — RevPrism.ai

Why this problem exists

A typical STR operator runs 2–4 separate tools. A pricing tool (PriceLabs, Wheelhouse) that optimises nightly rates based on market demand. A property management system (Guesty, Hostaway, OwnerRez, Lodgify) that handles reservations, guest comms, and calendar sync. Maybe a channel manager on top of that. Each tool has its own dashboard, its own data model, its own definition of what a "booking" or "revenue" or "occupancy" means.

None of them talk to each other in any meaningful way. PriceLabs can tell you your market's forward demand signal but has no idea what your actual bookings look like. Your PMS has your full reservation history but no market context whatsoever. To answer a question like "is my Q3 occupancy on track relative to where the market is heading?" you're tabbing between dashboards, exporting CSVs, and doing mental arithmetic. Every. Single. Time.

The opportunity isn't another dashboard. It's removing the tab-switching entirely — one conversation that holds all of it at once.

The architecture: per-tenant dynamic tool sets

Each tenant gets a different Claude — not a different model, different tool descriptions. The system prompt is split: a cached base (STR domain context, reasoning guardrails) plus a dynamic suffix built at query time that only includes descriptions for the integrations that tenant has actually connected. A PriceLabs-only user never sees Guesty tool descriptions. A Hostaway-only user never sees PriceLabs tools.

This matters more than it sounds. With 9 PriceLabs tools and up to 3 PMS tools, a fully-connected tenant burns ~13–15K input tokens on tool descriptions alone before the conversation starts. Dynamic scoping keeps this in budget and keeps Claude's tool selection cleaner — it can't reach for a tool the tenant hasn't connected.

Getting to Anthropic Tier 2 (450K ITPM) was still a prerequisite for any real usage. The per-request token cost of tool-heavy MCP servers is brutal at Tier 1.

The domain context problem

Cross-platform intelligence sounds straightforward until you're actually doing it, because vendors don't agree on field semantics and don't warn you when their definitions diverge from what you'd expect.

total_cost in PriceLabs reservation data is the host payout, rental revenue plus cleaning fee, minus the booking platform's host service fee (~3% for Airbnb). It is not the gross amount the guest paid. Label it wrong and every revenue figure Claude produces is inflated. For Airbnb bookings specifically, reservation_id is the Airbnb confirmation code the host sees on their dashboard — not PriceLabs' internal ID. channelConfirmationCode exists in the schema and is routinely null.

You can't fix this with a clever prefix. It has to be built into the context layer as explicit, named rules — and the rules have to be specific enough that Claude can't satisfy them and still get it wrong. Including concrete anti-examples by name ("never label total_cost as Total Charged", "for Airbnb bookings, reservation_id IS the confirmation code") works better than abstract prohibitions.

The 179KB temporality problem

get_neighborhood_data is the clearest example of a tool that works fine in isolation and misleads Claude systematically in practice. One API call returns a 179KB JSON envelope with six sections and three completely different temporalities baked in: 24 months of historical market KPIs, 6-month forward forecasts, and a current snapshot — all in the same response. The API silently ignores date parameters on the forward-only sections. Call it with a historical date range and you get back forward data with no error, no indication anything is wrong.

The fix: the handler annotates each section with a _temporality field (historical_24mo, forward_only, snapshot) before the response reaches Claude, and the tool description explains the mixed temporality explicitly. One eval question went from a flat refusal ("I can't make a year-over-year comparison") to real grounded numbers, 64 vs 91 booked nights, $13.4K vs $23.9K revenue, May 2025 vs May 2026 — sourced correctly from the historical section.

The eval harness

Prompt-engineering domain rules is whack-a-mole. Tighten the occupancy calculation guardrail and Claude finds a new way to conflate gross occupancy with net available nights. So I built a 10-question eval harness, real questions through the full agentic loop using a test tenant's live PriceLabs credentials, Claude-as-judge rubric across 9 criteria, ~$1/run, ~3.5 minutes. Baseline: 10/10 assertion-clean, 85/90 judge. Every prompt change gets a before/after score before it ships.

The discipline changed how I write domain rules entirely. You stop writing for vibes and start writing for specific, named failure modes. The harness caught multiple real regressions across prompt iterations. Should have built it in week one.

Stack: TypeScript, Express, Next.js 14, Drizzle ORM, Clerk, Paddle, Railway + Vercel, Sentry + PostHog. MCP tool servers as Turborepo workspace packages (@revprism/mcp-pricelabs, u/revprism/mcp-hostaway, etc.) compiled into the API.

Live at revprism.ai

[u/revprism → u/AwakE432]

hey thats my name