Your AI agent can now build an album with you

A browser agent driving a normal website is doing computer vision on a user interface designed for humans. It reads a screenshot, guesses which pixels are the Create album button, clicks, waits, screenshots again, and tries to work out whether it worked.

Every one of those steps can fail in a way the agent cannot see. It clicks a disabled button and reads the unchanged page as success. It misses a validation error rendered in a colour it cannot interpret. A dropdown renders differently on a narrow window and the whole plan derails. Worse, it has no idea what an action costs — nothing on screen tells it that this particular button spends your credits.

None of that is the agent being bad at its job. It is being asked to reverse-engineer intent from a picture, when the site could simply have told it.

Sustain implements WebMCP, an emerging web standard for exactly this. When an agent is active in your browser, our pages register a set of tools it can call directly. Each one has a name, a typed input, and a description written for a machine that has never seen our UI.

Ten tools ship today, and they map to the actual journey of making an album rather than to our REST endpoints:

• ask_site — answers questions from our own published content (pricing, printing, privacy, the guides you are reading now) and returns the source pages, so the agent can cite rather than invent.

• create_album and album_status — start an album and check how it is going.

• request_photos and import_google_photos — two ways to get photos in, neither of which sends a single image through the conversation. More on that below.

• quick_place and build_album — lay the photos out for free, or run the full AI build.

• list_albums, get_credits, start_checkout — find your albums, read your balance, buy more credits.

You are signed in to Sustain with an agent running in your browser. You say: “Make me an album from my Italy trip.” What happens next is not a sequence of clicks:

Throughout, you are both looking at the same page. The agent is not operating a hidden copy of the site somewhere — it is working in your tab, and every result appears in front of you.

This is the part that is easy to get wrong, and we got it wrong first. The obvious design is a tool that takes the photos as an argument — the agent hands us the images, we store them. It works for one small picture and collapses for everything else, because a tool call is text: the image has to be encoded into the conversation, and a single full-resolution photo can exceed an entire AI context window. Splitting it into more calls makes it worse, since every call stays in the transcript and is re-sent on each later turn.

So the tools do not move photos at all. request_photos issues an upload ticket — a short-lived, single-purpose credential for one album — and whoever actually holds the pictures sends them straight to us:

• The photos are on your phone. The ticket comes with a link. You open it, pick your photos, done. Hundreds of them, none passing through the AI.

• You have given the agent access to your files. Then it uploads them itself, directly, from disk to Sustain. The agent never reads the images into the conversation — it just uses the ticket.

• Your library is in Google Photos. import_google_photos starts a picker session, you choose in Google’s own window, and Sustain downloads them server-side — up to a thousand, again with nothing going through the agent.

The ticket expires in 24 hours, is scoped to one album, and still respects your plan’s photo and storage limits. It is the same mechanism behind the QR-code upload we already ship, which is a good sign: the right design for an agent turned out to be the one we had already built for humans.

The Google Photos route is where the agent genuinely joins in the selecting: once you have picked, it can drop the videos and skip the screenshots before importing. We are careful about how far to take that claim — Google gives us a filename and a file type and nothing about what is in a picture, so an agent that told you it had removed the blurry ones would be making it up.

This is the part people ask about first, and the answer is better than it usually is for agent integrations.

The tools run inside your browser tab, in the page you already signed in to. When one calls our API, your browser attaches the same secure session cookie it always does. There is no token to issue, no OAuth screen, no API key pasted into a chat, and no credential the agent can read, store, or leak. It can act only as the person already signed in to that tab, and only for as long as that session lasts.

That also sets the ceiling on what a misbehaving agent could do: exactly what you could do yourself in that tab, and nothing more. The server checks every permission independently, the same as when you click.

Some things should not happen because software decided they should. We left them out on purpose:

• It cannot place a print order. That spends real money and needs a shipping address. You do that yourself.

• It cannot take a payment. start_checkout creates a checkout session and hands you the link — you pay on the provider’s own page. The tools never touch card details.

• It cannot help itself to your files. A web page cannot read your disk — browsers forbid it, and that is a feature. An agent can only upload what you have deliberately given it access to, and only using a ticket you asked it to create.

• It cannot cancel your subscription or delete an album.

One thing it can do is spend credits: build_album runs the paid AI build in a single call, and the cost depends on how many photos survive de-duplication. We treat credits the way any metered API treats tokens — the tool says plainly that it spends them, and if your balance is short it comes back with the exact shortfall so the agent can tell you and offer to top up rather than failing silently.

There are two routes now, and they are at very different stages.

Connecting a desktop assistant works today, with nothing to switch on — see Connecting Claude or ChatGPT at the end of this post. It needs a Basic or Pro plan.

The in-browser route is still opt-in. WebMCP is a genuinely new standard and we would rather tell you where it stands than imply more than is true: Chrome has shipped it from version 149 but has not switched it on by default. In Chrome 149 or later, open chrome://flags/#enable-webmcp-testing, set the WebMCP for testing flag to Enabled, and click Relaunch. Chrome restarts with your tabs intact. Then pick an agent.

Google publishes a Model Context Tool Inspector extension for exactly this — installed from the Chrome Web Store like any other, with public source. It is the shortest path from curiosity to a finished album, and today it is the route we would actually point you at.

They can now — this is the part of the post that changed.

When we first published this, the honest answer was not yet. Desktop assistants speak MCP but not WebMCP: they talk to servers over the network and have no page in front of them, so a website’s in-browser tools are invisible to them. We said the route we actually wanted was a hosted MCP server, so an agent with no browser could act on your account through a proper OAuth grant you could review and revoke, and that it was on our list.

It is built. https://mcp.sustain-app.com/mcp is a real MCP server, and Claude, ChatGPT or any other MCP client can connect to it directly — no extension, no flag, no bridge. You sign in through Sustain’s own consent screen, tick what the agent may do, and disconnect it whenever you like.

We still would not point you at a community “bridge” extension. They are generally loaded unpacked — unsigned, outside the Chrome Web Store’s review — and they can see and act on every tab you are signed into. Now there is no reason to: the supported route exists.

Once the inspector is installed and Sustain is open in front of it, this is the prompt to start with. Paste it and watch the calls go by.

It deliberately stops before spending anything: it asks for a free layout and for a description of what a paid build would do, so your first run cannot surprise you with a credit charge.

There is a version of the next few years where people stop visiting websites and start asking an assistant to deal with them. In that world, a site that only speaks in pixels is one an agent gets wrong, gives up on, or skips in favour of one it can actually operate.

Being agent-ready is not a badge. It is the difference between an assistant that can genuinely make you a photo album and one that clicks around, spends your credits by accident, and hands back something you did not ask for. We would rather be legible to the machines that are increasingly doing the asking.

It also keeps us honest about our own product. Writing a tool description forces you to say exactly what an action does and what it costs, in a sentence, with no interface to hide behind. Several of ours got clearer in the writing.

This is the route that needs no flags and no extensions. It is part of the Basic and Pro plans.

In Claude, open Settings → Connectors → Add custom connector and paste https://mcp.sustain-app.com/mcp. Claude will find the rest on its own — it reads what the server publishes and sets up the sign-in for you.

You will land on a Sustain page asking what this app may do, on your account. Four boxes: see your albums, create and edit albums, spend your credits on AI runs, and see your credit balance and plans. Tick fewer than it asked for if you want to — the agent gets what you grant, not what it requested. An agent without spend your credits cannot even see the tool that starts a paid run; it is not offered and refused, it is simply not there.

Then ask for what you want. “Make me an album from my Italy trip” is enough: the agent creates the album, hands you an upload link for your phone, waits for the photos, and offers to run the AI build — telling you it costs credits before it does.

You can take it back at any time from Settings → Connected apps. Disconnecting takes effect on the agent’s very next call, not whenever its access happens to expire, because we issue those tokens ourselves rather than handing out something we cannot revoke.

A granted permission is not a blank cheque, and the failure we actually expect is not an attacker — it is an agent looping on a call it misread as failed.

So there are limits that hold whatever the agent was granted: a cap on how many calls a minute a connection may make, and a cap on how many paid runs it may start in a day. Hit either and the agent is told plainly, and you can still do the same thing yourself on the website.

Every call an agent makes is recorded too — which tool, whether it worked, and what it was about. Not what you typed: the arguments are fingerprinted rather than stored, because the question that table answers is what has this agent been doing, not what did you say to it.