How do I use resume-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@resume-mcp What projects has YongBo Yu worked on? Include links." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

resume-mcp

by YongBoYu1

Overview Schema Source Related Servers Discussions Admin

Python

Local

resume-mcp

Problem

Agents invent bios and career claims without citations. When you ask an MCP client who someone is or what they shipped, you often get fluent prose and no way to verify it.

Related MCP server: Resume MCP Server

Solution

A stdio MCP server that:

Fetches public machine-readable pages (resume.json, optionally llms.txt)
Caches them in-process (1-hour TTL)
Exposes tools that return structured answers with a top-level sources[] of public URLs on every response

No secrets, no LinkedIn scraping, no private app links — only HTTPS to the wired public corpus.

The default dataset is YongBo Yu’s public site (resume.json / llms.txt). The pattern is general: point the same fetch/cache/source-URL shape at any public machine-readable resume corpus.

Requirements

Python 3.11+
Network access to the wired public host (default: yongbo-yu.vercel.app)

Install

# from this repo
pip install -e .

# or with uv
uv pip install -e .

Dev / smoke tests:

pip install -e ".[dev]"
pytest -q

Run (stdio)

# module entrypoint
python -m resume_mcp

# console script (after install)
resume-mcp

# with uv
uv run python -m resume_mcp

The process speaks MCP over stdin/stdout. Do not pipe unrelated stdout into the same process.

Cursor `mcp.json`

Add a server entry (Cursor: Settings → MCP, or edit ~/.cursor/mcp.json / project .cursor/mcp.json):

{
  "mcpServers": {
    "resume-mcp": {
      "command": "python3",
      "args": ["-m", "resume_mcp"],
      "cwd": "/absolute/path/to/resume-mcp"
    }
  }
}

If the package is installed into a venv, point command at that interpreter (or use the resume-mcp console script).

With uv:

{
  "mcpServers": {
    "resume-mcp": {
      "command": "uv",
      "args": ["run", "python", "-m", "resume_mcp"],
      "cwd": "/absolute/path/to/resume-mcp"
    }
  }
}

After saving, reload MCP servers in Cursor. The tools below should appear as resume-mcp tools.

Tools

Tool	Purpose
`who_is_yongbo_yu`	Identity blurb + canonical public links from the wired corpus
`list_projects`	Projects from `resume.json` with highlights; KiloDock links to the project page
`get_resume_summary`	Condensed work / education / skills
`search_evidence`	Keyword search over cached resume + `llms.txt` (snippets + source URLs)

Every tool response is JSON text that includes a top-level sources array of public URLs.

Example prompts (in Cursor / Claude)

“Summarize the public resume this MCP is wired to, with sources.”
“List projects from the cached resume.json and cite the source URLs.”
“Search the wired public corpus for ‘LangGraph’ and quote snippets with URLs.”
“Use who_is_yongbo_yu for the identity blurb + links from this corpus (not invented bio text).”

Data sources (public only)

On startup (and on first tool use if needed), the server fetches:

https://yongbo-yu.vercel.app/resume.json
https://yongbo-yu.vercel.app/llms.txt (optional; search still works if it fails)

No API keys. No private WOD-APP or similar links.

Author

YongBo Yu (also Yong Yu) — Toronto, Canada · GitHub YongBoYu1

Site: https://yongbo-yu.vercel.app
KiloDock evidence: https://yongbo-yu.vercel.app/projects/kilodock
Machine-readable resume: https://yongbo-yu.vercel.app/resume.json

License

MIT — see LICENSE.

Available Tools

4 tools

get_resume_summaryA

Condensed work experience, education, and skills from public resume.json.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosure. It clearly states the data source is public resume.json and that the output is condensed rather than the full resume. This is sufficient behavioral context for a simple read-only retrieval tool; no hidden side effects or access concerns are indicated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise phrase with no filler or redundancy. It front-loads the core content type ('Condensed work experience, education, and skills') and identifies the source file efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read operation with an output schema, the description is largely complete: it names the source and the content categories returned. The only notable gap is the lack of explicit differentiation from sibling tools, which is a minor omission given the low complexity of this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and the schema is empty, so there are no parameter semantics to document. The high schema coverage makes parameter documentation unnecessary, and the description's reference to the source file adds useful context without needing to address parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly indicates the tool returns a condensed version of work experience, education, and skills from public resume.json. While it lacks an explicit verb like 'returns' or 'retrieves', the resource and scope are specific enough to identify its purpose. It is reasonably distinguishable from the sibling tools, which focus on biographical info, projects, and evidence search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus the sibling alternatives such as who_is_yongbo_yu or list_projects. The description implies a general resume-summary use case but does not state exclusions or direct agents toward a preferred tool for specific needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_projectsA

List projects from public resume.json with highlights; KiloDock links to its project page.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral disclosure burden. It communicates a read-only action ('List'), notes the data source is public, and reveals output details (highlights and KiloDock links). This is sufficient for a simple, side-effect-free listing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence front-loads the action ('List projects') then efficiently adds two pieces of useful context (source location and output highlights). There is no redundancy or filler, and the structure makes the tool easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, accepts no parameters, and has an output schema, so the description does not need to explain return values. It covers the core action, the data source, and distinctive output features, making it complete enough for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema already provides 100% coverage, so there are no parameter semantics for the description to clarify. The description does not need to add parameter-level detail, and the baseline for a no-parameter tool is satisfied.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') with a clear resource ('projects from public resume.json') and adds meaningful details ('highlights', 'KiloDock links'). It inherently distinguishes this from sibling tools like get_resume_summary and search_evidence, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: whenever the agent needs an overview of projects from the public resume. However, it does not explicitly reference alternatives such as get_resume_summary or search_evidence, nor does it state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_evidenceA

Keyword search over cached resume.json and llms.txt; returns snippets with source URLs.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavior disclosure. It usefully notes that the data is cached and that snippets with source URLs are returned, but it does not explain search semantics, limit handling, or behavior when no matches are found. It is adequate but not detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler: it front-loads the action and resource, then states the return format. Every phrase adds value and the structure is easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter search tool with an output schema, the description covers the core purpose and return shape. However, the absence of any parameter-level documentation and any guidance on when to use it relative to sibling tools leaves notable gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needs to compensate. It clarifies that the query is a keyword search, but the limit parameter is completely undocumented in both the schema and the description. The tool does not sufficiently bridge the parameter documentation gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action (keyword search), a specific resource (cached resume.json and llms.txt), and the result (snippets with source URLs). This makes it clearly distinguishable from sibling tools like list_projects and get_resume_summary, which do not perform keyword search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies it should be used when the agent needs to search over the cached evidence files, but it gives no explicit when-to-use or when-not-to-use guidance and does not mention alternatives. The context is reasonably clear, yet the agent must infer the placement among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

who_is_yongbo_yuA

Identity blurb and canonical public links for YongBo Yu (also Yong Yu).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the transparency burden. It discloses that the output contains an identity blurb and public links, which strongly implies a safe, read-only lookup, but it does not explicitly state the absence of side effects, access requirements, or any limitations. This is adequate but not deeply transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One economical sentence that communicates the subject, the alternate name, and the two content components (identity blurb and canonical public links) with zero filler. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with an output schema, this description is largely complete. The only gap is explicit guidance on when to prefer it over sibling tools, but the low complexity and presence of an output schema reduce the need for additional explanation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the baseline is 4. The description correctly makes no parameter claims and there is no parameter detail that could add value beyond what the schema already communicates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's purpose: providing an identity blurb and canonical public links for YongBo Yu (also Yong Yu). It names the specific resource and content type, which distinguishes it from resource-based siblings like list_projects and get_resume_summary, though it does not explicitly contrast with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus siblings such as get_resume_summary or search_evidence. The context is implied (identity lookup), but no exclusions, prerequisites, or alternative routing are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Sep 5, 2026
- First observedget_resume_summary
- First observedlist_projects
- First observedsearch_evidence
- First observedwho_is_yongbo_yu

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored 2026-09-05 18:15 across 4 tools

Disambiguation4/5

The tools are mostly distinct: one covers identity and links, one covers projects, one covers a career summary, and one is a search tool. The only slight overlap is between who_is_yongbo_yu and get_resume_summary since both describe the person, but their focus areas are clear enough to guide tool selection.

Naming Consistency4/5

Three tools follow a clean verb_noun snake_case pattern: list_projects, get_resume_summary, and search_evidence. who_is_yongbo_yu is the exception because it uses a question-style name instead of a verb_noun form, but the overall naming style remains readable and predictable.

Tool Count5/5

Four tools is well-scoped for a personal resume server. Each tool earns its place: identity, projects, resume summary, and evidence search cover the main consumption modes without redundancy or bloat.

Completeness5/5

The server covers the core needs of the resume domain: who the person is, what projects they have, a condensed career summary, and searchable evidence. Agents can answer typical questions about YongBo Yu without hitting obvious dead ends.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Refetch
io.github.lowenbjer
Fetch pages as markdown, search web and news, extract structured data. For AI agents.
Web Scraping Browser Automation Search
2
SteadyFetch A
io.github.carsonroell-debug
Reliable web fetching for AI agents with retry, circuit breaker, caching, and anti-bot bypass
Browser Automation Web Scraping Agent Orchestration
52
Brainiall Web A
com.brainiall
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Browser Automation Web Scraping
51
Sofya A
co.sofya
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
Search Browser Automation Web Scraping
42

Related MCP Servers

mundigital
Search
mundizzle
A
license
Not graded
quality
D
maintenance
Exposes a public, read-only professional profile with tools to search resume evidence, fetch curated links, and generate career briefs for LLM agents.
Updated 17 hours ago (2026-09-11 16:33 UTC)
MIT
Resume MCP Server
Search Knowledge & Memory
Adarshcharjan
A
license
Not graded
quality
C
maintenance
Exposes a structured professional resume as a set of AI-queryable tools, enabling AI clients like Claude Desktop to query summary, experience, skills, projects, and tailor resumes to job descriptions.
Updated 2 months ago (2026-07-14 05:41 UTC)
1
MIT
Portfolio MCP
RAG Systems Search
aim-t
F
license
Not graded
quality
C
maintenance
Enables AI assistants to query a person's CV and portfolio content via MCP tools and resources, returning grounded answers from local markdown data instead of relying on resume parsing.
Updated 18 days ago (2026-08-24 21:23 UTC)
-
personal-mcp
Search
adta7
F
license
Not graded
quality
B
maintenance
Enables agents to access a personal homepage's content graph through MCP tools, resources, and prompts, including retrieving profile, projects, resume, current status, searching content, and leaving messages.
Updated 13 days ago (2026-08-30 07:11 UTC)
-

resume-mcp

Problem

Solution

Requirements

Install

Run (stdio)

Cursor mcp.json

Tools

Example prompts (in Cursor / Claude)

Data sources (public only)

Author

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Cursor `mcp.json`