I Shipped an MCP Server in 4 Hours for a Side Project That Has 690 Sessions a Week.

Here Is What I Built and Why.

I run a free browser-based passport photo tool that does about 690 sessions a week, growing. Most of the traffic comes from ChatGPT (65 percent) and from “direct” sources that are mostly hidden ChatGPT mobile referrer (20 percent). Google sends about 6 percent. The funny thing about that distribution is that it does not look like a 2010s SEO win. It looks like the start of a new pattern: AI engines are now the dominant traffic source for tools that solve crisp factual questions. Last week I shipped an MCP server for the same project. Total work: about four hours. Total expected immediate users: under a hundred. So why did I bother. This is the post about that decision. It might be useful for any indie operator deciding whether to invest in agent-readable surfaces right now or wait six months.

What MCP actually is

Model Context Protocol (MCP) is Anthropic’s open spec for connecting AI agents to external tools and data sources. It is a JSON-RPC 2.0 contract that defines three core methods: initialize, tools/list, and tools/call. Any agent that speaks MCP can connect to any MCP server and get a fresh tool surface that the model knows how to call. The clients that support it as of mid-2026: Claude Desktop, Cursor, Continue, the Anthropic SDK agent loop, and a growing list of custom frameworks. The user base is small (Claude Desktop has roughly one million users, Cursor about five hundred thousand, Continue under one hundred thousand) but the user is high-intent: someone who installed an AI desktop client to use it as a daily workflow tool. For a small project, the question is whether the MCP user base is worth the build effort. The answer for me turned out to be yes, but not for the reasons I expected.

The four reasons it was worth shipping

✔︎ One. The build cost was almost nothing. I already had a public REST API endpoint at /api/specs that returns country photo specifications as JSON. The MCP server reuses the same data, wrapped in JSON-RPC 2.0 with four tool definitions. Total new code: about 350 lines split across a route handler and a tools file. No new infrastructure, no new database, no new deployment target. The MCP server lives at the same domain, hosted on the same Vercel project, alongside the REST API and the website.

✔︎ Two. It is a citation surface.** MCP servers get listed in directories like glama.ai (30,000 plus servers indexed), awesome-mcp lists on GitHub, smithery.ai. Each listing is a backlink to my project’s docs page. The MCP page itself carries WebAPI Schema.org markup so AI engines that index API surfaces (Google AI Overview, Bing Copilot) recognize the endpoint as a registered API. None of these are big traffic individually. Collectively they signal authority to AI-search ranking systems.

✔︎ Three. It is a content piece on its own. This post you are reading exists because the MCP server exists. The MCP shipment is the narrative hook. Without it, I would not have written this essay, would not have a new technical artifact to point at on Dev.to, would not have a reason to ping the IH community. Content compounds on tangible shipments more than on opinions.

✔︎ Four. First-mover advantage in a narrow niche. A WebSearch for “passport photo MCP server” returned zero results before I shipped. After shipping, this project is the canonical answer for that query pattern. When MCP adoption grows, narrow niches with an existing answer get cited first.

What I actually built Four read-only tools:

• list_supported_countries enumerates the 100 plus countries with passport and visa photo specs.

• get_visa_photo_spec takes a country and optional document type, returns dimensions in mm and pixels, background color, full requirements list, and the URL where the user can generate the photo.

• get_portal_constraints takes a government portal id and returns file-size and format constraints (DS-160 240 KB cap, Saudi Enjaz 200 KB, India Sarathi 20–50 KB window, China COVA 40 KB to 1 MB JPEG, etc).

• get_photo_tool_url returns the deep link to the browser tool for a country. All read-only. The tools return metadata. They do not process photos. Photo handling stays in the browser tool itself, where the photo never touches a server (Brian Acton would approve). This read-only design was deliberate. The temptation with an MCP server is to expose write operations, because then agents can do more. But write operations on biometric data trigger GDPR Article 9, Illinois BIPA, India DPDP Act 2023, and a few state-level US biometric laws. The privacy exposure becomes meaningful as soon as the server can receive a photo. I designed around that by keeping the MCP layer metadata-only and leaving the image handling in the original browser-only pipeline. The agent can answer “what spec do I need” and “where do I go to generate it” without ever touching the user’s photo.

What the actual build looked like

Hour one. Designed the tools. Wrote out the four tool definitions on paper before opening an editor. The decisions were: which questions does an agent need to answer, what is the minimum input it needs from the user, what is the output shape that the model can format into a natural-language response without further processing. Get Elena Dev’s stories in your inbox Join Medium for free to get updates from this writer.

Hour two. Implemented lib/mcpTools.ts. Each tool is a function that takes a typed args object and returns a ToolResult with content: Array<{type: ‘text’, text: string}>. The TOOLS array exports the JSON Schema for each tool. The callTool dispatcher routes by name. No imports beyond the existing country data module.

Hour three. Implemented the JSON-RPC 2.0 endpoint at app/api/mcp/route.ts. Three methods: initialize returns server capabilities, tools/list returns the TOOLS array, tools/call dispatches to callTool. CORS open. No auth. Total endpoint code: about 140 lines including header comments. The GET handler returns server metadata for discovery clients that browse for MCP servers.

Hour four. Wrote the /developers/mcp docs page. Schema.org TechArticle plus WebAPI markup so AI search engines recognize it. Setup instructions for Claude Desktop, Cursor, and Continue. Direct JSON-RPC examples for custom agents. Design principles, FAQ, related resources. Done. Pushed to main, Vercel built it, the endpoint went live.

How I tested it

Three steps, ten minutes:

• curl -X POST https://idphotosnap.com/api/mcp -H “Content-Type: application/json” -d ‘{“jsonrpc”:”2.0",”id”:1,”method”:”initialize”,”params”:{}}’. Server returned protocol handshake. Good.

• curl -X POST with method: “tools/list”. Server returned the four tools with schemas. Good.

• Added the server to Claude Desktop config, restarted, asked “what size is a Schengen visa photo.” Claude called get_visa_photo_spec(country: “schengen”) and answered with the correct 35 by 45 mm light grey spec. Verified end to end. No edge cases. No retry logic needed. JSON-RPC 2.0 is a small protocol and the implementation is bounded.

What I will not do

I will not add write operations. The privacy positioning of the browser tool depends on the photo never reaching a server. If the MCP server starts accepting image data, the entire architectural story collapses. The MCP layer stays read-only. Users who want to generate a photo follow the URL the tool returns. I will not add authentication. The dataset is already MIT open data on GitHub, npm, PyPI, crates.io, Hugging Face. Authenticating access to a derivative API would just create friction without protecting anything that is not already public. I will not maintain protocol parity with every emerging agent framework. MCP is the Anthropic surface. OpenAI has Custom GPTs with OpenAPI Actions, which I support via a separate OpenAPI spec at the same domain. Both contracts wrap the same underlying data. If Google or Mistral ship a third protocol, I will consider it after a year of usage data.

Was four hours worth it

Three days in, the answer looks like yes. Three MCP awesome lists have accepted PRs adding our entry. Glama.ai indexed the server within twenty-four hours of submission. The /developers/mcp docs page got picked up by Bing within the same window. The Custom GPT version of the same data, published to the OpenAI registry the same week, is showing initial discovery traffic. None of this individually moves the traffic needle. But the cumulative pattern is that every agent-readable surface I add now is a placeholder for whatever the dominant agent framework looks like in twelve months. The cost to participate is one half-day per channel. The cost of being absent when adoption curves steepen is much harder to model.

What you can take from this

Build a JSON-RPC 2.0 endpoint that wraps your existing public data. Document it. Submit to three directories. Move on. Total cost is a workday. The downside if MCP fizzles is one wasted day. The upside if it does not is being in the early-mover set when AI agents become the default workflow client. If your data is not public yet, do that first. An open dataset is the actual moat. The MCP server is a thin layer on top of one. If your project is not a side project but a serious business, the calculation is the same just at different absolute numbers. The four hours scale to a sprint, and the upside is bigger because the user base is more valuable per agent install. Either way: the cheapest option is not zero. Zero ages badly.

#anthropic #MCP #startup #indiehacking

If you have ever built a passport photo tool, you know the most tedious part is not the face detection or the background segmentation. It is the country specifications. Every country has a slightly different size. Different background color requirements. Different file size caps on the online portal. A different head-height percentage. And the documentation is scattered across consulate websites in 12 languages.

I have been collecting and validating these specs for a year while building IDPhotoSnap, a free browser-only passport photo tool. Last week I published the dataset as an open repository at github.com/whitetirocket/passport-photo-specs - MIT licensed, JSON and TypeScript and Python bindings, 100 countries, 248 document formats.

This post is about why I did it, what is in it, and how you can use it in your own tool or research.

The problem with passport photo specs

Most photo tools claim to "support 200+ countries" or "900+ document types". When you check what that actually means, two patterns appear:

1. They have one default spec (35x45mm, white background, ICAO 9303) and apply it as a fallback for every country that has not been independently validated. So "200 countries" is really "30 countries with verified specs plus 170 countries getting the default".

2. They scrape specs from each other rather than from the original government source. When a country updates its requirements (which happens every few years), the updated spec takes 6-12 months to propagate through the ecosystem.

For a passport photo this matters. A wrong photo gets rejected at the consulate, and the application gets delayed by days or weeks. The user paid \(15 for the photo at a drugstore and another \)200 for the visa application, and the photo is the part that fails.

I wanted a single source of truth that I could verify against government sources directly.

What is in the dataset

Each country entry has documents (passport, visa, ID card, driving licence, residence permit, sometimes more). Each document has:

• widthMm, heightMm - print dimensions in mm

• widthPx, heightPx - pixel dimensions at the given DPI

• dpi - typically 300

• background - human-readable description ("Plain white", "Light grey")

• bgColor - hex code

• bgColorLabel - short label for UI

• requirements - bullet list of full requirements

Example for an Italian Schengen visa photo:

{
  "id": "italy-visa",
  "name": "Visa",
  "slug": "italy-visa-photo",
  "widthMm": 35,
  "heightMm": 45,
  "widthPx": 413,
  "heightPx": 531,
  "dpi": 300,
  "background": "Plain light grey",
  "bgColor": "#eeeeee",
  "bgColorLabel": "Light grey",
  "requirements": ["Plain light grey background", "Head 70-80% of frame", ...]
}

The repository ships:

• specs/specs.json - the full dataset (160 KB)

• specs/index.ts - TypeScript module with typed exports and lookup helpers

• specs/__init__.py - Python module with the same API

• scripts/validate.js - integrity check that runs on every commit

How to use it

TypeScript / JavaScript

import { findDocument, findCountry, countries } from 'passport-photo-specs'

const italyVisa = findDocument('italy-visa-photo')
// { widthMm: 35, heightMm: 45, widthPx: 413, heightPx: 531, dpi: 300,
//   background: 'Plain light grey', bgColor: '#eeeeee', ... }

const india = findCountry('india')
// All India documents: passport, visa, OCI, PAN card, PCC, driving licence, voter ID

Python

from passport_photo_specs import find_document, countries

italy_visa = find_document('italy-visa-photo')
print(f"Size: {italy_visa['widthMm']}x{italy_visa['heightMm']}mm")
print(f"Background: {italy_visa['background']}")

Plain JSON

If you are not on the JS or Python stack, load specs/specs.json in any language. The structure is documented in the README.

Notable specs that catch tool builders

These are commonly mis-specified across the ecosystem. If you are building something in this category, double-check yours:

• Chinese visa is 33x48mm, not 35x45 like Schengen and not square like US. It is the only major format with this aspect ratio.

• Chinese visa COVA portal requires file size 40 KB to 1 MB, JPG only, 354x472 px minimum.

• US DS-160 visa upload caps files at 240 KB. Square 600x600 minimum, 1200x1200 maximum.

• Indian Sarathi driving licence requires 20-50 KB - a window, not a max. Files under 20 KB and over 50 KB both fail silently.

• Indian PAN card is 25x35mm at 200x230 px maximum, 10-300 KB. Smaller than most other photos.

• UK passport accepts light grey background in addition to white. One of the few that does. Glasses not allowed since 2018.

• German Personalausweis has a May 2025 rule requiring digital-only photos via Buergeramt terminal or certified Fotograf for German citizens. This is separate from the German Schengen visa for foreign applicants, which still accepts standard 35x45mm digital photos.

These five entries are the dataset's biggest non-obvious wins. If your tool gets these right, applicants from those use cases will not have their photos rejected.

Validation methodology

For each country, I checked at least one of these sources:

• US Department of State (travel.state.gov)

• UK HM Passport Office (gov.uk/photos-for-passports)

• German Bundesdruckerei + Auswaertiges Amt

• Italian Polizia di Stato + Questura

• French ANTS (ants.gouv.fr)

• Spanish Ministerio de Asuntos Exteriores

• Canadian IRCC (Immigration, Refugees and Citizenship Canada)

• Australian Department of Foreign Affairs and Trade

• Indian Passport Seva Kendra (passportindia.gov.in)

• Indian RTO / Sarathi / Parivahan portals

• Chinese Ministry of Foreign Affairs (cova.cs.mfa.gov.cn)

• Japanese Ministry of Foreign Affairs (mofa.go.jp)

• Schengen visa code Annex 11 (ICAO 9303)

• EU Entry/Exit System (EES) specifications

• New Zealand DIA (passports.govt.nz)

• Brazilian Polícia Federal

• Mexican SRE (gob.mx)

Beyond top-20 countries, I follow the ICAO 9303 default unless an official source documents a country-specific deviation. I do not pad the dataset with synthetic country variants - if a country's photo spec is identical to ICAO 9303 default, it is marked as such rather than counted as "unique".

This means the 100 country count is honest. I could have called it 193 (all ICAO member states) and claimed the same coverage as competitors. I chose not to.

Why open source

Passport photo specs are public information from public government sources. There is no business reason to keep them proprietary, and the world is better served by having one canonical machine-readable dataset than by every photo tool re-researching them in silos.

There is also a research angle. If you are working on biometric privacy, immigration policy data, or AI training corpora that need to recognize valid versus invalid ID photos, the dataset is now available without a license fee or per-row pricing.

What I would like

If you find a spec that is wrong, open an issue with a link to the official government source. If you want to add a country I do not have, open a PR with the spec plus the citation.

I will not accept specs copied from other photo tool aggregators - we have enough of those. Government sources only.

Used in production

The dataset powers IDPhotoSnap, the free browser-only passport photo tool I mentioned at the start. The tool does face detection in face-api.js, background segmentation in BRIA RMBG-1.4 (ONNX), cropping and JPEG export in Canvas API. The full pipeline runs in WebAssembly - the photo never leaves the user's device. The country specs from this dataset are what drives the per-country crop dimensions, background color replacement, and file size targeting for online portal uploads.

If you build something else with the dataset, open a PR to add yourself to the "Used by" section in the README.

Repository links

• Repository: github.com/whitetirocket/passport-photo-specs

• Direct JSON: specs/specs.json

• Issues for spec corrections: github.com/whitetirocket/passport-photo-specs/issues

• Live demo: idphotosnap.com

MIT licensed. Attribution appreciated but not required.

#opensource, #webdev, #javascript, #typescript, #privacy

This post collects the key technical specifications for the major countries, in one place, in a format you can encode into a config file or validation function.

What every passport photo spec actually contains

There are five fields you need:

1. Output dimensions — physical size in millimeters and DPI for printing.
2. Face height percentage — the vertical fraction of the photo that should be occupied by the face, measured from chin to crown.
3. Vertical center — where the eyes (or the midpoint of the head) should sit vertically in the frame.
4. Background — required color, usually expressed as a target shade.
5. Expression — almost universally neutral, mouth closed.

Example: encoded specifications

Here is how the same specifications look as a JSON config:

Quick reference for the major countries

Where the specs come from

Most of these specifications trace back to ICAO 9303, the international standard for machine-readable travel documents. Countries deviate from ICAO in two main ways:

• Background color — Finland uses light grey, Indonesia historically used red, India uses white.
• Face size — the US allows a smaller face (50-69%) than most of Europe (70-80%).

For the long tail of countries not on this list, the most reliable sources are:

1. The countries embassy or consulate website
2. The ICAO 9303 specification as a default
3. Real-world rejection reports (StackExchange Travel, immigration forums)

Why this is harder than it should be

The technical work — cropping an image to a target size with face detection — is straightforward. The actual hard work is curating the spec database. Some countries publish clear PDFs. Others have vague text. Some require specific paper types or photo finishing that frankly cannot be enforced via software.

If you are building anything in this space, I would strongly recommend treating the spec database as your primary asset, not the image processing code. The processing code is a few hundred lines. The spec database is a year of slow collection.

Closing

If you spot an error in any of the specifications above, please leave a comment — these are notoriously hard to keep current as governments occasionally update their requirements.