job-mcp
job-mcp
FastMCP 서버(stdio 전송)이며 다음을 제공합니다:
리소스
cv://profile— LLM 클라이언트가 읽을 수 있는 사용자의 이력서(CV/resume)를 JSON으로 제공합니다.도구
send_email— Red Mail을 사용해 SMTP로 이메일을 전송합니다.
작업 흐름: MCP 클라이언트에게 채용 공고와 채용 담당자 이메일을 채팅으로 제공하면 → 클라이언트가 cv://profile을 읽고 → 맞춤 지원 이메일을 작성한 다음 → send_email을 호출해 전송합니다.
1. 설치
cd job-mcp
python -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e .Related MCP server: MCP Email Server
2. SMTP 자격 증명 설정
cp .env.example .env.env 파일에서 SMTP 호스트와 자격 증명을 수정하세요. Gmail의 경우 일반 로그인 비밀번호가 아닌 앱 비밀번호를 사용하고, 먼저 2단계 인증을 활성화하세요.
3. 이력서 작성
src/job_mcp/data/cv.json을 실제 정보(연락처, 기술, 경력, 학력, 프로젝트, 자격증)로 수정하세요. 리소스는 이 파일을 있는 그대로 읽습니다.
4. 서버를 단독 실행(기본 동작 확인)
python -m job_mcp.server서버는 stdin/stdout에서 MCP JSON-RPC 메시지를 기다리며 대기합니다(정상입니다 — MCP 클라이언트에 의해 실행되도록 만들어진 것이지, 대화형으로 사용되는 것이 아닙니다).
MCP 개발 인스펙터로도 검사할 수 있습니다:
mcp dev src/job_mcp/server.py5. MCP 클라이언트에 연결
stdio로 서버를 실행하는 클라이언트용 구성 예시(예: Claude Desktop의 claude_desktop_config.json):
{
"mcpServers": {
"job-mcp": {
"command": "/absolute/path/to/job-mcp/.venv/bin/python",
"args": ["-m", "job_mcp.server"],
"env": {
"SMTP_HOST": "smtp.gmail.com",
"SMTP_PORT": "587",
"SMTP_USERNAME": "you@gmail.com",
"SMTP_PASSWORD": "your-app-password",
"SMTP_SENDER_EMAIL": "you@gmail.com",
"SMTP_SENDER_NAME": "Your Name"
}
}
}
}(자격 증명은 .env 대신 여기의 env에 넣어도 됩니다. config.py가 어느 쪽이든 os.environ에서 읽으므로 둘 다 동작합니다.)
6. 사용하기
클라이언트에 다음과 같이 붙여넣으세요:
여기 채용 공고와 채용 담당자의 이메일이 있습니다. 내 이력서 리소스를 읽은 다음 맞춤 지원 이메일을 작성해서 보내 주세요.
채용 공고: 채용 담당자 이메일: hr@company.com
클라이언트는 cv://profile을 호출하고 두 가지 맥락을 모두 사용해 이메일을 작성한 다음 send_email(to=..., subject=..., body_html=..., body_text=...)을 호출해야 합니다.
참고 사항 / 나중에 보강할 내용
send_email에는 현재 서버 자체에 확인 단계가 내장되어 있지 않습니다. "보내기 전 검토" 가드레일을 클라이언트 측이 아닌 서버 측에서 적용하려면 두 단계 흐름을 추가하세요(예: 미리보기와 ID를 반환하는draft_email도구와 실제로 전송하는confirm_send도구).실수로 중복 전송되는 것을 방지하기 위해 전송된 이메일의 속도 제한 또는 로깅을 고려하세요.
cv.json은 리소스를 호출할 때마다 새로 읽으므로 서버를 재시작하지 않고도 수정할 수 있습니다.
Available Tools
1 toolsend_emailA
Send an email via SMTP using Red Mail. Use this to send the final, tailored job-application email to the recruiter/HR address. Provide a polished HTML body (and optionally a plain-text fallback).
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | ||
| to | Yes | ||
| bcc | No | ||
| subject | Yes | ||
| reply_to | No | ||
| body_html | Yes | ||
| body_text | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the behavioral disclosure burden. It transparently states that the tool sends an email via SMTP, which is an external side effect, and adds a practical requirement to provide polished HTML. It omits details like SMTP prerequisites or failure modes, but the core behavior is explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and every clause adds value: the action, the use case, and the body-format expectation. No redundant or generic phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no annotations, and no output schema, so the description must be reasonably self-contained. It covers the main action, the intended purpose, and the key body requirement. However, it leaves several parameter semantics and any error/response behavior unaddressed. The operation is simple and the names are fairly self-evident, so the gaps are moderate rather than severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It only explains body_html and optionally body_text; to, subject, cc, bcc, and reply_to are left undocumented. While the parameter names are conventional, the description does not add sufficient meaning for a zero-coverage schema, especially for required fields like 'to' and 'subject'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send an email via SMTP using Red Mail') and the specific use case ('final, tailored job-application email to the recruiter/HR address'). It is a precise verb+resource combination, with no ambiguity or tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to send the final, tailored job-application email to the recruiter/HR address', giving a clear when-to-use context. There are no sibling tools listed, so there is no opportunity to name alternatives or when-not scenarios, but the intended scenario is well defined.
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 tool update
v0.1.0- First observed
send_email
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity or misselection. The tool's purpose is clearly distinct simply because it is the only tool.
A single tool name cannot be inconsistent with itself. 'send_email' follows a clear verb_noun convention, and there are no other names to compare against.
One tool feels too thin for a server named 'job-mcp', which implies a broader job-application workflow. While sending an email is a concrete task, the server likely needs supporting tools for content generation or attachment handling to be useful.
The surface is severely limited: it only sends an email. Missing operations include email preview, attachment support, and any integration with job-application data, leaving obvious gaps for real-world workflows.
Maintenance
Related MCP Connectors
Auto-apply to jobs: matches your CV, tailors a fresh CV per posting, and applies for you.
Send transactional emails for AI agents via SMTP. Templates included.
Litjob AI job application assistant: job matches, tailored CVs and cover letters. You submit.
Tailor resumes, score ATS fit, find hiring leads, and send cold outreach, from your agent.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAutomates cold email outreach for job applications by parsing job postings, generating personalized emails using AI, and sending them or saving as drafts in Gmail with resume attachments.1-
- FlicenseNot gradedqualityDmaintenanceEnables LLMs to read, send, and manage emails via POP3 and SMTP with TLS support.6-
- AlicenseNot gradedqualityDmaintenanceEnables LLMs to access candidate information including resume, LinkedIn, GitHub, and contact via email.14 npm81MIT
- AlicenseAqualityAmaintenanceFree MCP and skills for remote and overseas job search across Himalayas, Jobicy, Arbeitnow and company ATS boards, with source links and eligibility checks. Optional local drafts, authorized email sending and reply tracking. Hosted MCP: https://mcp.worldrole.work/mcp — free anonymous access to 20 distinct jobs per network per UTC day, or 50 per free account; other request limits apply.914MIT