Viallo Now Has an MCP Server for Your Photo Library (2026)

What we built

Viallo's MCP server lets an AI assistant work with your Viallo photo library on your behalf. It runs at https://mcp.viallo.app/mcp, authenticates with OAuth 2.1 and PKCE, and exposes 17 named tools across four separate permission scopes: reading your profile, reading albums, writing to albums, and managing share links. By default it returns metadata rather than image files - album names, captions, tags, filenames, dates and place names. Handing over an actual photo happens through exactly one tool, view_photo, only when you ask for a specific photo, and every one of those calls is written to your activity log.

Viallo is a private photo sharing platform. Albums are private by default, photos are stored at full resolution on EU servers, the company does not train AI on them, and anyone you send a share link to opens it in a browser without downloading an app or making an account. The MCP server inherits all of that, which is the entire reason it was worth building rather than telling people to export a folder.

The full tool reference, the scope list and a set of example prompts live on the MCP page. This post is the other half: why it is shaped the way it is, and what it refuses to do.

What an MCP server actually is

MCP stands for Model Context Protocol. Anthropic published it as an open standard in November 2024, and the major assistants have adopted it since, which is why one endpoint works in several different apps.

The protocol is boring on purpose. A server advertises a list of named tools. The assistant reads that list, decides which one fits what you asked for, and calls it. The server answers that one call and stops. There is no background sync, no crawler indexing your library in advance, and no standing session waiting to be used. If you close the chat, nothing keeps running.

The thing to understand is that a tool list is a permission boundary as much as a feature list. An assistant connected over MCP can do the 17 things the server named and nothing else. That is a very different shape from handing an app blanket access to your camera roll, which is the direction most assistants have been pushing. It is also why the interesting engineering work here was deciding what not to put in the list.

Viallo was not first, and pretending otherwise would be silly

I wanted to open this post with "the first photo gallery with an MCP server". Then I went looking, and it is not true.

FindMe Photo, a gallery platform for wedding and event photographers, published a first-party MCP server on 24 April 2026 - the npm package findme-mcp, listed in the official MCP registry from that date, with 12 gallery tools. It is a real, live implementation with a hosted OAuth 2.1 and PKCE authorization server, not a proof of concept. PhotoPrism, the self-hosted gallery, shipped first-party MCP in its 23 May 2026 release, though that one exposes reference data - config keys and search filters - and cannot reach photos or albums at all, by design.

Beyond those two, there are community wrappers for Google Photos, Apple Photos, Immich, Flickr, Nextcloud and Synology Photos. They work, some of them well. None of them is first-party, which matters more than it sounds: a wrapper holds your credentials or an API key, and its permission model is whatever its author decided to implement.

So here is the honest version of the differentiator, and it is narrower than a land grab. When I checked on 7 August 2026, FindMe Photo's authorization server advertised exactly one scope - "scopes_supported": ["mcp"] at https://findme.photo/.well-known/oauth-authorization-server - which makes the grant all or nothing, while Viallo's asks for four separately and defaults to read-only. Anyone can check that URL in a browser and see for themselves, which is exactly why I am willing to write it down.

The second difference is who the tools are for. FindMe Photo's tools are photographer-side business operations - create_event, upload_photos_from_paths, get_event_analytics, get_event_qr - so it automates a studio delivering galleries to clients. Viallo's are aimed at one person's own photo library. If you are a wedding photographer running client galleries as a business, FindMe Photo is solving your problem and Viallo is not. Different products, and both things can be true.

That table is a snapshot taken on 7 August 2026, and this is a fast-moving corner of the industry. If you are reading it much later, check the vendors again rather than trusting a blog post. Google in particular has form here: it restricted its Photos API sharply in 2025, which is the main reason the community wrappers for it can do so little.

Decision one: metadata by default, pixels only on request

The obvious way to build this would have been to let the assistant pull images and reason over them. It is the more impressive demo by a mile. I did not build it that way, and the reasoning was short.

If the default response to "what is in my Sicily album" is a stack of image files, then every casual question ships your photos to a third party. The user did not ask for that, could not reasonably have predicted it, and in most cases would not notice it happened. A default that quietly does the most invasive available thing is a bad default even when the destination is trustworthy.

So sixteen of the seventeen tools return text. Album names, photo counts, capture dates, place names, captions, tags, filenames, storage usage, share link status. That covers most of what people actually ask, because most questions about a photo library are questions about organisation rather than content.

view_photo is the seventeenth, and it is the only path to actual pixels. It runs when you ask to see a specific photo, one photo per call, and it does not run to satisfy a browsing question. There is no pre-built index of your images sitting somewhere, because building one would have required exactly the analysis pass I decided not to run.

Decision two: four scopes instead of one

One scope is much easier to build. You issue a token, the token means "this app may use the API", and every tool checks the same thing. It is also how most of the prior art works.

The problem with one scope is that consent stops meaning anything. If ticking the box to let an assistant answer "how much storage am I using" also lets it delete an album, then the consent screen is a formality and everybody clicks through it. Splitting the grant is the only way the reading case and the destroying case can be separate decisions.

Write scopes are never granted by default. You have to tick them, which means a read-only connection is the path of least resistance rather than something you have to fight the UI for. Splitting share_links.manage out from albums.write was the one that took an argument to settle: creating a link is technically a write, but it is a write that puts photos in front of people who are not you, and that felt like it deserved its own checkbox.

Decision three: put the word permanent where the assistant will read it

This is the part I would want to know about if I were connecting somebody else's server.

Deletion through Viallo's MCP server is permanent. delete_album and remove_photo_from_album remove the files from storage, and there is no undelete - not through MCP, and not in the app either. There is no trash to fish anything back out of. That is how deleting in Viallo has always worked, and MCP did not get a softer version of it.

The design decision was about where to say so. Tool descriptions are not documentation for humans - they are the text the model reads before it decides what to call, and they are the only chance you get to influence how a tool is used. So the descriptions for both deletion tools state in bold that the operation is permanent and irreversible, and instruct the assistant to confirm with the user before calling them.

That is a hint, not a guarantee, and I want to be precise about the difference. A model can ignore an instruction in a tool description. What the instruction buys you is that the common case - an assistant cheerfully interpreting "tidy up my old albums" in one turn - now runs into a description that tells it to stop and ask. The guarantee lives somewhere else: in the fact that albums.write is a scope you had to deliberately grant, and a read-only connection genuinely cannot delete anything.

My honest advice for a first connection is to grant profile.read and albums.read, live with it for a week, and come back for the write scopes once you know what you actually want an assistant doing.

Decision four: log every photo read

A permission you cannot audit is a permission you have to take on faith. So every view_photo call is written to your activity log, along with the rest of the security activity on your account, and those entries are kept for 90 days.

The point is not that you will read the log every day. Nobody does. The point is that if you ever want to know whether an assistant looked at a specific photo, the answer exists and it is not "we would have to check with the vendor". It also makes the metadata-first default checkable rather than a claim you have to believe: if the server were quietly pulling images to answer browsing questions, the log would show it.

Revocation lives in the same place, at /settings/connected-apps. Revoking removes the tokens immediately, so the assistant loses access on its very next call. Access tokens also expire on their own, so an abandoned connection does not stay live forever. Deleting the server entry in your assistant is housekeeping on that side; revoking in Viallo is what actually cuts access.

What it deliberately cannot do

Viallo runs no image analysis on its servers - no object detection, no face recognition, no content search. That is a product decision that predates MCP, and the MCP server inherits it.

The consequence is concrete and worth stating plainly rather than burying: an assistant connected to Viallo cannot find "the photo with the red balloon". It can find "photos from Rome in June". search_photos works on captions, tags, filenames, dates and place names - text that you or your camera created. It has nothing else to work with, and no amount of rephrasing the question will change that.

Content search is genuinely useful, so why give it up? Because the only way to offer it is to run every photo you upload through a model that describes what is in it, and store those descriptions. That is a permanent, library-wide analysis pass on your entire photo history, performed whether or not you ever use the search box. It would also mean Viallo's servers held a written record of what is in your private photos, which is a much more sensitive artifact than the photos themselves in some ways - it is searchable, and it is small enough to hand over.

Google Photos took the other side of that trade, and it works: its content search is excellent, and if finding pictures by what is in them is the thing you need most, that is the honest recommendation. The trade is what it is. You get the search, and the analysis is the price.

A few other limits, for completeness:

• It is not end-to-end encrypted. Viallo can technically read your files, the same as any service that resizes and serves images. The MCP server is a narrower permission than uploading your camera roll to a chat, not a mathematical guarantee. Anyone telling you otherwise about any product with a web viewer is selling something.
• It cannot edit photos. No cropping, no filters, no retouching through MCP. It moves and organises files, it does not change them.
• It has no memory between calls. The transport is Streamable HTTP and the server is stateless. It answers the call it was given and forgets.
• Clients that only run local processes cannot reach it. This is a remote server. An assistant that only supports local stdio MCP servers will not connect at all.

How to connect it

MCP access is included on every Viallo plan, including the free one - 2 albums, 200 photos and 10 GB, no credit card. Plan limits apply to whatever the assistant does, so the plan comparison is worth a look if you are near those numbers. There is no API key to generate and no per-user URL to find: the endpoint is the same for everybody.

In Claude Code, it is one command:

Everywhere else the shape is the same:

1. Open your assistant's settings and add a remote MCP server. In Claude Desktop that is Connectors, in ChatGPT it is MCP servers on a paid plan, in Cursor it is Add remote server, and JetBrains IDEs use the same HTTP transport through their AI assistant settings.
2. Paste https://mcp.viallo.app/mcp as the URL. If the client asks for a transport, pick Streamable HTTP rather than the older SSE option.
3. Sign in to Viallo in the browser window that opens. Your client never sees your password, and you will not be asked to paste a token anywhere.
4. Read the consent screen and tick the scopes you want. Read-only is the default, and nothing pre-ticks the write scopes for you.
5. Ask something small to confirm it worked, such as "how many albums do I have in Viallo, and which is the biggest?"

Then check it from the other side. Open /settings/connected-apps and confirm the client is listed with the scopes you expected. If those do not match what you thought you approved, the settings page is right and your memory is wrong.

Where this goes next

The endpoint is live today and you can connect to it right now; the listing in the public MCP registry follows shortly, which only affects how easily people find it. The tool list will change as people use it, because the gap between what I thought people would ask and what they actually ask is always wider than expected. The scopes are the part I most want to be wrong about in a specific direction: if four turns out to be too coarse, splitting them further is easy, and going the other way would not be.

More clients will work as they adopt remote MCP over HTTP, and that requires nothing from Viallo. The endpoint does not change, and there is no per-client integration to write - which is the whole argument for building on an open standard rather than a private API.

The thing that is not on the roadmap is image analysis. Adding content search would make search_photos dramatically better and would undo the trade this entire post is about. If that is the feature you need, the right answer is a product that made the other choice deliberately, not Viallo bolting it on quietly.

Corrections

The prior-art section above is the version that survived fact-checking. If something in it is wrong - a vendor I missed, a scope list that has changed, a date that is off - I would rather fix it than defend it. The date on this post is when it was written and the facts were checked against live endpoints that day.

Frequently Asked Questions