How do I use resume-tailor-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-tailor-mcp Tailor my resume to this software engineer job posting" 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-tailor-mcp

by mr-martinsosa

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

resume-tailor-mcp

An MCP server that tailors a resume to a job posting. It exposes three tools to any MCP client (Claude Desktop, an IDE, the MCP Inspector) and supports two backends: the Anthropic API with an API key, or key-less operation using MCP sampling to borrow the host's model.

What MCP is

MCP (Model Context Protocol) is a standard for giving an LLM access to tools and data. A host (such as Claude Desktop) embeds the model, a server such as this one exposes capabilities, and the two communicate over JSON-RPC. The server has no model of its own and only answers requests.

Related MCP server: resume-mcp

Tools

A ping health check, plus three tools:

Tool	Input	Returns
`tailor_resume`	resume + job description	fit score, matched/missing keywords, rewrites of existing bullets, gaps, a cover note
`score_fit`	resume + job description	a 1-5 fit score with a recommendation, plus a separate ghost-job legitimacy read
`extract_keywords`	job description	the ATS keywords a posting wants, split into must-have and nice-to-have

The system prompt constrains the model to rephrase and re-emphasize existing resume content and to flag genuine gaps rather than fabricate experience.

Backends

The backend is selected with the TAILOR_MODE environment variable:

api (default): calls the Anthropic API with an ANTHROPIC_API_KEY, using structured outputs so the model is constrained to the response schema.
sampling: holds no key. It requests a completion from the host via MCP sampling (createMessage) and validates the returned text against the same schema. Requires a host that supports sampling, such as Claude Desktop.

The tools are identical across both backends. See Design notes for the tradeoff.

Requirements

Node 20 or newer.
The api backend requires an ANTHROPIC_API_KEY.
The sampling backend requires a host that supports MCP sampling.

Installation

git clone https://github.com/mr-martinsosa/resume-tailor-mcp.git
cd resume-tailor-mcp
npm install
npm run build     # compile TypeScript to dist/

Usage

Run the test suite (uses injected fakes, so no API key, network, or cost):

npm test

Inspect the live server with the MCP Inspector:

npm run inspect

Claude Desktop

After npm run build, add the following to claude_desktop_config.json, using an absolute path:

{
  "mcpServers": {
    "resume-tailor": {
      "command": "node",
      "args": ["/absolute/path/to/resume-tailor-mcp/dist/server.js"],
      "env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
    }
  }
}

For key-less operation, omit ANTHROPIC_API_KEY and set the mode instead:

"env": { "TAILOR_MODE": "sampling" }

Project layout

src/
  server.ts            boots the stdio server; selects the backend by TAILOR_MODE
  schema.ts            zod schemas and prompts (one schema per tool)
  tools/               one file per tool: registration and provider call
  llm/
    anthropic.ts       direct-API backend (structured outputs)
    sampling.ts        key-less backend (MCP sampling + client-side validation)
test/                  smoke, tool, and sampling tests, all run without a key
study-materials/       notes on MCP and the design

Design notes

Structured outputs: the API backend uses messages.parse with zodOutputFormat, so the model is constrained to the schema and the SDK returns a validated, typed object with no manual parsing step.
Single schema per tool: each tool's zod schema serves as the Anthropic output format, the MCP outputSchema, the prompt instruction in sampling mode, the client-side validator, and the TypeScript type.
Provider seam: tools call an injected function (TailorFn, ScoreFn, ExtractFn) rather than the LLM directly. Tests inject fakes (so no key is needed), and the sampling backend was added without changing any tool.
Backend tradeoff: the direct-API backend enforces the schema server-side but requires a key; the sampling backend is key-less but gives up server-side enforcement, so it validates the returned text itself.

License

MIT. See LICENSE.

Available Tools

4 tools

extract_keywordsExtract keywordsA

Extract the keywords an applicant-tracking system would key on from a job posting, grouped into must-have and nice-to-have.

ParametersJSON Schema

Name	Required	Description	Default
`job_description`	Yes	The full text of the job posting.

Output Schema

ParametersJSON Schema

Name	Required	Description
`must_have`	Yes	Required skills/technologies/keywords the posting emphasizes.
`nice_to_have`	Yes	Preferred-but-not-required keywords.

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must cover behavioral traits. It states the extraction and grouping behavior, but does not disclose potential limitations (e.g., accuracy, length constraints) or describe the output format beyond grouping. The presence of an output schema partially compensates.

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, well-structured sentence that conveys all necessary information without redundancy. It is front-loaded and concise.

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?

Given the tool's simplicity (1 parameter) and the existence of an output schema, the description is adequate. It could mention the output format or usage context more explicitly, but overall it covers the core functionality well.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description adds context about the output (grouping), but does not add any additional semantics for the input parameter beyond what the schema provides.

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 clearly states the action (extract), the resource (keywords from a job posting), and the specific grouping into must-have and nice-to-have. It distinguishes itself from sibling tools like score_fit and tailor_resume by focusing on keyword extraction rather than scoring or tailoring.

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

Usage Guidelines4/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 (when keywords are needed from a job posting with grouping), but does not explicitly state when not to use it or provide alternatives. However, the context is clear enough for an AI agent to infer appropriate usage.

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

pingPingA

Health check. Returns 'pong', echoing an optional message.

ParametersJSON Schema

Name	Required	Description	Default
`message`	No	Optional text to echo back

TDQS

A4.5/5.0

Behavior5/5

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

No annotations are provided, so the description fully carries the burden. It discloses the exact return value ('pong') and the effect of the optional message parameter (echoing it back). No hidden behavior or side effects are implied.

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 consists of a single sentence that front-loads the core purpose ('Health check') and immediately follows with the output behavior. No extraneous words; every phrase earns its place.

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?

Given the tool's simplicity (one optional parameter, no output schema), the description provides all necessary information: it explains what the tool does, what it returns, and the role of the parameter. No gaps remain.

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

Parameters3/5

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

Schema description coverage is 100% for the single optional 'message' parameter. The description adds 'echoing an optional message', which reiterates the schema's 'Optional text to echo back' without adding new semantic detail. Baseline score of 3 is appropriate.

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 clearly states 'Health check' and specifies that it returns 'pong', echoing an optional message. This precisely defines its purpose and distinguishes it from sibling tools like extract_keywords, score_fit, and tailor_resume.

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

Usage Guidelines4/5

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

The description explicitly states 'Health check', which implies when to use the tool (to verify service availability). While it doesn't mention when not to use it or list alternatives, the context is sufficient for a simple tool with clear intent.

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

score_fitScore fitA

Score how well a resume fits a job posting on a 1-5 scale (with a recommendation), and separately judge whether the posting looks like a real, active opening. Use it to triage which roles deserve a full tailor.

ParametersJSON Schema

Name	Required	Description	Default
`resume`	Yes	The candidate's full resume text (Markdown or plain text).
`job_description`	Yes	The full text of the job posting to tailor toward.

Output Schema

ParametersJSON Schema

Name	Required	Description
`archetype`	Yes	Closest role archetype, e.g. 'Full-stack + AI' or 'LLMOps'.
`rationale`	Yes	A short paragraph justifying the score and the legitimacy tier.
`dimensions`	Yes	Per-dimension 1-5 scores.
`global_score`	Yes	Weighted overall 1-5 fit score.
`recommendation`	Yes	Action threshold derived from the score.
`legitimacy_tier`	Yes	Ghost-job legitimacy read — separate from the fit score.

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided, so the description bears full burden. It discloses the outputs (score, recommendation, real/active judgment) but does not explicitly state behavioral aspects like idempotency, side effects, or required permissions. For a scoring tool, this is adequate but not comprehensive.

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 two sentences: the first explains core functionality, the second provides usage guidance. Every sentence adds value with no redundancy or filler.

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?

Given that an output schema exists (even if not shown), the description sufficiently explains the two main outputs. For a simple scoring tool, this covers all essential aspects for an agent to use it correctly in context.

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

Parameters3/5

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

Input schema has 100% coverage with descriptions for both parameters (resume and job_description). The description adds no extra meaning beyond the schema, so baseline score of 3 applies.

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 clearly states the tool scores resume-job fit on a 1-5 scale with a recommendation and separately judges posting authenticity. It explicitly contrasts with sibling tools by noting it's for triage before full tailoring.

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

Usage Guidelines4/5

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

The description explicitly says to use it for triaging roles that deserve a full tailor, providing clear context. It does not explicitly mention when not to use it or name alternative tools, but the usage is well implied.

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

tailor_resumeTailor resumeA

Tailor a resume to a specific job description without fabricating experience. Returns a fit score, matched/missing keywords, truthful rewrites of existing bullets, honest gaps, and a short cover note.

ParametersJSON Schema

Name	Required	Description	Default
`resume`	Yes	The candidate's full resume text (Markdown or plain text).
`job_description`	Yes	The full text of the job posting to tailor toward.

Output Schema

ParametersJSON Schema

Name	Required	Description
`verdict`	Yes	One sentence: is this worth applying to and why.
`cover_note`	Yes	A 3-4 sentence outreach note referencing the specific role.
`honest_gaps`	Yes	Real gaps the candidate should be ready to address in a screen.
`match_score`	Yes	Honest 0-100 fit estimate.
`matched_keywords`	Yes	Keywords from the posting the resume already supports.
`missing_keywords`	Yes	Keywords the posting wants that the resume does NOT support.
`tailored_bullets`	Yes	Rewrites of EXISTING bullets only — never fabricated.

TDQS

A4.1/5.0

Behavior4/5

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

No annotations exist, so the description bears full burden. It explicitly states key behavioral traits: 'without fabricating experience', 'truthful rewrites', 'honest gaps'. This assures the agent of ethical, non-destructive behavior. Could mention that it does not modify the original resume, but the return format implies no side effects.

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?

Single sentence efficiently encapsulates purpose, ethical stance, and output list. Every phrase earns its place; no redundant words. Front-loaded with main action and constraint.

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?

Given 2 parameters with full schema coverage, an output schema (so return values already documented), and moderate complexity, the description sufficiently covers the tool's role and behavior. It leaves no critical gaps for selection and invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema for `resume` and `job_description` parameters, but it contextualizes their role in the tailoring process. No additional format or constraint details are needed.

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?

Description uses specific verb 'Tailor' and resource 'resume to a specific job description', clearly stating the output components (fit score, matched/missing keywords, rewrites, gaps, cover note). It distinguishes from siblings like extract_keywords and score_fit by combining tailoring, scoring, and rewriting.

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 usage when a resume and job description are available and one wants to tailor without fabrication, but it does not explicitly state when to use this tool over siblings like extract_keywords or score_fit, nor provide when-not or prerequisite conditions.

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.0Jul 12, 2026
- First observedextract_keywords
- First observedping
- First observedscore_fit
- First observedtailor_resume

Deploy Server

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

TDQS

A4.2/5.0

Scored 2026-07-12 23:10 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: extract_keywords parses job postings, ping is a health check, score_fit evaluates fit, and tailor_resume modifies the resume. No overlap in functionality.

Naming Consistency4/5

Three tools follow the verb_noun pattern (extract_keywords, score_fit, tailor_resume), but 'ping' is a plain verb. This minor inconsistency is acceptable for a health check endpoint.

Tool Count5/5

Four tools is a well-scoped set for a dedicated resume tailoring service. Each tool earns its place without being excessive or insufficient.

Completeness4/5

The core workflow (extract keywords, score fit, tailor) is covered, but there is no tool to manage or upload the base resume, assuming it's provided externally. Minor gap, but the set is functional.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Vitex — AI Resume GeneratorOAuth
io.github.ChanMeng666
Generate tailored, ATS-optimized resume PDFs and cover letters from a job description, over MCP.
AI & Machine Learning Workplace & Productivity
2
nextrole A
io.github.hyperdrift-io
A job-search companion: tailor your CV to a role, score fit, fix ATS issues. Also via MCP.
Search Workplace & Productivity
52
Caplia AOAuth
io.github.Caplia-Tech
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
Finance AI & Machine Learning
2
CloudresumeOAuth
io.cloudresume
Resume builder with native MCP — create and edit resumes from your AI assistant.
Developer Tools Workplace & Productivity App Automation
2

Related MCP Servers

Resume MCP Server
AI & Machine Learning Data Visualization
26Ritika
F
license
Not graded
quality
C
maintenance
An MCP server that compares your resume against a job description using semantic similarity and keyword matching, and generates a visual skill-gap chart.
Updated 3 months ago (2026-06-21 16:32 UTC)
-
resume-mcp
Workplace & Productivity Project Management
ddavidgao
F
license
Not graded
quality
D
maintenance
MCP server for maintaining a professional profile database and generating tailored, ATS-optimized resumes for specific job postings.
Updated 5 months ago (2026-04-06 02:06 UTC)
1
-
mcp-server-cv-modify
RAG Systems AI & Machine Learning Web Scraping
ikrigel
F
license
A
quality
D
maintenance
MCP server that intelligently modifies CVs based on job descriptions using keyword extraction and strategic enhancement.
Updated 7 months ago (2026-01-28 15:10 UTC)
3
3
-
resume-editor-mcp
AI & Machine Learning Workplace & Productivity
gaowenting0303
F
license
Not graded
quality
C
maintenance
MCP server for AI-native resume optimization, providing tools to load JD, analyze match, rewrite sections, and assemble customized resumes.
Updated 3 months ago (2026-06-25 01:46 UTC)
1
-