Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@job-search-mcp Search for job openings at Kakao"
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.
채용 플랫폼(잡코리아, 사람인)에서 회사명으로 채용공고를 검색하는 MCP 서버입니다.
원티드(Wanted)는 왜 없나요? 원티드는 CDN 레벨에서 자동화 접근을 차단하고 있으며, robots.txt 자체도 403으로 응답합니다.
회사명을 입력하면 각 플랫폼에서 채용공고를 수집하여 다음 정보를 반환합니다:
항목 | 잡코리아 | 사람인 |
공고 제목 | ✅ | ✅ |
회사명 | ✅ | ✅ |
경력 | ✅ | ✅ |
학력 | ✅ | ✅ |
지역 | △ (코드) | ✅ |
마감일 | ✅ | ✅ |
공고 URL | ✅ | ✅ |
Related MCP server: job-source-mcp
search_jobs채용 플랫폼에서 회사명으로 채용공고를 검색합니다.
파라미터 | 타입 | 필수 | 기본값 | 설명 |
| string | ✅ | - | 검색할 회사명 |
| string | - |
| 검색할 플랫폼 ( |
| number | - |
| 페이지 번호 |
search_jobs_bulk여러 회사의 채용공고를 한 번에 병렬로 검색합니다. search_jobs를 반복 호출하는 것보다 훨씬 빠릅니다.
내부적으로 동시성 제한(10개 배치)을 적용하여, 수십~수백 개 회사를 넘겨도 서버가 자동으로 분할 처리합니다. LLM이 여러 번 나눠 호출할 필요 없이 1회 호출로 전체 결과를 받을 수 있습니다.
결과는 임시 디렉토리에 텍스트 파일로 저장되며, 요약과 파일 경로만 반환합니다. LLM이 파일을 읽어 상세 내용을 확인하는 방식으로, 대량 결과에서도 컨텍스트 윈도우를 절약할 수 있습니다.
파라미터 | 타입 | 필수 | 기본값 | 설명 |
| string[] | ✅ | - | 검색할 회사명 목록 |
| string | - |
| 검색할 플랫폼 ( |
# pnpm 없는 경우 "npm install -g pnpm"
pnpm install
pnpm buildclaude mcp add job-search -- npx -y job-search-mcpclaude_desktop_config.json에 추가:
{
"mcpServers": {
"job-search": {
"command": "npx",
"args": ["-y", "job-search-mcp"]
}
}
}claude mcp add job-search -- node /path/to/job-search-mcp/dist/index.js{
"mcpServers": {
"job-search": {
"command": "node",
"args": ["/path/to/job-search-mcp/dist/index.js"]
}
}
}당근마켓 채용공고 검색해줘사람인에서 네이버 채용공고 찾아줘여러 회사의 채용공고를 한 번에 검색할 때 유용합니다. search_jobs를 반복 호출하는 것보다 빠릅니다.
네이버, 카카오, 라인플러스, 당근마켓, 토스 채용공고를 한 번에 검색해줘.아래 프롬프트를 그대로 붙여넣어 search_jobs_bulk의 대량 처리 성능을 테스트할 수 있습니다.
다음 100개 회사의 채용공고를 한 번에 검색해줘:
삼성전자, SK하이닉스, LG전자, 현대자동차, 기아, 네이버, 카카오, 쿠팡, 배달의민족, 토스,
당근마켓, 라인플러스, 삼성SDS, LG CNS, SK텔레콤, KT, 현대모비스, 포스코, 한화솔루션, CJ대한통운,
셀트리온, 크래프톤, 넥슨코리아, 엔씨소프트, 넷마블, 스마일게이트, 카카오게임즈, 펄어비스, 컴투스, 데브시스터즈,
야놀자, 직방, 리디, 무신사, 마켓컬리, 오늘의집, 토스증권, 카카오뱅크, 케이뱅크, 비바리퍼블리카,
한글과컴퓨터, 더존비즈온, 안랩, 이스트소프트, 카카오엔터프라이즈, 네이버클라우드, NHN, 우아한형제들, 두나무, 하이브,
롯데정보통신, 신한은행, 하나은행, KB국민은행, 우리은행, 현대카드, 삼성생명, 교보생명, 한화생명, 미래에셋증권,
SK플래닛, 11번가, 위메프, 티몬, SSG닷컴, GS리테일, BGF리테일, 올리브영, 아모레퍼시픽, LG생활건강,
현대건설, 대우건설, GS건설, 삼성물산, SK에코플랜트, 한화건설, 롯데건설, 포스코건설, DL이앤씨, HDC현대산업개발,
CJ ENM, 스튜디오드래곤, 카카오엔터테인먼트, SM엔터테인먼트, JYP엔터테인먼트, YG엔터테인먼트, 넷플릭스코리아, 쿠팡플레이, 왓챠, 티빙,
LG이노텍, 삼성전기, SK실트론, DB하이텍, 한미반도체, 리노공업, 원익IPS, 주성엔지니어링, 코미코, 솔브레인동시성 제어: search_jobs_bulk는 10개씩 배치로 병렬 요청
결과 저장: 대량 검색 결과는 임시 파일(%TEMP%/job-search-mcp/)로 저장하여 컨텍스트 절약
타임아웃: 각 HTTP 요청에 15초 AbortSignal.timeout 적용
웹 스크래핑 기반이므로, 잡코리아/사람인의 HTML 구조 변경 시 파싱이 실패할 수 있습니다.
짧은 시간에 너무 많은 요청을 보내면 플랫폼 측에서 일시적으로 접근을 차단(rate limit)할 수 있습니다.
각 요청에는 15초 타임아웃이 적용되어 있으며, 시간 초과 시 해당 요청은 실패 처리되고 나머지 결과는 정상 반환됩니다.
테스트 환경 :
모델 : Claude Opus 4.6 (1M)
장비 : Raspberry pi 4 Model B 8GB RAM
네트워크 : CAT 5E UTP
버전 | 기업(건) | 공고(개) | 소요 시간(MCP) | 소요 시간(총합) | 비고 |
| 100 | 5,002 |
| 3m 18s | 단순 토큰 출력 방식 |
| 100 | 5,002 | 125.7s | 2m 49s | 동시성 제한(10 batch)파일 저장 방식 |
현상
search_jobs_bulk로 대량 검색 시, 로컬 PC에서는 수십 초면 끝나는 작업이 수십 분 이상 걸리거나 응답이 오지 않습니다.
원인
npx -y job-search-mcp 방식은 매 실행마다 npm registry에서 최신 버전을 확인합니다. Raspberry Pi처럼 네트워크가 느린 환경에서는 이 registry 통신이 병목이 되어, 실제 검색이 시작되기 전에 수 분 이상 지연될 수 있습니다.
# ss -tnp로 확인하면 npm registry(104.16.x.x)에 연결된 상태로 멈춰있음
ESTAB 0 0 192.168.x.x:41824 104.16.3.34:443 users:(("npm exec job-se",...))해결
글로벌 설치로 전환하면 매번 registry를 확인하지 않고 바로 실행됩니다.
# 글로벌 설치
npm install -g job-search-mcp
# Claude Code MCP 설정 변경
claude mcp remove job-search
claude mcp add job-search -- job-search-mcpMIT License. See LICENSE for details.
Search Korean job postings (채용공고 검색). Searches JobKorea and Saramin for job listings by company name. 한국 채용공고 검색 도구입니다. 회사명을 입력하면 잡코리아와 사람인에서 해당 회사의 채용공고를 검색합니다. 어떤 회사명이든 검색 가능합니다. 채용, 구인, 구직, 취업, job search, hiring, career, recruitment 관련 질문에 이 도구를 사용하세요. 공고 제목, 경력, 학력, 지역, 마감일, URL을 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 페이지 번호 (기본값: 1) | |
| platform | No | 검색할 플랫폼 (jobkorea, saramin, all). 기본값: all | all |
| company_name | Yes | 검색할 회사명. 사용자가 입력한 회사명을 그대로 전달하세요. 임의로 줄이거나 변형하지 마세요. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it searches JobKorea and Saramin and returns specific fields, and states any company name is searchable. But it doesn't discuss pagination, platform selection behavior, or potential limitations/side effects, which is a gap for a tool with no annotations.
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 overly verbose with redundant bilingual repetition, repeating the same information in English and Korean. It could be condensed to a single sentence, and the structure is not front-loaded with the most essential information.
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 description covers purpose, usage, and return fields, and the schema covers parameters. However, it lacks details about pagination behavior, the platform parameter's effect, and the exact response format (e.g., how results are structured), which is important given no output schema.
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 coverage is 100%, so each parameter is already described. The description adds little beyond the schema, only reiterating that any company name can be searched, which is implied by the schema's description.
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 tool searches Korean job postings by company name across JobKorea and Saramin, and lists the returned fields. It distinguishes from the sibling (search_jobs_bulk) by focusing on single-company search, though it doesn't explicitly name the sibling.
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?
It explicitly tells the agent to use this tool for questions related to job search, hiring, career, and recruitment. However, it doesn't specify when not to use it or mention alternative tools, so the guidance is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search job postings for multiple companies at once (여러 회사 채용공고 일괄 검색). 여러 회사명을 한 번에 입력하면 내부에서 병렬로 검색하여 결과를 반환합니다. 결과는 파일로 저장되며, 요약과 파일 경로를 반환합니다. 파일을 읽어서 상세 내용을 확인하세요. 병역특례 지정업체 목록 등 다수의 회사를 한 번에 조회할 때 사용하세요. search_jobs를 여러 번 호출하는 것보다 훨씬 빠릅니다.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | 검색할 플랫폼 (jobkorea, saramin, all). 기본값: all | all |
| company_names | Yes | 검색할 회사명 목록. 사용자가 입력한 회사명을 그대로 전달하세요. 임의로 줄이거나 변형하지 마세요. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: internal parallel search, results saved to a file, and response containing a summary and file path. It also instructs the user to read the file for details. Minor gaps remain, such as file persistence and error handling for invalid inputs, but overall transparency is strong.
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 compact yet comprehensive. It front-loads the purpose, then explains the process, output, and usage guidance in a logical order. Every sentence adds value, with no fluff or redundancy.
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?
Despite no output schema, the description explains the return format (summary and file path) and the side effect of file creation. The tool has only 2 parameters, and the description provides enough context for an agent to invoke it correctly, including use case and performance benefit.
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 100%, with both company_names and platform having clear descriptions. The tool description adds minimal parameter-specific detail beyond what the schema already provides, so the baseline of 3 is appropriate per the rubric.
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 'Search job postings for multiple companies at once' with a specific verb and resource. It distinguishes from the sibling tool search_jobs by emphasizing bulk search and speed advantage, making its unique purpose unambiguous.
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?
Explicitly states when to use: 'Use this when you want to look up many companies at once, such as a list of companies designated for military exemption.' It also directly compares to the alternative: 'much faster than calling search_jobs multiple times,' providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.6search_jobssearch_jobs_bulkScored across 2 tools
The two tools are clearly differentiated: one searches a single company, the other supports batch searching for multiple companies. While they share the same core purpose, the distinct execution mode (direct results vs. file output) makes them easy to tell apart.
Both tools follow a consistent 'search_jobs' verb-noun pattern, with the bulk variant clearly suffixed as '_bulk'. This creates a predictable and readable naming scheme.
With only 2 tools, the server feels thin for a general job search use case, but the single/bulk search split is a reasonable scope for a focused utility. It is borderline but not extreme.
The server only supports searching by company name, lacking keyword, location, or other filters. The bulk tool returns a file path, requiring external file access to retrieve results, which is an awkward dead end. Missing detail views or pagination leave significant gaps.
Search job postings across Indeed, LinkedIn, and more from one request - titles, companies
Search job postings, companies, and technology stacks across 10M+ companies.
Search company disclosures and financial statements from the Korean market. Retrieve stock profile…
Search Japanese companies, departments and hiring signals; export CSV/XLSX with authentication.
