Skip to main content
Glama
deenesjakoruzh
M-Sohaib-Siddiqui

resume-analyzer-mcp

by M-Sohaib-Siddiqui
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Resume Analyzer MCP 서버 📄🎯

AI 모델(Claude, Antigravity, Cursor)이 이력서를 분석하고, 객관적인 ATS(지원자 추적 시스템) 점수를 산출하며, 직무에 맞춘 이력서 개선안을 제안할 수 있도록 하는 오픈소스 Model Context Protocol (MCP) 서버입니다. Python(mcp SDK)으로 구축되었습니다.

🌟 주요 기능

🛠️ 도구

  1. analyze_resume(resume_text: str, target_job_title: str)

    • 구조적 완성도(요약, 경력, 학력, 기술, 프로젝트)를 평가합니다.

    • 영향력 있는 동사와 정량적 성과 지표(예: %, $, 배수)를 감지합니다.

    • 직무에 부합하는 핵심 기술을 식별합니다.

  2. suggest_improvements(resume_text: str, target_job_title: str)

    • 실행 가능하고 직무에 맞춘 불릿 포인트 개선안을 생성합니다.

    • 약하거나 수동적인 표현을 찾아 영향력 있는 동사로의 업그레이드를 권장합니다.

    • Google 'XYZ 공식'(Y로 측정된 X 달성, Z를 통해)을 적용합니다.

  3. calculate_ats_score(resume_text: str, job_description: str)

    • 이력서 텍스트를 대상 직무 설명과 비교합니다.

    • 정확한 ATS 일치율 점수(예: ATS 점수: 82%)를 계산합니다.

    • 키워드 일치율, 일치 용어, 중요한 누락 키워드를 생성합니다.

📚 리소스

  • resume://sample-template: 업계 표준 마크다운 이력서 템플릿.

  • rules://ats-guidelines: ATS 파싱 표준 및 불릿 포인트 채점 기준.

💬 프롬프트

  • full_resume_review: 종합 경력 검토 워크플로우를 실행하기 위한 사전 구축 프롬프트 템플릿.

Related MCP server: resume-tailor-mcp

💬 사용자 및 클라이언트를 위한 예시 프롬프트

1. 이력서 구조 분석 (analyze_resume)

"백엔드 엔지니어 포지션에 대해 아래 제 이력서를 검토하는 데 analyze_resume를 사용해 주시겠어요?"

# John Smith
Skills: Python, PostgreSQL, Docker, REST APIs
Experience: Software Engineer at Acme Inc. Developed backend APIs in Python and reduced database latency by 30%.
Education: B.S. in Computer Science

2. ATS 일치 점수 (calculate_ats_score)

"이 채용 공고에 대한 제 일치율을 확인하려고 calculate_ats_score를 실행해 주세요."

  • 이력서: Skills: Python, SQL, PostgreSQL, Docker

  • 채용 공고: Python, SQL, PostgreSQL, Redis, Docker, Kubernetes, CI/CD에 능숙한 시니어 백엔드 엔지니어를 찾습니다.

3. 실행 가능한 이력서 추천 (suggest_improvements)

"데이터 엔지니어 역할에 맞게 제 이력서에 suggest_improvements를 실행해 주시겠어요?"

Worked on data pipelines. Helped with SQL queries and handled daily reports.

4. 리소스 가져오기

"표준 이력서 양식을 보여주기 위해 resume://sample-template 리소스를 읽어 주시겠어요?"

🚀 빠른 시작 및 로컬 설정

1. 사전 요구 사항

  • Python 3.10 이상

  • Git

2. 설치

프로젝트 작업 공간을 복제하거나 이동합니다:

cd D:\dev\resume-analyzer-mcp

# Create and activate virtual environment
python -m venv .venv
# On Windows PowerShell:
.\.venv\Scripts\Activate.ps1
# On macOS/Linux:
source .venv/bin/activate

# Install dependencies
pip install -e .

🧪 로컬 검증 테스트 실행

stdio를 통해 MCP 서버를 프로그래밍 방식으로 시작하고 도구 호출, 리소스 및 프롬프트를 확인하는 자동화된 통합 테스트 스위트를 실행합니다:

python test_client.py

🔌 MCP 클라이언트에 연결

Claude Desktop 구성

claude_desktop_config.json에 서버 구성을 추가합니다:

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "resume-analyzer": {
      "command": "D:\\dev\\resume-analyzer-mcp\\.venv\\Scripts\\python.exe",
      "args": [
        "D:\\dev\\resume-analyzer-mcp\\server.py"
      ]
    }
  }
}

Antigravity / Gemini 구성

작업 공간의 .agents/mcp_config.json 또는 ~/.gemini/config/mcp_config.json에 추가합니다:

{
  "mcpServers": {
    "resume-analyzer": {
      "command": "python",
      "args": ["D:/dev/resume-analyzer-mcp/server.py"]
    }
  }
}

☁️ Smithery MCP 마켓플레이스에 배포

Smithery를 사용하면 개발자가 MCP 서버를 자동으로 검색, 호스팅, 설치할 수 있습니다.

1단계: 저장소를 GitHub에 푸시

git add .
git commit -m "Add example prompts and documentation"
git remote add origin https://github.com/your-username/resume-analyzer-mcp.git
git push -u origin main

2단계: Smithery에 게시

  1. smithery.ai를 방문하여 GitHub로 로그인합니다.

  2. Submit Server를 클릭하고 resume-analyzer-mcp 저장소를 선택합니다.

  3. Smithery가 smithery.yaml 및 Dockerfile에서 컨테이너를 자동으로 빌드하고 대화형 샘플 프롬프트와 함께 README.md를 렌더링합니다!

📄 라이선스

MIT 라이선스. 상업적 및 비상업적 용도로 무료입니다.

Available Tools

3 tools
analyze_resumeB

Analyzes the structure, completeness, impact metrics, action verbs, and skills of a resume.

ParametersJSON Schema
NameRequiredDescriptionDefault
resume_textYes
target_job_titleNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/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 carry the burden. It states the tool analyzes multiple qualitative and quantitative aspects, implying it is a read-only analytical operation. However, it doesn't disclose any side effects, dependencies, or the format of the output, leaving some behavioral ambiguity.

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

Conciseness4/5

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

The description is succinct—a single sentence that front-loads the core purpose. It is appropriately concise and avoids redundant wording.

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?

Given the tool's moderate complexity, the description covers key analysis dimensions but lacks details on output and optional parameter usage. An output schema exists, so return format details are less critical, but the incomplete parameter guidance lowers the score.

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 must compensate for parameter meaning. It doesn't elaborate on resume_text format or clarify the role of target_job_title even though it's optional. This is a significant gap for a tool with only two 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 identifies the action (analyzes) and the resource (resume), and lists several specific aspects: structure, completeness, impact metrics, action verbs, and skills. This distinguishes it well from siblings like suggest_improvements and calculate_ats_score, though it doesn't explicitly differentiate them.

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 analysis is needed, listing key analysis dimensions. However, it doesn't explicitly state when to use this tool versus alternatives, such as when to use calculate_ats_score for scoring or suggest_improvements for changes.

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

calculate_ats_scoreA

Calculates ATS match percentage score (0-100%) by comparing resume text against a job description.

ParametersJSON Schema
NameRequiredDescriptionDefault
resume_textYes
job_descriptionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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 transparency burden. It discloses the output range (0-100%), the input types (resume text and job description), and the comparison action. This makes the tool's behavior clear, though it does not detail any underlying algorithm or edge cases, which is acceptable for a simple calculation 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?

The description is a single sentence, front-loaded with the main purpose, and contains no fluff. Every word adds value, making it appropriately concise and well-structured.

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?

For a simple tool with two string inputs and a numeric output, the description is complete. It explains the core functionality, and since an output schema exists, return values need not be elaborated. The tool's simplicity and clear purpose mean no additional behavioral context is required.

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 0% description coverage, so the description must add meaning. It does this by explicitly stating that resume text is compared against a job description, clarifying the role of each parameter. Although parameter names are self-explanatory, the description reinforces their relationship and intended use.

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 calculates an ATS match percentage score (0-100%) by comparing resume text against a job description. This specific verb and resource set it apart from sibling tools like analyze_resume and suggest_improvements, which likely focus on other aspects.

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 contexts: use when you need a numeric ATS match score. However, it does not explicitly mention when to use this tool over siblings or when not to use it. The guidance is implied rather than explicit.

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

suggest_improvementsB

Generates actionable recommendations to optimize bullet points, action verbs, and formatting.

ParametersJSON Schema
NameRequiredDescriptionDefault
resume_textYes
target_job_titleNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/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 disclosing behavior. It accurately states the tool generates recommendations without side effects, but it does not elaborate on the nature of the output, whether it reads or writes data, or any limitations. This is adequate for a simple suggestion tool but lacks depth, missing an opportunity to clarify that it is non-destructive.

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 front-loads the main action and clearly states the domain. Every word adds value, and it is appropriately sized for the tool's simplicity, achieving maximum conciseness.

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?

Given the tool's low complexity (2 parameters, 1 optional) and the presence of an output schema (which likely documents return values), the description is mostly sufficient but leaves out any mention of the target_job_title parameter. It does not explain when to use this tool, but the core purpose is clear. It barely meets the minimum viable standard for completeness.

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 coverage is 0%, so the description must compensate. It adds meaningful detail about resume_text (referencing bullet points, action verbs, formatting), but completely ignores the optional target_job_title parameter. This leaves a significant gap in understanding how the second parameter behaves, earning a below-average score.

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 uses a specific verb ('Generates') and resource ('actionable recommendations to optimize bullet points, action verbs, and formatting'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like analyze_resume or calculate_ats_score, though the focus on improvement recommendations is distinct enough to infer a difference.

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 offers no guidance on when to use this tool versus its siblings. There is no mention of alternatives, prerequisites, or typical scenarios. The only hint is the verb 'Generates', which implies a recommendation role, but no explicit usage context is provided.

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.

  1. 3 tool updatesv0.1.0
    • First observedanalyze_resume
    • First observedcalculate_ats_score
    • First observedsuggest_improvements
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 3 tools

Disambiguation4/5

The three tools have distinct purposes: analyzing resume quality, suggesting improvements, and calculating ATS match. However, 'analyze_resume' and 'suggest_improvements' could overlap slightly since both deal with resume content quality, though their outputs differ (analysis vs. recommendations).

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: analyze_resume, suggest_improvements, calculate_ats_score. The pattern is predictable and clear.

Tool Count3/5

Three tools is on the leaner side for a resume analyzer, potentially leaving users wanting more functions like resume parsing or formatting help. However, the count is still within a reasonable range for a focused tool that handles core resume analysis tasks.

Completeness3/5

The core workflow covers analyzing a resume, suggesting improvements, and calculating ATS score. However, there's a notable gap: no tool to update or create a resume, and the tools likely rely on passing full resume text each time, making the workflow feel incomplete.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers