How I built a resume MCP in an hour

#ai #automation #mcp #productivity

How I built a resume MCP in an hour

I’ve been wanting to connect Rezi to Claude for a while. Not a chatbot, not a wrapper — an actual MCP server so Claude can read and write resumes that are actually ATS optimized. MCPs have been getting increasingly popular and it felt like the right time to just do it.

What I already had

Rezi’s backend is a Go monorepo. Resumes live in Firestore, auth runs through Firebase. I already had services reading and writing resume documents and a [standard data structure for resumes (https://github.com/rezi-io/resume-standard), so the data layer was basically done. The missing piece was an interface Claude (or any other agent) could talk to.

The setup

Go, mark3labs/mcp-go, deployed on Cloud Run behind our existing API gateway. The initial server exposed three tools: list_resumes, read_resume, and write_resume — enough to validate the whole thing worked.

The trickiest part wasn’t the tools — it was auth. MCP clients like Claude Code expect OAuth 2.1 with PKCE and a proper discovery flow (/.well-known/oauth-protected-resource, dynamic client registration, the whole thing).

That’s a few hundred lines of OAuth plumbing before you write a single tool.

How Claude built it

I started Claude in planning mode. Before writing a single line of code I made sure it fully understood the objective, how we handle auth, our resume data structure, and how we read and write documents to Firestore. Only once I was happy it had the full picture did I let it execute.

One decision worth calling out: should write_resume be a single tool, or should create and update be separate? I looked at how Claude and similar agents handle document writing internally — they tend to think of it as one operation regardless. A single shared tool with optional resume_id felt cleaner: no resume_id means create, provide one and it updates. We went with that, and the results were immediately impressive.

The “almost” part

During code review — before any testing — I noticed write_resume was replacing the entire Firestore document with whatever fields the agent passed. That would silently wipe things like which template the resume uses, its config, customizations, all of it. The agent only sends what it’s changing, not the full document.

The fix was straightforward: deep-merge the incoming data over the existing document so only the fields explicitly passed get updated, everything else is preserved. Caught it early, one fix, done.

End result

claude mcp add rezi --transport http https://api.rezi.ai/mcp

That’s it. The first time Claude needs a Rezi tool it opens a browser tab, you sign in, and from there it can list your resumes, read them, edit them, and create new ones — all in one conversation. Built and shipped in under an hour. Most of that was the OAuth flow. Once the plumbing was in place, the actual tools were almost trivial.

What came after

After testing it became obvious the next natural step was job search. If Claude can read your resume it should also be able to find jobs that match it. search_jobs and get_job_details came shortly after, and suddenly the workflow clicked into place end-to-end: read resume → search jobs → tailor resume to a specific role, all in one conversation.