Point any MCP client at ID.PHOTOS and your agent can turn an ordinary photograph into a compliant ID photo for more than a hundred national standards — passports, visas, residence cards — with the measurements checked and the verdict returned in the same call. No account, no sign-up, no API key.
There is nothing to sign up for and no key to paste.
{
"mcpServers": {
"id-photos": {
"type": "http",
"url": "https://id.photos/retail/mcp/server"
}
}
}
JSON-RPC 2.0 over MCP streamable HTTP. initialize and
tools/list answer immediately, so a client can look at the whole tool
list before it does anything at all.
| Tool | What it does | Cost |
|---|---|---|
list_standards | Every standard on offer, by country | Free |
get_photo_spec | One standard's size, resolution and rules — with a link to the published specification | Free |
process_photo | Photograph in, compliant photo and per-rule verdict out | Free |
process_photo_compare | Renders both the plain and the studio background, to be compared | Free |
select_rendition | Chooses which of the two the order delivers | Free |
get_session | The state of a photo: its checks, its rendition, whether it is paid | Free |
get_preview | The watermarked preview, enough to judge the photo | Free |
get_purchase_options | The price and the ways it can be paid | Free |
create_checkout | Opens a card payment and returns a link for the customer to pay on | Free |
register_payment_attempt · redeem_purchase | Reports a store transaction, and hands in the receipt | Free |
download_photo | The finished, unwatermarked image | Paid |
Everything up to delivery is free, however many times it runs — so an agent can render a photograph, show the customer what failed, and render it again without anything being owed. Downloading a photo that has been paid for, again, next year, is also free.
The head height, the eye line, the crop, the background, the print size — every standard defines them differently, and a photo that misses one is rejected at the counter. Each processed photo comes back with the measurements that were applied and a pass or fail against every rule, so your agent can tell the customer what is wrong before anyone pays.
get_photo_spec also returns the published specification page
for the standard. Hand that link to the customer rather than paraphrasing
the rules: it is the version that stays current when a country changes them.
process_photo returns a file_id. That id is what
identifies the work from then on — keep it, and treat it as a secret.
A dropped reply, a restart, the next morning: get_session reads
the photo and its payment state back, so the client is never the authority
on either.
There is no balance to top up and no bill at the end of the month. A payment buys the photo it was made against.
Two ways, and they differ in who can begin the payment. By card, the agent asks for a payment link and hands it to the customer. Through the App Store or Google Play, only the customer's own device can start it, and the agent's part is to report the result.
| By card | Through a store |
|---|---|
create_checkout returns a Stripe-hosted link. The customer pays there. |
register_payment_attempt announces the transaction id as soon as the store issues it — including when the purchase then fails, so a refund months later still finds the right photo. |
| Nothing to hand back: Stripe confirms to the server directly, so the agent simply waits. | redeem_purchase hands in the receipt. It is verified with the store that issued it, and the order is then paid. |
Either way, get_session is the authority on whether a photo is paid —
ask rather than remember, because a refund can arrive after a sale. More methods
are planned, PayPal and crypto among them, and each will say in the same field
whether an agent can begin it.
list_standards, or browse them at /photo-specs.
The instructions carry the full tool reference, a worked run, what every error means and the rules to follow — written to be read by an agent.