Skip to main content
Glama
enesjakozh
jhgaylor

HireBase MCP Server

by jhgaylor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

HireBase MCP 服务器

模型上下文协议 (MCP) 服务器提供与 HireBase Job API 交互的工具。

许可证：MIT

可用的 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 密钥。

  1. 确保已安装uv ： curl -LsSf https://astral.sh/uv/install.sh | sh

  2. **获取 HireBase API 密钥（可选）：**从HireBase请求密钥您可以将其设置为环境变量（ HIREBASE_API_KEY ）或将其留空。

  3. 配置您的客户端：

    • 使用uvx ：

      • **Claude Desktop：**编辑您的claude_desktop_config.json ：

        {
  "mcpServers": {
    "hirebase": {
      "command": "uvx",
      "args": [
        "hirebase-mcp" 
      ],
      "env": {
        "HIREBASE_API_KEY": "" 
      }
    }
  }
}

      • **光标：**转到设置 > MCP > 添加服务器：

        • Mac/Linux 命令： uvx hirebase-mcp （如有需要，调整包名称）

        • Windows 命令： cmd

        • Windows 参数： /c 、 uvx 、 hirebase-mcp （如果需要，调整包名称）

        • 在适当的部分设置HIREBASE_API_KEY环境变量。

    • 通过 Python 从源代码运行（替代方法）：

      1. 克隆 repo 并记下克隆到的位置

      2. **Claude Desktop：**编辑您的claude_desktop_config.json ：GXP2

发展

该项目使用：

  • uv用于依赖管理和虚拟环境

  • 用于 linting 和格式化的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 调用。

  1. 安装测试依赖项：

# Ensure you are in your activated virtual environment (.venv)
uv pip install -e '.[test]'

  1. 运行测试：

# Example command
pytest

贡献

欢迎投稿。

执照

该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。

Available Tools

2 tools
get_jobA

Get detailed information about a specific job

Args:
    job_id: The unique identifier of the job
ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes

TDQS

A3.7/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault
queryNo
and_keywordsNo
or_keywordsNo
not_keywordsNo
titleNo
categoryNo
countryNo
cityNo
location_typeNo
companyNo
salary_fromNo
salary_toNo
salary_currencyNo
years_fromNo
years_toNo
visaNo
limitNo

TDQS

B3.3/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

  1. 2 tool updates
    • First observedget_job
    • First observedsearch_jobs
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

A3.6/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow a consistent snake_case verb_noun pattern (get_job, search_jobs), making them predictable and easy to understand.

Tool Count3/5

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.

Completeness3/5

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

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Google Jobs Scraper MCP

    johnisanerd
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables 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.
    -

  • jobstack-mcp

    IsaiahDupree
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables 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.
    -

  • Job Search MCP

    hiddenjobs
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables 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

Appeared in Searches