CMeIn 發佈 MCP 伺服器，沒有開放照片生成

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 MCP server. my_credits has to know whose credits. Most MCP examples are local processes with a token in an env var, which does not survive contact with a consumer product where the user is a person with a login, not a developer with a config file.

If you are building something similar, that is where your time will go. Not the tool definitions.

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.

I am interested in where other people drew this line. If you have shipped an MCP server for something consumer facing, what did you deliberately not expose?

`