DEV Community

Cover image for From PDF to MCP: Let AI Agents Query Your Resume On Demand
Leeson Wong
Leeson Wong

Posted on

From PDF to MCP: Let AI Agents Query Your Resume On Demand

#agents #career #mcp #showdev

The Problem

More and more companies are using AI for resume screening. HR hands the JD to an Agent, and the Agent matches candidates. But resumes are essentially PDFs (or web pages) — hard for AI to parse cleanly. Layout noise, scattered information, no structured querying.

So I asked myself: why not make my resume AI-native? Not "AI-friendly" marketing fluff, but something an AI Agent can actually connect to, query on demand, and run structured analysis against.

I built exactly that: a MCP Server for my resume. Visit the public page, and an AI Agent can auto-discover the endpoint, connect, search through experience, analyze job fit, and query skill proficiency.

The project is open source: github.com/Leeson-Wong/resume-maker

This article won't oversell the technical implementation (honestly, it's basic). Instead, let's talk about what the Resume + MCP combination actually means.

What is MCP?

MCP (Model Context Protocol) is an open protocol proposed by Anthropic that lets AI Agents connect to external data sources and tools in a standardized way. Think of it as "the API for the AI era" — except MCP is self-describing (tools come with name, description, inputSchema), so AI Agents can automatically understand how to use them without integration docs.

See It in Action

Here's what a recruiter's AI Agent can do after connecting:

Query: Search for big data related experience

search_resume({ query: "big data" })

→ Returns: relevant experience snippets + source modules + relevance scores
Enter fullscreen mode Exit fullscreen mode

Query: Is this candidate a fit for our role?

evaluate_fit({
  job_description: "\"Senior full-stack engineer, 5+ years, React/Node.js,"
                    big data platform experience, DevOps"
})

→ {
    score: 82,
    matched: ["react", "node", "big data", "devops", ...],
    missing: ["Kubernetes"],
    recommendation: "Strong match! ..."
  }
Enter fullscreen mode Exit fullscreen mode

Query: Give me a comprehensive assessment

get_career_summary({})

→ {
    seniority: "senior",
    totalYears: 6,
    domains: ["Big Data Cloud Services", "Cross-platform Development", "Indie Product Development"],
    coreStrengths: ["Multi-stack adaptability", "Independent product delivery", "AI protocol design"],
    topSkills: [{ name: "React", level: 4, yearsUsed: 5 }, ...]
  }
Enter fullscreen mode Exit fullscreen mode

All structured JSON — no PDF parsing, no web scraping. The AI Agent processes data programmatically.

The Key Insight Isn't Technical — It's Product Logic

The Resume Submission Flow Has Changed

Old flow: Send PDF → HR skims manually → Maybe passes to AI for辅助判断

New flow: Give HR a link + invite code → Their AI Agent connects via MCP → The Agent decides what to query and how to analyze

The difference: the initiative shifts from HR to the AI Agent. The Agent queries dynamically based on what it cares about, rather than passively reading a fixed-format document.

Invite Code = Reverse Filtering

This is my favorite part of the design.

When applying, you give HR a "link + invite code." HR needs to configure the invite code in their AI client before the Agent can access deep information.

The process itself is a filter: teams without sufficient AI literacy can't even get through it. If they can, it means they're already using AI Agents in their hiring process — likely a more modern team.

Plus, the invite code supports tracking — you can see exactly which tools the other party's Agent queried and when. Far more valuable than a "resume viewed" notification. You know what they actually care about.

Privacy Tiers

Public page and MCP responses expose different levels of information:

Tier What's visible Channel
Public Name, title, skill tags, work history / public page
MCP Query Project details, skill proficiency, fit analysis /mcp (invite code required)
Private Email, phone number Never exposed via MCP

Not everything should be AI-accessible. Contact info belongs in the human communication phase.

Three-Layer Discovery Mechanism

How does an AI Agent know your resume has an MCP service? This is the most critical design decision — discovery matters more than connection.

AI Agent visits https://your-domain.com
  ↓
Parses HTML, discovers <link rel="mcp" href="/mcp">
  ↓
Requests /.well-known/mcp for full metadata (tool list, auth method)
  ↓
Connects using invite code via Authorization header
  ↓
Starts querying
Enter fullscreen mode Exit fullscreen mode

Three layers of discovery, shallow to deep:

Layer 1: HTML Injection — Auto-injected into public page, zero maintenance cost

<link rel="mcp" href="/mcp">
<link rel="llms-txt" href="/llms.txt">
<script type="application/ld+json">
{ "@type": "Person", "name": "...", "knowsAbout": [...] }
</script>
Enter fullscreen mode Exit fullscreen mode

Layer 2: /.well-known/mcp — Standard well-known endpoint, machine-readable full MCP config

{
  "mcp": {
    "endpoint": "/mcp",
    "transport": "http",
    "auth": { "type": "bearer" },
    "tools": [...]
  }
}
Enter fullscreen mode Exit fullscreen mode

Layer 3: /llms.txt — Follows the llms.txt standard, Markdown-formatted AI-friendly description

All three layers are auto-generated server-side from the same resume.json. Update your resume, and all discovery info updates automatically.

Architecture

This is a self-hosted full-stack application, not SaaS. Single-user, deployed on your own server.

/            → Public page (visible to anyone, MCP discovery info injected)
/mcp         → MCP endpoint (invite code auth, for AI Agents)
/edit        → Resume editor (auth code protected, for yourself)
Enter fullscreen mode Exit fullscreen mode

Core principle: single source of truth — resume.json. Editor and MCP share the same data. MCP reads fresh data on every request — no cache staleness.

The tech stack is nothing to brag about: React 19 + Vite 7 + Tailwind 4 for the editor, vanilla Node.js HTTP for the server, MCP SDK for the protocol layer, Zod for data validation. Search uses a hand-rolled TF scorer + mixed Chinese/English tokenization — good enough for keyword matching, nowhere near real semantic search.

8 tools total:

Tool What it does
get_profile Public info, privacy fields never via MCP
get_experience Work history, filterable by keyword
get_projects Projects, filterable by tech stack
get_skills Skill list with proficiency and years
get_education Education background
search_resume Full-text search, TF relevance scoring
evaluate_fit Given a JD, outputs match score + missing skills
get_career_summary Career overview: seniority, domains, core strengths

Each tool supports format: 'text' | 'json' — text for humans, json for programs.

Engineering Decisions Worth Mentioning

Atomic writes instead of a database — Resume data is ~2KB. Even SQLite feels overkill. write-to-temp + rename is atomic, plus a write queue for concurrency safety.

Fresh MCP Server per request — Instead of a long-lived MCP Server created at startup, each request calls createMcpServer(currentResume). This guarantees the latest data — edits are immediately visible to MCP.

Zod schema validation — Validate on both read and write. The frontend editor validates too, but never trusting client input is basic hygiene.

stdio mode — Besides HTTP, supports start:stdio for direct Claude Desktop configuration. No server needed for local development.

Deployment 

# One-command Docker deployment
cp config.example.json config.json   # Set your authCode
docker compose up -d
Enter fullscreen mode Exit fullscreen mode

Or connect directly via Claude Desktop:

{
  "mcpServers": {
    "resume": {
      "command": "npx",
      "args": ["tsx", "server/stdio.ts"],
      "cwd": "/path/to/resume-maker"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Honest Take

The search and matching algorithms in this project are honestly mediocre. TF scoring is just keyword frequency counting, skill normalization is a lookup table, and evaluate_fit's matching logic is essentially string containment checking. These are far from "precisely understanding personal data."

But the interesting part isn't the implementation.

What's interesting is the new possibilities created by the Resume + MCP combination:

  1. Information access has changed — From "reading a fixed document" to "AI querying structured data on demand"
  2. Filtering logic has changed — Invite codes reverse-filter recruiters by their AI literacy
  3. Data ownership has changed — Data lives on your own server, you control who sees what

These three shifts have nothing to do with implementation complexity. They're innovations at the product form level.

MCP is still early — almost no recruiters are actually using AI Agents to connect to MCP endpoints. But the direction is right. As AI becomes more involved in hiring, resumes should evolve from "documents for humans" into "data sources for AI."

If you're also experimenting with MCP, or interested in "AI-native personal information presentation," let's connect.

Live Demo: http://47.97.101.194:965 (Invite code: qm8vvf — connect to the MCP endpoint to try all tools)

Project: github.com/Leeson-Wong/resume-maker

If you find it interesting, a Star would be appreciated.

Another Project: BrickLife

Quick shoutout to another thing I built — a simulation/management mini-game called "BrickLife"

Play: http://47.97.101.194 (Best experience on mobile)

This article was co-written with Claude Code + GLM-5.1.

Top comments (0)