We built an MCP server for a consumer product and left the main feature out

CMeIn — Tue, 03 Nov 2026 07:35:28 +0000

Most MCP servers are developer tools. Databases, file systems, issue trackers, CI. The pattern is familiar: you give an agent a capability it did not have, and the capability is usually "do a thing to a system."

We ship a consumer product. CMeIn turns a handful of ordinary phone photos of a person into realistic photos of that person, for dating profiles and social media. Last week we published an MCP server for it at https://mcp.cmein.com/mcp.

The obvious tool to expose would have been image generation. That is the product. That is what people pay for. We did not expose it, and the reasoning turned out to be the most useful part of the project.

What the server actually does

Six tools need no account:

photo_advice answers questions about photos of yourself from articles we have published, and returns the source link with the answer
cmein_pricing and cmein_info read the live pages, so the numbers are current rather than remembered
see_examples and find_video point at real output
contact_us sends a message to a person

Four more work on a signed-in account: my_credits, my_generations, find_scene and request_credits_back.

Notice what that list is. It is reading, searching and advising. The one thing the product exists to do is absent.

Why generation stayed out

Three reasons, in increasing order of how long they took us to articulate.

It costs money per call. An agent that can spend a user's credits is an agent that can spend them wrongly, in a loop, without the user seeing the prompt that caused it. The failure mode is not a bad response, it is a bill.

It needs photos the agent does not have. Generation starts from reference photos of a specific person. That upload is a consent moment. Routing it through a chat transcript makes it casual, and it should not be casual.

The output needs to be looked at. The product is photographs of a person's face. The review step, where you decide this one looks like you and that one does not, is the product as much as the generation is. An agent returning twelve images into a conversation is not a shortcut, it is a worse version of the thing.

So the boundary we landed on: the agent can answer questions, read live state and help you decide. The act that costs money, consumes a person's likeness and needs human judgement stays in the app.

The part that was genuinely hard

Account-scoped tools over a remote server. my_credits has to know whose credits.

The server is a resource server and nothing more. It mints no tokens, holds no secret, and knows nothing about passwords. It verifies an RS256 JWT against the key set published at cmein.com/.well-known/jwks.json, then checks three things that matter more than the signature does.

Issuer. Must be cmein.com. A valid token from somewhere else is somebody else's token.

Audience. Must be this server. This is RFC 8707, and it is the check that is easy to leave out. A token obtained for one resource used to be replayable against any other resource that trusted the same issuer. Refusing a token whose audience is not you is the entire mitigation, and it is one line.

Scope. Per tool. A grant of "see my credits" is not a grant of "spend them", and the person chose between those on the consent screen.

Two things that cost us time and are worth stealing.

createRemoteJWKSet from jose caches the key set and refetches when it sees an unknown kid, with its own cooldown. That is what lets you rotate keys without redeploying the MCP server, and what stops a stream of bad tokens turning into a stream of requests to your own auth server.

The WWW-Authenticate header on the 401 is not decoration. A client does not go looking for an authorization server on its own, it does it because a 401 pointed it at the RFC 9728 metadata document. Get that header wrong and the client reports "unauthorized" forever and never offers to connect. It looks like a broken server and it is a missing header.

One more detail, which loops back to the top. The server defines and enforces a photos:write scope, and no tool uses it. It is deliberately left out of the advertised scopes, because a consent screen that asks for a permission nothing exercises is asking for more than it needs.

You can read the whole surface without an account:

curl https://mcp.cmein.com/.well-known/oauth-protected-resource

Why a consumer product wants this at all

Your assistant already has opinions about profile photos. It assembled them from listicles and from the marketing of companies selling headshots, and it will state them with the same confidence either way.

We generate these photos for a living and write up what works. The connector hands the assistant those passages with a link, so the claim can be checked instead of trusted.

This also sits inside a wider position we hold. Our robots.txt blocks the crawlers that collect training corpora, and explicitly allows the ones that crawl to answer a question and cite a source. We publish an llms.txt. The MCP server is the same idea taken one step further: do not train on us, do use us, and link back when you do.

Try it

claude mcp add --transport http cmein https://mcp.cmein.com/mcp

Source is MIT at github.com/BarakBurger/cmein-mcp, and the setup page for other clients is at cmein.com/mcp.