Case Study
Managing a shop's catalogue by conversation, without replacing the till
TillBridge is an MCP server that exposes a retail product catalogue as nine conversational tools. Staff at Frutería Valenciana scan a barcode, describe what they want in plain language, and an AI assistant drafts the entry, applies the correct IVA rate and queues the approved product for the shop's existing point-of-sale terminal. The till stays the system of record. TillBridge only feeds it.
The problem with feeding a legacy TPV
Frutería Valenciana runs a traditional TPV as its system of record. The terminal sells reliably, which is the job it was designed for. Adding products to it is another matter. A new line means working through a fixed sequence of screens, typing a name into a narrow field, choosing a category, entering a price and selecting the tax rate by hand.
Nothing looks the product up for you, so the name has to be invented on the spot and typed without error. The work happens at the till, which is also where customers queue, so catalogue maintenance drifts towards closing time. Names drift with it. The same product can enter twice under two spellings, and nobody notices until a shelf label disagrees with a receipt.
Some lines arrive with a printed EAN barcode. Loose fresh produce arrives with none, and needs an internal code and a shelf label instead. Both kinds have to exist in the till before anyone can sell them, and a supplier delivery means repeating that slow sequence dozens of times over.
Replacing a working till costs money and carries real risk for a shop this size. The practical question was never how to buy a better system. It was how to make the existing one easier to feed.
How TillBridge works
TillBridge treats the TPV as the system of record and places a system of engagement in front of it. Catalogue work happens in a separate database on a server I manage, where editing is cheap and mistakes are easy to undo. An MCP server wraps that database in a defined set of tools, and Claude connects to those tools through an ordinary chat window.
A staff member scans an EAN and says the shop has started selling it. The assistant searches the catalogue, finds nothing, then queries Open Food Facts for a suggested name and photograph. That suggestion is a starting point rather than an answer, because manufacturers name products differently from the way a shop labels a shelf. The assistant rewrites the name in the house style, picks a category already in use, applies the correct IVA rate and presents the finished entry.
Only after a person confirms does anything get written. The assistant creates the product, queues it for the till by its internal identifier, then checks the queue accepted it.
The nine tools
The tool surface is deliberately narrow. Nine operations cover the whole job, and each does one thing with named arguments. Four only read, three write to the catalogue, one raises alerts and one dispatches to the till.
buscar_producto. Searches by name, category or exact EAN, which is what prevents duplicates.buscar_en_off. Looks an EAN up in Open Food Facts for a suggested name and photograph.crear_producto. Creates a single product.crear_productos_lote. Creates or updates many products in one batch, which makes a supplier delivery tractable.actualizar_producto. Updates only the fields supplied, so a price change never disturbs a name or a category.recientes. Lists the most recently added products, so staff can review their own work.alertas_almacen. Flags products expiring within three days or already out of stock.enviar_a_tpv. Queues a product for the till by internal identifier, with an EAN required.estado_tpv. Reports the sync queue status for a given set of products.
What the set leaves out matters as much as what it includes. It exposes no delete operation, so nothing disappears from the catalogue through conversation. It exposes no raw query either, so the assistant cannot reach past the defined operations into the database itself.
Design decisions
Augment the legacy system, never replace it. Migration projects fail small retailers more often than they help them, because the till is the one piece of equipment a shop cannot afford to lose on a Saturday morning. TillBridge holds no sales data, no payment logic and no responsibility for the day's takings. If the server goes down, the shop keeps trading exactly as before.
Human confirmation before every write. Staff read a short summary, in their own language, of precisely what will change. That keeps the model in the role it handles well, which is drafting and checking, and leaves the decision with the person who knows the shop. A misunderstanding surfaces as a rejected proposal rather than a wrong price on a shelf.
UUID as identity, EAN as a second key. Barcodes go missing on loose produce, manufacturers reuse them over time, and they occasionally arrive mistyped. A stable internal identifier turns a barcode correction into a field update instead of a duplicate product.
Error messages in the language of the shop. A product still showing as pendiente after about two minutes almost always means the till is switched off, not that the data is wrong. Teaching staff that one rule did more good than any retry logic, because the catalogue entry is already safe and re-queuing costs nothing.
Products, not people. The catalogue holds stock rather than customers, so no personal data sits on the server and the data protection surface stays small. Sales and payment information never leaves the TPV.
Common questions
What is TillBridge?
TillBridge is an MCP server that turns a retail product catalogue into a set of conversational tools. Shop staff scan a barcode and describe what they want in plain language, and an AI assistant drafts the entry, applies the right tax rate and queues the approved product for the shop's existing till.
Can an AI assistant update a legacy point-of-sale system?
Yes, through a staging layer rather than direct access. TillBridge keeps the catalogue in a separate database, then pushes approved products to the terminal through a sync queue. The terminal stays the system of record for sales, so the integration adds capability without putting trading at risk.
What is an MCP server and why use one in retail?
Model Context Protocol is an open standard for exposing data and actions to AI assistants as named tools. In retail it lets an assistant search and edit a catalogue through nine defined operations instead of raw database access, which keeps the failure modes small and easy to explain to a shop owner.
Does the AI change prices without approval?
No. Every write waits for a human. The assistant may search freely and propose anything, but creating a product, changing a price and sending an entry to the till each require a member of staff to confirm a plain-language summary of exactly what will change.
How does the system handle Spanish IVA rates?
The assistant applies 4 per cent to basic foodstuffs such as bread, milk, eggs, fruit, vegetables and flour, and 10 per cent to most processed, packaged, frozen and prepared goods. The rate appears in the proposal before confirmation, so a person checks it rather than discovering it later.
What happens if the till is offline when a product is sent?
The product stays in the sync queue as pendiente. If it is still pending after about two minutes, the usual cause is a terminal that is switched off rather than bad data. Staff check the till, then re-queue the product. The catalogue entry is already safe on the server.
Can this pattern work with other POS systems?
Yes. The architecture separates the catalogue from the till, so the parts that change between retailers are the vocabulary, the tax rules and the sync target. A pharmacy, a hardware shop or a wholesaler with a legacy ERP can use the same shape of solution.
Limitations and what comes next
The flow runs in one direction. TillBridge feeds the TPV, and edits made directly on the terminal do not travel back, so two records of the same product can drift apart. Open Food Facts covers international brands well and local Spanish lines unevenly, and when a barcode returns nothing the assistant falls back to asking for a name. Non-barcoded produce stays partly manual for the same reason, because no public database knows what the loose apples on your own shelf should be called.
The roadmap follows from those gaps. A WhatsApp channel through n8n and the Evolution API would move the conversation to an app staff already keep open. A voice and vision shelf assistant on an ESP32-P4 device would move it into the aisle, so someone can hold up a product and ask about it instead of walking back to a screen. Camera-based identification of loose produce would bring fresh fruit and vegetables onto the same fast path as packaged goods. Multi-store rollout is the commercial step, and the architecture already separates catalogue from till, so that becomes a question of tenancy and access control rather than new concepts.