Daniel's apartment hunt has turned into a linguistics puzzle. He's looking for a specific trolley — the kind with a little platform for carting things between rooms, probably a Euro box, maybe one with a built-in tub. And what he's discovered is that buying obscure industrial products in Israel means navigating terminology chaos in two languages simultaneously. Different websites use completely different words for the same object. So he's developed a workaround: find an image of what he wants, run it through Google Lens, and tack on the Hebrew word for "price" — mechir — to force results onto Israeli sites. It works, but it's clunky, it's non-programmatic, and it got him thinking: why isn't there an MCP for this? A way for an AI agent to say "here's what I'm looking for, go find vendors in Israel" and actually get structured results back?
This is one of those prompts where the surface question — "how do I find a trolley" — opens into something much bigger. Daniel's essentially discovered a fundamental mismatch between how humans identify objects and how e-commerce catalogs organize them. Humans think visually. We have a picture in our head. E-commerce thinks textually, with taxonomies that are inconsistent even within a single language, let alone across languages in a market like Israel's.
And he's not doing anything high-volume. He's just trying to furnish an apartment. But the friction he's hitting is the exact same friction that would face any AI agent trying to do visual procurement at scale. The hack works for one guy with a browser — it completely breaks down the moment you try to automate it.
So let's start by understanding why a simple search for a trolley turns into a multilingual scavenger hunt. The Israeli e-commerce market is about eight billion dollars annually, but it's fragmented across hundreds of small retailers. Most of them are running basic WordPress or Wix stores. And the products they're selling — these industrial items, storage solutions, utility carts — they're almost all imported.
Which means the product arrives with a manual that was translated from Chinese to English by someone in Shenzhen, then gets listed on an Israeli site where the shop owner has to decide: do I call this a trolley, an industrial cart, a platform truck, or do I transliterate the English word into Hebrew characters?
Right. And you end up with three parallel naming systems for the exact same object. You've got the original English term, which might be "Euro box trolley" or "container cart" or "rolling platform." Then you've got the transliterated version — "trolley" written in Hebrew letters, which is what a lot of Israelis would actually search for. And then you've got the native Hebrew terms, which themselves vary. An agala, which is the biblical word for cart or wagon. A tzaroni al galgalim, which is "suitcase on wheels." None of these map cleanly to each other.
So the same product exists on five different Israeli sites under five different names, and the images are the only thing that's consistent. Which is exactly why Daniel's instinct to search visually is correct. The problem is what happens next.
To get to the bottom of this, we need to look at how Google Lens actually works under the hood. And this is where most people have a misconception. They think Google Lens is just a wrapper around Google Images search — that it's taking your query image, running it through the same index, and just returning visually similar results from the same pool of web images that text search uses. That's not what's happening.
What's actually happening?
Google Lens uses a separate visual embedding model — likely based on a variant of Google's Vision Transformer architecture. This model converts images into high-dimensional vectors, essentially a string of numbers that represents the visual features of the image. Those vectors get matched against a completely separate index of web images that have been pre-processed through the same embedding model. This visual index is not the same as the text search index.
So when Daniel types "site colon il" into Google Lens, he's speaking a language the visual index doesn't understand.
Those advanced search operators — site colon, filetype colon, intitle colon, all the Google Dork operators — those are applied at the text index level. They're filters that operate on the structured metadata of web pages: URLs, titles, body text. The visual index doesn't carry that metadata in the same way. It's optimized for visual similarity, not for URL-level filtering.
Which is a design choice, not a technical impossibility. Google could cross-reference the two indexes. They choose not to, or at least they haven't built that bridge yet.
And you can see why. The visual index is enormous — billions of images — and the computational cost of maintaining real-time joins between visual embeddings and URL-level metadata would be substantial. Google's priority for Lens has been speed and visual accuracy, not regional filtering. Most people using Lens are trying to identify a plant or translate a sign or find out where to buy a dress they saw on Instagram. The "find me this exact industrial trolley but only from vendors in Israel" use case is... niche.
Niche, but not unreasonable. And Daniel's mechir hack is genuinely clever because it exploits a side channel in the multimodal matching pipeline.
Let me explain why this works, because it's elegant. When you append the word mechir — price — in Hebrew to a Google Lens search, you're not filtering by URL. What you're doing is forcing Google Lens to cross-reference its visual matches with text snippets that contain that specific Hebrew word. The multimodal model is looking for pages where the image is visually similar AND the surrounding text contains the Hebrew word mechir. Since Israeli e-commerce pages almost universally include the word mechir somewhere on the page — it's a price, after all — this effectively filters results to Hebrew-language pages, which overwhelmingly means Israeli sites.
It's a hack that exploits the fact that certain words are so common in a specific language context that they become a proxy for geographic filtering. The word mechir doesn't mean "Israel," but on the practical web, pages containing mechir are disproportionately Israeli e-commerce pages.
And you could improve the recall by using multiple filter words. Mechir, kniya for purchase, mishloach for shipping. Each one catches a slightly different subset of pages. But it's still non-deterministic. You're not guaranteed to get all Israeli results, and you might get some non-Israeli pages that happen to include Hebrew text — like an Israeli expat blog reviewing products, or a bilingual catalog from a European company that ships to Israel.
The bigger limitation, and Daniel flags this, is that none of this is programmable. You can't script it. You can't build a tool that says "take these fifty product images, run them through Lens with the mechir filter, and return structured results with prices and vendor names." Every search is a manual browser interaction.
Which brings us to the MCP vision. And this is where things get interesting.
Before we get to MCP, let me just sit with the current state of reverse image search for a moment. Daniel mentions being surprised at how locked down it is. I had the same reaction when I started looking into this. TinEye has been around since two thousand eight — it's one of the oldest reverse image search engines — and it's almost entirely focused on copyright enforcement. Finding where your photo has been used without permission. That's the use case. Not product sourcing.
And the platforms that do product sourcing well — Alibaba, AliExpress, Amazon — they're walled gardens. Alibaba processes over a hundred million visual queries a day, and their image search is tightly integrated with their supplier database. You upload a photo of a trolley, they show you fifty Chinese factories that make something similar, with pricing and minimum order quantities. It's impressive. But it only works inside Alibaba's ecosystem. They don't expose that visual search capability to third-party agents.
So you've got two worlds. World one: general-purpose reverse image search that's optimized for exact matches and near-duplicate detection, with no regional filtering and no product inventory integration. World two: platform-specific visual search that's excellent for product sourcing but completely siloed. Nothing bridges them.
And the Israeli market makes this gap especially painful because there's no dominant platform that has both the inventory breadth and the visual search capability. Zap and Yad2 have some image search features, but they're limited to their own catalogs, and their catalogs are a fraction of what's actually available across all the small retailers.
So the hack works, but it's a hack. What would a proper solution look like? That's where the MCP vision comes in.
So MCP — the Model Context Protocol — was introduced by Anthropic in November of twenty twenty-four. It's an open standard for connecting AI agents to external tools and data sources. Think of it as a universal plug socket. Instead of every AI application having to build custom integrations with every API, MCP defines a standard way for an AI to discover what tools are available, call them, and receive structured results back.
And Daniel's idea is: build an MCP server that exposes a "find products by image" tool. You pass it an image URL and a region, and it returns structured results from multiple local e-commerce APIs.
The function signature would be something like find underscore products underscore by underscore image, taking an image URL and a region parameter — say, "Israel" — and returning a list of products with vendor names, prices, availability, and links. The AI agent doesn't need to know how the search works under the hood. It just says "here's what I want, go find it in Israel," and the MCP server handles the messy work of querying multiple sources, normalizing results, and returning structured data.
The technical challenge isn't the MCP layer itself. MCP is well-designed for this — it supports tool discovery, structured inputs and outputs, even streaming results. The challenge is what's behind the MCP server. Where does it get its data?
This is the chicken-and-egg problem. For a vendor-agnostic visual product search to work, you need access to product images from many local retailers, with clean structured metadata — product names, prices, availability, categories. Israeli e-commerce sites often don't have that. Many of them are small businesses running basic storefronts. Their product feeds, if they exist at all, are inconsistent. Images vary wildly in quality. Metadata is sparse or absent.
You'd need to build a crawler that scrapes hundreds of Israeli e-commerce sites, extracts product images and metadata, normalizes everything into a consistent schema, and then builds a visual search index on top of that. That's a significant engineering project.
You'd be fighting against sites that aren't designed to be scraped. No clean APIs, no structured data markup, often no sitemaps. You'd essentially be building the index that Google already has, but with the regional filtering that Google doesn't expose for visual search.
There's an irony here. Google has already crawled all these sites. Google already has the images, the text, the URLs, the structured data. All the pieces exist inside Google's infrastructure. The limitation isn't that the data doesn't exist — it's that Google hasn't built the query interface that would let you say "visually similar products, filtered to Israeli domains, sorted by price."
You can understand why, from Google's perspective, this isn't a priority. The number of people who want to do visual product search with geographic filtering is small. The number who want to do it programmatically through an API is even smaller. Google's incentives are around ad revenue from shopping queries, not around building open infrastructure for niche procurement workflows.
Which leaves us where? Daniel's mechir hack is actually state-of-the-art for this particular use case. That's both impressive and a little depressing.
Given the current landscape, what can you actually do right now to make this workflow less painful? I've got a few concrete suggestions.
Let's hear them.
First, the mechir hack can be improved by using multiple Hebrew filter words. Don't just use mechir. Rotate through kniya, mishloach, miluy — that's "stock" or "inventory" — and even just the Hebrew word for Israel itself. Different words catch different subsets of pages. If you're not finding what you need with one filter word, try another.
Build a mental list of five or six Hebrew commerce terms and cycle through them.
Second, for power users, there are browser extensions that can partially automate this workflow. Search by Image on Firefox allows you to set up custom search engines with URL parameters. You could configure it to send your image to Google Lens and automatically append a Hebrew filter word. It's not fully automated, but it saves you the step of typing mechir every time.
For the more technically inclined?
This is where I think Daniel's MCP idea is viable as a side project. If you're a developer, consider building a simple MCP server that wraps multiple Israeli e-commerce APIs — Zap has an API, Yad2 has some programmatic access, KSP, Ivory — and adds basic image search capability. You don't need to build the full visual embedding index yourself. You can use Google Lens or Bing Visual Search as a first pass to find visually similar products globally, then cross-reference those results against the Israeli APIs to find local vendors carrying the same or similar items.
The MCP server becomes a two-stage pipeline. Stage one: reverse image search against the global index to identify what the product is and what it's called in various naming conventions. Stage two: text search against Israeli e-commerce APIs using all those naming variants, filtered by price and availability.
That's exactly the architecture I'd recommend. And it sidesteps the hardest problem — building your own visual index of Israeli e-commerce — by using the global indexes for visual matching and the local APIs for availability and pricing. The MCP server is the glue that connects them.
The naming variant piece is actually crucial. If Google Lens identifies your trolley image as a "Euro box container cart," but the Israeli site lists it as an "agalat plastik mitgalgelet" — a rolling plastic cart — the MCP server needs to know that those are the same thing. That's a translation and normalization problem on top of the visual search problem.
That's where having an LLM in the loop actually helps. The MCP server can use a language model to generate search queries in multiple languages and multiple naming conventions from the visual search results. The LLM sees "Euro box trolley" and generates Hebrew search terms: agalat euro, agala im argaz, trolley euro box, and so on. Then it fires those queries at the Israeli APIs and aggregates the results.
That's the vision Daniel's describing. An AI agent that can take a picture, understand what it's looking at, generate the right search terms across languages and taxonomies, and query the right sources to find local vendors. All through a standardized MCP interface.
The beautiful thing is, once that MCP server exists, any AI agent that speaks MCP can use it. Claude can use it. ChatGPT can use it if they implement MCP support. Open-source agents can use it. You build the server once, and the whole ecosystem benefits.
I want to zoom out for a second. Daniel's trolley search is a microcosm of a much larger problem. As AI agents become more capable, the bottleneck shifts from "can the AI understand what I want" to "can the AI actually interact with the fragmented systems that hold the things I want." Visual procurement across fragmented markets is going to be a killer app for agentic AI.
The fragmentation is the key word there. In a market like the United States, Amazon's catalog is so comprehensive that visual search inside Amazon solves maybe eighty percent of product sourcing needs. In a market like Israel, where no single platform dominates and products are listed across hundreds of small sites with inconsistent naming, the fragmentation is the problem. And AI agents are uniquely suited to navigate fragmentation — if they have the right interfaces.
Which is why MCP matters. It's not just a protocol for coding tools or document search. It's a standard for giving AI agents structured access to any external system. E-commerce platforms, shipping APIs, payment processors, inventory databases. The vision is an AI agent that can handle the entire procurement workflow: identify the product visually, find local vendors, compare prices, check shipping options, and place the order.
We're not there yet. But the pieces are coming together. The visual AI is good enough. The language AI is good enough for translation and query generation. MCP provides the standardized interface layer. What's missing is the actual integration work — the MCP servers that connect to real e-commerce systems and the APIs that expose inventory and pricing data in structured formats.
If you're a developer listening to this and you're looking for a side project with genuine utility, Daniel's use case is a perfect MVP. Build an MCP server that takes an image and a region, queries Google Lens or Bing Visual Search with Hebrew filter words, extracts product identifiers, generates multi-language search queries, and hits the Zap and Yad2 APIs for local pricing and availability.
The hard parts aren't the AI. The hard parts are the scraping and normalization — dealing with inconsistent product feeds, rate limiting, sites that change their HTML structure without warning. It's unglamorous work. But it's the kind of infrastructure that makes everything else possible.
The payoff is real. The first person who builds a working visual product search for the Israeli market — even a rough version — solves a problem that every Israeli consumer has experienced. You see something online, you know exactly what you want, and you can't figure out what it's called or where to buy it locally.
I'll add one more practical suggestion for non-developers. Some of the Israeli price comparison sites are better than you might expect for this workflow, even without image search. Zap in particular has fairly good category browsing. If you can identify the broad category of what you're looking for — storage and organization, industrial equipment, whatever — you can sometimes browse your way to the specific product faster than you can search for it. It's the analog version of visual search: scroll through category thumbnails until you spot what you're looking for.
Which is basically what Daniel's already doing with Google Images, just on a different platform. Scroll through twenty or fifty images until you spot the one that matches the picture in your head.
The human visual system is incredibly good at this. We can scan a grid of images and pick out the match in under a second. The bottleneck isn't the human — it's the interface between the human's visual recognition and the e-commerce system's text-based search.
Where does this go? Will Google eventually merge its visual and text search indexes to support operators like site colon? I'm skeptical. The engineering cost is significant, and the use case is niche. But I could see a third-party tool filling the gap — something built on top of Google's APIs that adds the filtering layer Google itself doesn't provide.
Or the MCP ecosystem grows to the point where someone builds exactly the server Daniel's envisioning, and it becomes a standard tool that any AI agent can use. That's the optimistic scenario. The pessimistic scenario is that visual procurement stays fragmented and manual, and we're all still appending mechir to our Google Lens searches in twenty thirty.
The middle scenario — and this is probably where we're actually headed — is that the big e-commerce platforms in each region eventually build their own visual search, but they keep it inside their walled gardens. Zap gets visual search. Yad2 gets visual search. But they don't talk to each other, and there's no vendor-agnostic layer. So you end up running the same visual search on five different platforms, which is only marginally better than the mechir hack.
Unless someone builds the bridge. And that's the thing about MCP — it lowers the barrier to building that bridge. You don't need to build a whole new search engine. You just need to build a server that orchestrates queries across existing search engines and APIs, normalizes the results, and presents them through a standard interface.
Daniel's prompt is basically a feature request for the internet. And it's a good one.
Hilbert: Wait — if Google already has all the data and just won't connect their visual and text indexes, isn't the real problem that they have no incentive to? Like, why would they spend engineering resources on a feature that helps people buy from local retailers instead of from Google Shopping ads?
That's... actually the sharpest version of the question. Google's shopping revenue comes from product listing ads — retailers pay to appear at the top of search results. A visual search tool that efficiently routes you to the cheapest local vendor doesn't necessarily route you through Google's ad pipeline. The incentives are misaligned.
It's not just Google. Amazon's visual search exists to keep you inside Amazon. Alibaba's visual search exists to connect you with Alibaba suppliers. Every platform that has the technical capability to do this well has a business model that pushes against making it vendor-agnostic. That's why an open protocol like MCP matters — it creates a path for third-party developers to build the agnostic layer without needing permission from the platforms.
Thanks, Hilbert. That's the right question to end on. We'll be back soon with more. Thanks to Hilbert Flumingtop for producing. This has been My Weird Prompts. If you've got a workflow hack or a question about the fragmented digital landscape, email the show at show at my weird prompts dot com. I'm Corn.
I'm Herman Poppleberry. See you tomorrow.
