Daniel sent us this one — he's frustrated with the content recommendation landscape, especially as a non-US viewer. He's tired of seeing "only available in the US" on mainstream platforms, tired of being nickel-and-dimed with eight-dollar rentals for things that should be in a subscription, and he doesn't want to spend his evening sifting through YouTube just to find something worth watching. His idealized app is basically one button — knows his preferences, knows what he's already watched, and crucially knows what he can actually watch from his location. No false promises that crumble at the geo-block. He's asking whether this already exists or whether he needs to build it himself, and he wants us to walk through the landscape — JustWatch, Reelgood, Trakt, Letterboxd, Plex Discover, the AI-powered tools — what they actually do well, and where they fail for international users.
He specifically mentioned MCP as the technical backbone that makes this theoretically doable. Which it is. But the gap between "technically doable" and "actually exists" is a canyon here, and it's not a technical canyon.
The technical side is almost boringly solved. The hard part is that the streaming industry has spent two decades building walls around their data, and they're not taking them down for anyone.
By the way, DeepSeek V four Pro is writing our script today. Which is fitting, given we're talking about recommendation systems. Hope it recommends us a good episode.
I'd settle for it recommending me a nap schedule. But let's dig into this. The landscape Daniel's describing — I think a lot of people feel this exact frustration but can't articulate why the tools that exist don't quite work.
Let's name it. The core problem is data fragmentation across three dimensions. Dimension one is content metadata — what exists, who made it, what's it about. Dimension two is availability data — where can you watch it, in which country, at what price, under which license. Dimension three is personal watch history — what have you already seen, what did you rate, what did you abandon halfway through. Any recommendation tool that doesn't nail all three is going to fail in exactly the ways Daniel's describing.
Most tools nail maybe one and a half.
Let's go through them. JustWatch and Reelgood are the two big players in the availability-plus-discovery space. They aggregate streaming catalogs across dozens of services and tell you where something is available to stream, rent, or buy in your region. JustWatch covers something like a hundred countries now. You set your country, you search for a title, it shows you the options. That's dimension two done reasonably well.
Reasonably well, but not perfectly. I've used JustWatch from here in Israel, and the accuracy is spotty. Sometimes it says something's on Netflix and it's not. Sometimes it misses that a title left the catalog last week.
That's the catalog freshness problem. Streaming catalogs change constantly — Netflix adds and removes hundreds of titles every month. JustWatch and Reelgood rely on a combination of automated scraping and direct API partnerships with some services, but not all. Reelgood, importantly, has no public API. They used to have one, but they shut down developer access. JustWatch similarly doesn't offer a public API — they have some B2B partnerships, but if you're a developer like Daniel wanting to build on top of their availability data, you're out of luck.
The best availability data in the industry is basically walled off. What about the other tools?
Trakt is interesting because it attacks dimension three — watch history and personal tracking — better than almost anyone. It's a scrobbling service. You connect it to whatever you're watching on, and it logs everything automatically. It knows what you've seen, when you watched it, what you rated it. And crucially, Trakt does have a public API. It's been around for years, it's well-documented, and a whole ecosystem of third-party apps is built on top of it.
That's the good news. What's the bad news?
Trakt doesn't do availability. It's purely a tracking and discovery layer. It'll tell you what's trending, it'll give you personalized recommendations based on your watch history, but it won't tell you where to actually watch any of it. And its recommendations are based on community data, not on catalog availability, so it'll happily recommend things that aren't available in your country.
Trakt solves the "what should I watch" part, but hands you a list of things you can't actually watch. That's almost more frustrating than no recommendation at all.
It's worse than you think — because even if Trakt wanted to add availability data, there's no clean way for them to get it. Netflix's public API was shut down in twenty fourteen. Hulu, Disney Plus, HBO Max — none of them have public APIs for catalog or availability data. The only way to get this data is through scraping, which is fragile, legally questionable, and breaks constantly.
The industry has actively removed the infrastructure that would make a tool like Daniel's possible. That's not an accident.
It's absolutely deliberate. Netflix has spent billions on content and on their recommendation engine. They consider their catalog data and user behavior data to be core competitive assets. They're not going to hand that to a third party so someone can build a better discovery layer on top of them. They want you inside their app, using their recommendation system, watching their content.
Which brings us to Letterboxd. It's a social network built around film discovery and criticism. It's fantastic for what it does — tracking what you've watched, writing reviews, following people with interesting taste, building watchlists. But it's almost entirely focused on the film-as-art perspective. It doesn't care where you can watch something. It'll show you that some obscure nineteen-seventies Japanese film is trending among cinephiles, and you're on your own to figure out how to actually see it.
That's fine for the Letterboxd audience, which skews toward people willing to hunt down physical media or attend repertory screenings. But Daniel's describing a much more practical use case. He wants to sit down after a long day, press a button, and watch something good that he hasn't seen. Letterboxd is not that button.
Plex Discover was supposed to be closer to that button. Launched in twenty twenty-two as a universal watchlist and discovery layer that aggregated availability across services. The idea was exactly what Daniel's describing — you search for something, Plex tells you where it's available, and if it's on a service you have connected, you can launch it from there.
It works sometimes. But the coverage is incomplete, and the accuracy depends heavily on your region. Plex relies on the same scraping and partnership model as JustWatch, which means the same catalog freshness problems. Plus, Plex Discover is built into the Plex media server ecosystem — it's optimized for people who already have a Plex server. If you're not in that ecosystem, the value proposition is weaker. And Plex has been pivoting hard toward becoming a streaming service themselves with ad-supported content and live TV. The discovery layer feels increasingly like a side feature rather than the core product.
Now, what about the AI-powered recommendation tools? There's been a wave of these — services that use large language models to give you personalized recommendations. The pitch is usually something like "ChatGPT for movies.
I've tried a few. They're good at the conversational part — you can say "I want something like Blade Runner but less bleak" and they'll give you a reasonable suggestion. But they have no idea what's actually available to you. They're recommending from a knowledge base of "all movies that exist," not "all movies you can watch right now." They're solving the taste-matching problem while completely ignoring the access problem.
Let's synthesize. We've got JustWatch and Reelgood doing availability but with no public API and spotty regional accuracy. We've got Trakt doing watch history beautifully with an open API but zero availability data. We've got Letterboxd doing social discovery with no access layer. We've got Plex Discover trying to do everything but with incomplete coverage and a narrow ecosystem focus. And we've got AI tools that understand taste but not availability. Nobody is doing all three dimensions at all. Daniel's one-button app doesn't exist.
The question he's really asking is: could it exist? Is this a solved technical problem with business obstacles, or is there something genuinely hard here that nobody's cracked?
Let's separate the technical from the non-technical. On the technical side, MCP — the Model Context Protocol — does change the game. MCP allows an AI agent to connect to multiple data sources through a standardized interface. You could have one MCP server that connects to Trakt for watch history, another that scrapes or queries availability data for your region, another that does the taste modeling using a local or cloud-based LLM. The agent orchestrates across all of them and gives you a recommendation that accounts for all three dimensions.
In theory, Daniel could build a personal MCP agent that does exactly what he wants. It queries his Trakt history, checks JustWatch or a similar source for what's available in Israel, applies his preferences, and spits out a shortlist of things he can actually watch right now. And people are already experimenting with this. There are early-stage MCP servers that provide streaming availability lookups — one uses the TMDB API for metadata and combines it with scraping for availability, another connects to Plex servers for personal library search. The pieces are all there, and MCP makes them composable in a way that wasn't practical before.
"in theory" is doing a lot of work. Walk me through the realistic obstacles.
Obstacle one: availability data is a nightmare. There is no single authoritative source for "what can I watch in Israel right now." JustWatch and Reelgood build their data through a combination of scraping, partnerships, and manual curation. If Daniel wants to build his own version, he's either scraping dozens of streaming sites — which breaks constantly and has legal exposure — or he's paying for a commercial API. And as we established, those commercial APIs aren't really available to individual developers.
What about TMDB? They've got a "watch providers" endpoint in their API. It's actually pretty good — covers a lot of countries and services. But it's community-maintained, which means it has the same freshness problems. A title might show as available on Netflix Israel when it was actually removed two weeks ago. For a one-button experience, that's a fatal flaw. If the tool tells you something's available and it's not, you stop trusting the tool.
Obstacle two is the watch history portability problem. Every streaming service keeps your watch history in its own walled garden. Netflix knows everything you've watched on Netflix. Disney Plus knows what you've watched on Disney Plus. There's no standard for exporting this data, no API for querying it, and no incentive for the services to make it portable. Trakt works around this by having you connect apps that scrobble on your behalf, but it's a workaround, not a solution. You're relying on third-party developers to maintain integrations with platforms that actively don't want to be integrated with.
The streaming services don't want your watch history to be portable. Your watch history is what powers their recommendation engines, and their recommendation engines are what keep you inside their app. If you could take your Netflix watch history and plug it into a universal recommender, Netflix loses a competitive moat. This isn't a technical limitation — it's a business strategy. The friction is the product.
Obstacle three is the geo-availability API problem. Even if you solve data freshness and watch history portability, you still need to know, in real time, what's available in a specific country. And the streaming services don't publish this in any structured way. The licensing landscape makes it complicated even for them — a title might be available on Netflix in Israel but not in the US, or available for streaming in one country but only for rental in another. These deals are negotiated territory by territory, service by service, and they change constantly. There's no central clearinghouse because the rights holders don't want there to be one.
The idealized app Daniel's describing is technically buildable for a single person willing to invest the time. But it's not productizable. You can't turn it into a service other people can use without running into all three obstacles at scale.
That's the honest answer. As a personal project, using MCP to wire together Trakt for history, some scraping or TMDB for availability, and a local LLM for the recommendation logic — that's doable. It won't be perfect, the availability data will sometimes be wrong, and you'll spend more time maintaining the scrapers than you'd like. But it'll work well enough for personal use. The problem is solved at the level of "a technically skilled person can build this for themselves." It's completely unsolved at the level of "anyone can download an app and have it just work.
Daniel's noticing the missing third, because as a non-US viewer, the availability dimension isn't a nice-to-have — it's the whole game. If you're in the US, the availability problem is relatively easy. Most things are available somewhere, usually on a service you already have. If you're in Israel or Ireland or Brazil, the availability problem is the first thing you hit every single time you try to watch anything.
This is the structural problem. The streaming industry has spent the last decade building national content silos. Every service maintains separate catalogs for every country. The reasons are partly licensing, but they're also strategic. A fragmented global market means services can price differently in different countries, acquire content differently, and avoid competing on a truly global scale. The side effect is that international viewers get a worse experience — they pay roughly the same subscription fees for smaller catalogs, get later release dates, and navigate a much more complex availability landscape. The industry isn't just failing to solve this problem — they're actively maintaining it.
Because solving it would mean competing on price and user experience globally rather than territory by territory. And that's a much harder business. So where does that leave someone like Daniel?
I think there are a few things he can actually do. The first is to invest in building the personal MCP agent we described. It's a weekend project to get something basic working, and then you iterate. The key components: use Trakt as the watch history backbone, use TMDB's watch providers API as a starting point for availability, and use something like Claude or a local model for the recommendation logic. Accept that the availability data won't be perfect and build in some tolerance — maybe the agent suggests three things and one turns out to be unavailable, but the other two work.
That's probably the most realistic path. But I want to push on something. Daniel mentioned Mubi as "lovely but very indie." And I think there's an unspoken assumption that the solution has to be an aggregator on top of the existing services. What if the better solution is to change which services you use?
Mubi works differently. It's a curated service — they pick thirty films a month, one new film every day, and that's your selection. It's small, it's curated, and it's globally consistent. You don't have the geo-block problem because Mubi licenses films globally rather than territory by territory. The selection is limited, but the experience is clean. No false promises. You trade variety for reliability.
For certain kinds of viewers — the kind who'd rather watch one good thing than scroll through a thousand mediocre things — that trade might actually be worth it. The problem is that Mubi's curation skews heavily toward art-house and international cinema. If your interests are tech, AI, geopolitics — as Daniel mentioned — Mubi's catalog isn't going to serve you well.
Which brings us to YouTube, which Daniel specifically mentioned he doesn't want to spend his evening sifting through. And I get that. YouTube's discovery experience is exhausting. The algorithm optimizes for engagement, not for satisfaction. But YouTube also has the content Daniel's actually interested in. The tech commentary, the geopolitical analysis, the long-form deep dives — that stuff lives on YouTube. The problem isn't the content, it's the discovery layer. And that's actually a more solvable problem than the streaming availability one.
Because YouTube does have an API. A pretty good one. You can query it for channels, for playlists, for recommendations based on watch history. If Daniel's primary interest is in tech and geopolitics content, building a personal recommendation tool on top of YouTube's API is dramatically easier than building one on top of the fragmented streaming landscape. You don't have the geo-block problem — YouTube content is almost universally available. You don't have the catalog fragmentation problem — it's all on one platform.
That's a useful insight. The "one-button app" Daniel's describing might be much closer to reality if you scope it to YouTube rather than trying to solve the entire streaming universe. You train it on the channels and topics you care about, it builds a feed of unwatched content that matches your interests, and it presents it without the algorithmic sludge. You could extend it beyond YouTube pretty easily — add RSS feeds for podcasts and newsletters, add article recommendations from sources you trust. The "what should I consume right now" problem is broader than just movies and TV, and the non-streaming parts of it are much more tractable.
That's a different product than what Daniel described. He specifically asked about movies and TV. And I think there's value in being honest that the movie and TV recommendation problem, specifically for international viewers, is hard in ways that personal effort can only partially overcome. Let me put some numbers on this. Netflix's catalog size varies by more than a factor of three between the US and some smaller markets. The US catalog has something like six thousand titles. Some countries have fewer than two thousand. Same subscription price, massively different value proposition.
That's just Netflix. In the US, you might have access to five or six major streaming catalogs. In Israel, some of those services don't even operate, and the ones that do have smaller libraries. The availability problem isn't just a minor inconvenience — it's a fundamentally different experience depending on where you live. And none of the recommendation tools on the market account for this in a meaningful way.
Which is probably smart from a user experience perspective. That information would just make people angry — because it reveals how arbitrary the whole system is. These aren't natural constraints — they're business decisions. The technology exists to make content globally available. The industry chooses not to.
Now: Hilbert's daily fun fact.
The collective noun for a group of pugs is a grumble. A grumble of pugs.
If Daniel were sitting here asking me what to actually do, I'd give him a three-part answer. Part one: for movies and TV specifically, lower your expectations about what a single tool can do. Use JustWatch or Reelgood for availability lookup, use Trakt or Letterboxd for tracking and discovery, and accept that you're going to be doing some manual integration between them. It's not one button, it's three or four, and that's where we are right now.
Part two: build the personal MCP agent anyway, but scope it realistically. Don't try to solve the whole streaming universe. Start with a narrow use case — maybe just "what should I watch on Netflix Israel tonight that I haven't seen" — and expand from there. The MCP architecture makes it easy to add new data sources over time. You can start with Trakt and TMDB and add more sophisticated availability scraping as you need it.
Part three, which I think might actually be the most practical: invest in curating your own sources rather than relying on algorithmic discovery. Follow specific critics whose taste you trust. Build relationships with platforms like Mubi that do curation well. Subscribe to newsletters that surface interesting content in your areas of interest. The algorithmic recommendation dream is seductive, but the curated recommendation reality is more achievable right now.
There's a broader point here about the state of recommendation systems. We've spent twenty years trying to build algorithms that understand our taste, and the results are fine. Netflix's recommendation engine is sophisticated, but it still mostly surfaces things that are similar to things you've already watched. It's good at "more like this" and bad at "something completely different that you'd love." A good critic or curator can surprise you — they can recommend something you'd never have found on your own because it doesn't fit neatly into your established preference patterns. Algorithms optimize for engagement, which means they optimize for the familiar. Curation can optimize for discovery.
Which connects to something Daniel mentioned — that Netflix feels formulaic. That's not an accident. Netflix optimizes for content that performs well with their recommendation algorithm, which means content that appeals to broad, predictable taste clusters. The weirder, more challenging stuff gets deprioritized because it doesn't fit the algorithmic mold.
We've got two parallel problems. Problem one is the technical infrastructure problem — the APIs don't exist, the data is fragmented, the geo-blocks are deliberate. Problem two is the curation problem — even if you solve the infrastructure, the underlying content discovery experience on major platforms is optimized for engagement, not for satisfaction. Daniel's one-button app would need to solve both. And solving both at scale is hard. Solving both for yourself, as a personal project, is achievable. The gap between those two statements is where the whole industry lives.
One thing we haven't talked about is the piracy angle Daniel mentioned. He said he can't endorse torrents on moral or security grounds, but he noted that the industry's behavior pushes people in that direction. When the legal options are fragmented, expensive, and geographically inconsistent, piracy stops being about getting something for free and starts being about getting something at all.
There's good research on this. When legal streaming options become available in a market, piracy rates drop. When content is easy to access legally, people choose the legal option. The problem isn't that people want to pirate — it's that the legal options are worse in many markets. You pay more for less content with a worse user experience. The geo-blocking in particular creates the absurd situation where someone in Israel is willing to pay for content but literally cannot, because the rights holder hasn't bothered to make it available in that territory. That's not a piracy problem — that's a market failure.
It's a market failure that the industry has accepted as the cost of doing territory-by-territory licensing deals. They'd rather lose some international revenue than restructure their entire licensing model around global availability.
To bring this back to Daniel's original question: does the app exist? Can he build it? Yes, for himself, with MCP, with realistic expectations about data quality, and with the understanding that maintaining it will be an ongoing project, not a one-time build. Should someone build it as a product? Not until the streaming industry changes its posture on data access. And that's unlikely in the near term. The incentives all point toward more walled gardens, not fewer. Every major service is investing in original content and proprietary recommendation systems. They're not going to voluntarily become dumb pipes that feed content into someone else's discovery layer.
The one wildcard is regulation. The EU's Digital Markets Act has already forced some platform openness, and there's been discussion about extending similar requirements to streaming services — mandatory APIs for catalog data, data portability requirements for watch history. If that happens, the landscape changes overnight. But we're years away from that, if it happens at all. And it would likely be EU-specific, which doesn't help Daniel in Israel.
The honest answer is: build it yourself, scope it narrow, use MCP, accept imperfection, and in the meantime, support the platforms and services that are actually trying to solve the global availability problem rather than perpetuating it. Mubi, for all its limitations, is doing something different. Services that license globally deserve support because they're building the infrastructure for the world Daniel wants to live in.
Daniel, if you do build it — the MCP agent that ties together Trakt, TMDB, and a recommendation layer — we'd love to hear how it goes. The pieces are all there. The integration work is non-trivial but doable. The main thing holding it back isn't technology — it's the industry's active resistance to making their data accessible. That's the story of a lot of things right now. The technology is ready. The incentives aren't aligned. And until they are, the people who want better experiences are going to have to build them themselves.
Thanks to Hilbert Flumingtop for producing, as always. This has been My Weird Prompts. You can find every episode at myweirdprompts dot com or wherever you get your podcasts.
If you've built something that solves this problem — or if you've given up and just watch whatever Netflix puts in front of you — we'd love to hear about it. Until next time.
