HireBase MCP Server
HireBase MCP 서버
HireBase Job API와 상호 작용할 수 있는 도구를 제공하는 MCP(Model Context Protocol) 서버입니다.
사용 가능한 MCP 상호 작용
이 서버는 다음과 같은 MCP 상호작용을 제공합니다.
도구
search_jobs: HireBase API를 사용하여 다양한 기준(키워드, 직함, 위치, 급여 등)에 따라 일자리를 검색합니다.매개변수 :
query,and_keywords,or_keywords,not_keywords,title,category,country,city,location_type,company,salary_from,salary_to,salary_currency,years_from,years_to,visa,limit.
get_job: HireBase ID를 사용하여 특정 직무에 대한 자세한 정보를 검색합니다.매개변수 :
job_id.
프롬프트
create_candidate_profile: 후보자 세부 정보(이름, LinkedIn, 웹사이트, 이력서 내용)를 기반으로 구조화된 프롬프트를 생성하여 구직 활동을 안내합니다.매개변수 :
name,linkedin_url,personal_website,resume_text.
Related MCP server: Google Jobs Scraper MCP
클라이언트 설정(예: Claude Desktop, Cursor)
Claude Desktop이나 Cursor와 같은 MCP 클라이언트와 함께 이 서버를 사용하려면 클라이언트를 구성하여 서버 프로세스를 실행하고 선택적으로 HireBase API 키를 제공해야 합니다.
uv설치되었는지 확인하세요:curl -LsSf https://astral.sh/uv/install.sh | shHireBase API 키 얻기(선택 사항): HireBase 에서 키를 요청합니다. 이를 환경 변수(
HIREBASE_API_KEY)로 설정하거나 그냥 비워둘 수 있습니다.클라이언트를 구성하세요:
uvx사용:Claude Desktop:
claude_desktop_config.json편집하세요:지엑스피1
커서: 설정 > MCP > 서버 추가로 이동하세요.
Mac/Linux 명령:
uvx hirebase-mcp(필요한 경우 패키지 이름 조정)Windows 명령:
cmdWindows 인수:
/c,uvx,hirebase-mcp(필요한 경우 패키지 이름 조정)해당 섹션에서
HIREBASE_API_KEY환경 변수를 설정합니다.
Python을 통해 소스에서 실행(대안):
저장소를 복제하고 복제한 위치를 기록하세요.
Claude Desktop:
claude_desktop_config.json편집하세요: GXP2
개발
이 프로젝트에서는 다음을 사용합니다.
종속성 관리 및 가상 환경을 위한
uv린팅 및 포맷팅을 위한
ruff빌드 백엔드로
hatch
일반적인 작업
# Setup virtual env
uv venv
# Install dependencies
uv pip install -e .
# install cli tools
uv tool install ruff
# Run linting
ruff check .
# Format code
ruff format .환경 변수
HIREBASE_API_KEY( 필수 ): HireBase API에 액세스하는 데 필요한 API 키입니다. 서버에서 채용 정보 데이터에 대한 인증된 요청을 하려면 이 키가 필요합니다.
테스트
이 프로젝트에서는 핵심 도구 로직을 테스트하기 위해 pytest 사용합니다. unittest.mock 사용하여 외부 API 호출을 모의 테스트합니다.
테스트 종속성 설치:
# Ensure you are in your activated virtual environment (.venv)
uv pip install -e '.[test]'테스트 실행:
# Example command
pytest기여하다
기여를 환영합니다.
특허
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
Available Tools
2 toolsget_jobA
Get detailed information about a specific job
Args:
job_id: The unique identifier of the job
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'detailed information' but does not specify what fields are returned, any authentication or rate limits, or confirm it is a read-only operation. The description lacks sufficient behavioral context.
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 short sentences with a structured Args section, no redundant words, and perfectly sized for the tool's simplicity.
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?
For a simple single-parameter get tool, the description is adequate but could be improved by noting what 'detailed information' includes, potential error conditions, or expected return format. Without annotations or output schema, additional context would enhance completeness.
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?
With 0% schema coverage, the description compensates by adding meaning: 'job_id: The unique identifier of the job' goes beyond the schema's title 'Job Id', explaining the parameter's role effectively.
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 verb 'get' and the resource 'detailed information about a specific job', and the sibling tool 'search_jobs' implies this tool is for fetching a single job by ID, distinguishing it effectively.
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 implies usage for fetching a specific job by ID, but provides no explicit guidance on when to use it versus the sibling 'search_jobs', nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_jobsB
Search for jobs using the HireBase API
Args:
query: Full text search query
and_keywords: Keywords that must all appear in results
or_keywords: Keywords where at least one must appear
not_keywords: Keywords that must not appear
title: Job titles to search for
category: Job categories to filter by
country: Countries to filter by
city: Cities to filter by
location_type: Location types (Remote, In-Person, Hybrid)
company: Companies to filter by
salary_from: Minimum salary
salary_to: Maximum salary
salary_currency: Salary currency (e.g. USD)
years_from: Minimum years of experience
years_to: Maximum years of experience
visa: Whether job offers visa sponsorship
limit: Maximum number of results to return
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| and_keywords | No | ||
| or_keywords | No | ||
| not_keywords | No | ||
| title | No | ||
| category | No | ||
| country | No | ||
| city | No | ||
| location_type | No | ||
| company | No | ||
| salary_from | No | ||
| salary_to | No | ||
| salary_currency | No | ||
| years_from | No | ||
| years_to | No | ||
| visa | No | ||
| limit | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral context such as read-only status, pagination behavior, rate limits, or cost implications. The parameter 'limit' hints at pagination but doesn't explain default or maximum results. The tool's safety profile (e.g. destructive or not) is completely unspecified.
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 relatively concise, starting with a clear one-line summary followed by a bulleted list of parameters. It avoids unnecessary prose. However, the parameter list could be streamlined further, and the formatting is slightly inconsistent (e.g., some descriptions end with periods, others do not).
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?
Given the tool has 17 parameters, no output schema, and no annotations, the description is incomplete. It does not explain what the return format is, how pagination works, or any side effects. The agent lacks essential runtime information for a complex search tool.
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?
With 0% schema description coverage, the description partially compensates by providing brief explanations for each parameter (e.g., 'Full text search query', 'Keywords that must all appear'). However, these descriptions are often repetitive of the parameter titles and lack additional detail like allowed values or formatting. They add value but not enough to fully overcome the coverage gap.
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 for jobs' using a specific API. It identifies the verb (search), the resource (jobs), and the system (HireBase API). The sibling tool 'get_job' likely retrieves a single job, making this tool's purpose distinct for broad search/filtering.
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?
No explicit when-to-use or alternative guidance is provided. The description only lists parameters, leaving the agent to infer usage context. The sibling 'get_job' implies a distinction between search and retrieval, but no direct comparison or exclusion criteria are given.
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.
2 tool updates
- First observed
get_job - First observed
search_jobs
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one retrieves a single job by ID, the other searches/filters jobs. There is no overlap in functionality.
Both tools follow a consistent snake_case verb_noun pattern (get_job, search_jobs), making them predictable and easy to understand.
With only 2 tools, the server feels minimal for a job platform. While it covers basic search and retrieval, the scope is thin and suggests missing functionality like listing or management tools.
The tool set covers searching and fetching job details but lacks listing all jobs, CRUD operations, or endpoints for related entities like categories or companies. This leaves notable gaps for a full-featured job interface.
Maintenance
Related MCP Connectors
Job search over employers' own hiring systems. Search with no key; a free key opens every read tool.
Manage job applications — jobs, companies, boards, notes, and profile — from your AI client.
Search job postings across Indeed, LinkedIn, and more from one request - titles, companies
JobsPipe — data pipeline of every job posting on the web. Search live, normalized job postings from 30+ ATS feeds and job boards for AI agents via MCP.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables searching and retrieving job listings from the Active Jobs Db API with support for multiple filters like title, location, organization, and AI-based fields.6MIT
- FlicenseNot gradedqualityBmaintenanceEnables AI assistants to search Google Jobs and retrieve structured job listings, including titles, companies, locations, descriptions, and direct apply links, through natural language queries. Supports location targeting, country/language filters, and pagination.-
- FlicenseNot gradedqualityCmaintenanceEnables searching and retrieving job postings from multiple job boards (USAJOBS, Adzuna, Jooble, The Muse, Reed, and ATS) through the JobStack API, exposing search_jobs and get_job as MCP tools.-
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to search remote job listings, read full descriptions and structured metadata, compare roles, and retrieve original application links when the account's subscription and scopes allow.MIT