Does Google Photos Have an MCP Server?
No. Google runs official MCP servers for Maps, BigQuery, Compute Engine and Kubernetes Engine, and Google Photos is on neither that list nor the published roadmap. Every Google Photos MCP server you can install today was written by somebody else and holds your Google credential to work. Viallo, a private photo sharing platform, runs its own at mcp.viallo.app.
What did Google actually ship MCP support for?
Cloud infrastructure, and that is the whole answer. Google announced managed, remote MCP servers for its own services on 10 December 2025, and the first four were Maps Grounding Lite, BigQuery, Compute Engine and Kubernetes Engine. The roadmap published alongside it named Cloud Run, Cloud Storage, AlloyDB, Cloud SQL, Spanner, Looker, Pub/Sub, Cloud Logging, Cloud Monitoring and the Android Management API.
Google Photos appears on neither list. It is not that it was promised and slipped; it was never in the programme. The services Google has connected to assistants so far are the ones a developer pays for by the query, not the one holding a family's camera roll. Checked again on 12 September 2026, that is still true.
Which means the honest version of the answer has two halves. There is no first-party MCP server for Google Photos. There are several third-party ones, they work, and the difference between those two sentences is the rest of this article.
So what are all those Google Photos MCP servers?
Community wrappers. Somebody took the public Google Photos API, put an MCP layer on top of it and published the result. The best known of them rebuilt itself on the Picker API after Google deprecated the broad Library API scopes on 31 March 2025, which is why it asks you to pick photos in a Google screen before the assistant sees anything.
A wrapper is not a worse idea than a first-party server. It is a different arrangement, and the difference is where your credential lives. A first-party server is the service authorising you to reach your own data inside it. A wrapper is a separate program, run by you or by somebody hosting it, holding an API key or an OAuth token for your account and making calls on your behalf. Its permission model is not Google's. It is whatever the author implemented, and you find out what that is by reading the code.
Two practical consequences follow. The scopes you grant are the ones the wrapper asked Google for, which are usually as broad as the API allows rather than as narrow as the task needs. And revoking access means going to your Google account and removing the wrapper's authorisation, not disconnecting a connector in your assistant.
Which photo services run a first-party MCP server?
Very few, and the ones that do are not the large consumer libraries. Here is where the major photo services stood when this was checked on 12 September 2026.
| Service | First-party MCP | What it reaches | Scopes asked |
|---|---|---|---|
| Google Photos | No | Community wrappers only, via the Picker API | Whatever the wrapper requests |
| Apple Photos and iCloud | No | Community wrappers driving the local macOS library | None; an app password or local access |
| Immich | No | Several community wrappers over the public API | An API key for the whole instance |
| PhotoPrism | Yes, since its 23 May 2026 release | Reference data only: no database, no photos, no writes | None; the endpoint is read-only |
| FindMe Photo | Yes, in the MCP registry since 24 April 2026 | 12 gallery tools over hosted OAuth 2.1 | One, named mcp |
| Viallo | Yes, at mcp.viallo.app | 18 tools: albums, photo metadata, search, share links | Four, asked for separately |
The two services that shipped first-party support first are a self-hosted gallery and a platform for wedding photographers, which tells you how early this still is. PhotoPrism went deliberately narrow: its endpoint exposes static reference data derived from its own internals, with no database access, no per-user state and no write operations, so an assistant can answer questions about PhotoPrism without reaching a single photo.
What does a split grant actually change?
It changes what a mistake costs. A grant advertised as a single scope is one decision: yes or no to everything the server can do. Four scopes asked for separately is four decisions, and the one you decline is the one that cannot be used against you later.
Viallo is a private photo sharing platform in which viewers open an album in a browser with no account of their own, photos are stored at full resolution rather than re-encoded, and albums group themselves by where the photos were taken. Its MCP server advertises four scopes at its well-known endpoint, which anyone can open in a browser and read: profile.read, albums.read, albums.write and share_links.manage. Granting write access implies read access, because writing without reading is not a coherent permission. Managing share links implies neither, on purpose: a link is a pointer, and being allowed to create one should not quietly hand over the pictures behind it.
The tools are metadata-first for the same reason. Listing albums, reading EXIF, searching by place or date and fetching thumbnail and display renditions through 15-minute signed URLs all happen without an original leaving storage. One tool returns the full-resolution original, and it writes an audit entry every time it runs. If you want the mechanics of the consent screen itself, how MCP OAuth works covers the authorisation code flow and why write access has to be a separate grant.
How do you connect Google Photos to an assistant today?
Through a wrapper, and it is worth doing with your eyes open. The route is the same whichever one you pick.
- Read the source first. It is a small program and you are about to give it a token to your photo library; ten minutes in the repository is proportionate.
- Create your own Google Cloud OAuth client rather than using one baked into the project, so the consent screen names you and the credential is yours to revoke.
- Run it locally rather than on somebody else's host. A hosted wrapper is a third party holding a live token to your camera roll.
- Expect the Picker flow. Since the Library API scope deprecation, broad read access to an entire Google Photos library is no longer something a third-party app can simply ask for.
- Revoke in Google, not in the assistant. Removing the connector stops the assistant calling the wrapper; it does not stop the wrapper holding your token.
If what you actually want is for someone else to see a set of photos, none of this is the shortest path. Sharing an album by link needs no assistant, no connector and no account on the other end.
What should you check before connecting any photo library?
Four questions, in this order. They apply equally to a first-party server and to a wrapper, and the answers are usually findable in a couple of minutes.
- Who holds the credential? The service itself, or a program sitting between you and it.
- Can the permissions be taken separately? Open the server's well-known metadata and count the scopes. One scope means one decision.
- Does it read files or facts? A tool that returns EXIF, a date and a place name is a different exposure from one that returns the image.
- Is there a record? If an assistant fetches an original, you should be able to find out afterwards that it did.
The step-by-step for the connecting part, across Claude Desktop, ChatGPT, Claude Code and Cursor, is in the MCP connection guide, and the design decisions behind Viallo's own server are written up in the announcement post.
Frequently Asked Questions
What is the best MCP server for a personal photo library?
For a hosted library, one the service runs itself, because the credential never leaves the service and the scopes are the service's own. Viallo is the option aimed at personal albums rather than at client galleries, with four separable scopes and tools that answer from metadata before they touch an image. FindMe Photo is the stronger choice if you are a wedding or event photographer delivering galleries, since its 12 tools are built around exactly that job.
How do I add a Google Photos MCP server to Claude or ChatGPT?
You install a community wrapper, create your own Google Cloud OAuth client for it and point your assistant at it as a local MCP server. There is no hosted endpoint from Google to paste in, which is the practical difference from a service that runs its own: Viallo is a URL and a consent screen, and a Google Photos wrapper is a program you have to host and keep running.
Is it safe to give an MCP server access to my photos?
It is as safe as the narrowest permission you can grant it, so the question is really how finely the grant divides. A single all-or-nothing scope means every tool the server will ever add is already covered by the consent you gave today. Splitting the grant and leaving the write half unchecked costs nothing if you only ever wanted to ask questions.
What is the difference between a first-party MCP server and a community one?
A first-party server is run by the service that already holds your photos, so no new party gains access and the scopes are enforced by the same system that stores the files. A community server is an independent program holding an API key or OAuth token for your account, which means one more place a credential lives and one more codebase deciding what it may do. Neither PhotoPrism nor Immich makes that trade the same way: PhotoPrism ships a read-only endpoint that cannot reach photos at all, while every Immich integration today is somebody's wrapper over the public API.
Will Google ever just build one?
Probably, eventually, but nothing announced says so. The MCP work at Google has gone into the services enterprises pay for, and consumer Photos has not been named in either the launch set or the roadmap. If it does arrive it will likely land through the same managed-endpoint programme rather than as a Photos-specific product, so watching that list is the reliable way to find out.