Skip to main content
Glama
BACH-AI-Tools

bach-jsearch

Official

Jsearch MCP Server

English | 简体中文 | 繁體中文

用于访问 Jsearch API 的 MCP 服务器。

🚀 使用 EMCP 平台快速体验

EMCP 是一个强大的 MCP 服务器管理平台,让您无需手动配置即可快速使用各种 MCP 服务器!

快速开始:

  1. 🌐 访问 EMCP 平台

  2. 📝 注册并登录账号

  3. 🎯 进入 MCP 广场,浏览所有可用的 MCP 服务器

  4. 🔍 搜索或找到本服务器(bach-jsearch

  5. 🎉 点击 "安装 MCP" 按钮

  6. ✅ 完成!即可在您的应用中使用

EMCP 平台优势:

  • 零配置:无需手动编辑配置文件

  • 🎨 可视化管理:图形界面轻松管理所有 MCP 服务器

  • 🔐 安全可靠:统一管理 API 密钥和认证信息

  • 🚀 一键安装:MCP 广场提供丰富的服务器选择

  • 📊 使用统计:实时查看服务调用情况

立即访问 EMCP 平台 开始您的 MCP 之旅!


Related MCP server: trackly-cli

简介

这是一个 MCP 服务器,用于访问 Jsearch API。

  • PyPI 包名: bach-jsearch

  • 版本: 1.0.0

  • 传输协议: stdio

安装

从 PyPI 安装:

pip install bach-jsearch

从源码安装:

pip install -e .

运行

方式 1: 使用 uvx(推荐,无需安装)

# 运行(uvx 会自动安装并运行)
uvx --from bach-jsearch bach_jsearch

# 或指定版本
uvx --from bach-jsearch@latest bach_jsearch

方式 2: 直接运行(开发模式)

python server.py

方式 3: 安装后作为命令运行

# 安装
pip install bach-jsearch

# 运行(命令名使用下划线)
bach_jsearch

配置

API 认证

此 API 需要认证。请设置环境变量:

export API_KEY="your_api_key_here"

环境变量

变量名

说明

必需

API_KEY

API 密钥

PORT

不适用

HOST

不适用

在 Cursor 中使用

编辑 Cursor MCP 配置文件 ~/.cursor/mcp.json:

{
  "mcpServers": {
    "bach-jsearch": {
      "command": "uvx",
      "args": ["--from", "bach-jsearch", "bach_jsearch"],
      "env": {
        "API_KEY": "your_api_key_here"
      }
    }
  }
}

在 Claude Desktop 中使用

编辑 Claude Desktop 配置文件 claude_desktop_config.json:

{
  "mcpServers": {
    "bach-jsearch": {
      "command": "uvx",
      "args": ["--from", "bach-jsearch", "bach_jsearch"],
      "env": {
        "API_KEY": "your_api_key_here"
      }
    }
  }
}

可用工具

此服务器提供以下工具:

job_details

Get all job details, including additional information such as: application options / links, employer reviews and estimated salaries for similar jobs.

端点: GET /job-details

参数:

  • job_id (string) 必需: Job Id of the job for which to get details. Batching of up to 20 Job Ids is supported by separating multiple Job Ids by comma (,). Note that each Job Id in a batch request is counted as a request for quota calculation.

  • country (string): Country code of the country from which to return job posting. Default: us Allowed values: See https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

  • language (string): Language code in which to return job postings. Leave empty to use the primary language in the specified country (country parameter). Allowed values: See https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes

  • fields (string): A comma separated list of job fields to include in the response (field projection). By default all fields are returned. Example: employer_name,job_publisher,job_title,job_country


Search for jobs posted on any public job site across the web on the largest job aggregate in the world (Google for Jobs). Extensive filtering support and most options available on Google for Jobs.

端点: GET /search

参数:

  • query (string) 必需: Free-form jobs search query. It is highly recommended to include job title and location as part of the query, see query examples below. Examples: web development jobs in chicago marketing manager in new york via linkedin

  • page (number): Page to return (each page includes up to 10 results). Default: 1 Allowed values: 1-50

  • num_pages (number): Number of pages to return, starting from page. Default: 1 Allowed values: 1-50 Note: each 10 results page returned by the API will consume a single request from the quota.

  • country (string): Country code of the country from which to return job postings. Please note that this parameter must be set in order to get jobs in a specific country, for example, to query for software developer jobs in Berlin, one should add country=de to the request - e.g. query=software+developers+in+berlin&country=de. Default: us Allowed values: See https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

  • language (string): Language code in which to return job postings. Leave empty to use the primary language in the specified country (country parameter). Note that each country supports certain languages. In case a language not supported by the specified country is used, it is likely that no results will be returned. Allowed values: See https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes

  • date_posted (string): Find jobs posted within the time you specify. Default: all Allowed values: all, today, 3days, week, month

  • work_from_home (string): Example value:

  • employment_types (string): Find jobs of particular employment types, specified as a comma delimited list of the following values: FULLTIME, CONTRACTOR, PARTTIME, INTERN.

  • job_requirements (string): Find jobs with specific requirements, specified as a comma delimited list of the following values: under_3_years_experience, more_than_3_years_experience, no_experience, no_degree.

  • radius (number): Return jobs within a certain distance from location as specified as part of the query (in km). This internally sent as the Google \"lrad\" parameter and although it might affect the results, it is not strictly followed by Google for Jobs.

  • exclude_job_publishers (string): Exclude jobs published by specific publishers, specified as a comma (,) separated list of publishers to exclude. Example: BeeBe,Dice

  • fields (string): A comma separated list of job fields to include in the response (field projection). By default all fields are returned. Example: employer_name,job_publisher,job_title,job_country


job_salary

Get estimated salaries / pay for a jobs around a location by job title and location. The salary estimation is returned for several periods, depending on data availability / relevance, and includes: hourly, daily, weekly, monthly, or yearly.

端点: GET /estimated-salary

参数:

  • job_title (string) 必需: Job title for which to get salary estimation.

  • location (string) 必需: Free-text location/area in which to get salary estimation.

  • location_type (string): Specify the type of the location you are looking to get salary estimation for additional accuracy. Allowed values: ANY, CITY, STATE, COUNTRY Default: ANY

  • years_of_experience (string): Get job estimation for a specific experience level range (years). Allowed values: ALL, LESS_THAN_ONE, ONE_TO_THREE, FOUR_TO_SIX, SEVEN_TO_NINE, TEN_TO_FOURTEEN, ABOVE_FIFTEEN Default: ALL

  • fields (string): A comma separated list of job salary fields to include in the response (field projection). By default all fields are returned. Example: job_title,median_salary,location


company_job_salary

Get estimated job salaries/pay in a specific company by job title and optionally a location and experience level in years.

端点: GET /company-job-salary

参数:

  • company (string) 必需: The company name for which to get salary information (e.g. Amazon).

  • job_title (string) 必需: Job title for which to get salary estimation.

  • location (string): Free-text location/area in which to get salary estimation.

  • location_type (string): Specify the type of the location you are looking to get salary estimation for additional accuracy. Allowed values: ANY, CITY, STATE, COUNTRY Default: ANY

  • years_of_experience (string): Get job estimation for a specific experience level range (years). Allowed values: ALL, LESS_THAN_ONE, ONE_TO_THREE, FOUR_TO_SIX, SEVEN_TO_NINE, TEN_TO_FOURTEEN, ABOVE_FIFTEEN Default: ALL


技术栈

  • 传输协议: stdio

  • HTTP 客户端: httpx

许可证

MIT License - 详见 LICENSE 文件。

开发

此服务器由 API-to-MCP 工具生成。

版本: 1.0.0

Available Tools

4 tools
company_job_salaryA

Get estimated job salaries/pay in a specific company by job title and optionally a location and experience level in years.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyYesThe company name for which to get salary information (e.g. Amazon).
locationNoFree-text location/area in which to get salary estimation.
job_titleYesJob title for which to get salary estimation.
location_typeNoSpecify the type of the location you are looking to get salary estimation for additional accuracy. Allowed values: ANY, CITY, STATE, COUNTRY Default: ANY
years_of_experienceNoGet job estimation for a specific experience level range (years). Allowed values: ALL, LESS_THAN_ONE, ONE_TO_THREE, FOUR_TO_SIX, SEVEN_TO_NINE, TEN_TO_FOURTEEN, ABOVE_FIFTEEN Default: ALL

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the burden. The word 'Get' and 'estimated' indicate a read-only, approximate nature, but the description does not disclose data sources, potential inaccuracies, or behavior when no data is found. It suffices for a simple lookup but lacks deeper 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 a single, front-loaded sentence that clearly states the tool's purpose with no redundancy or filler. Every word earns its place.

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?

The tool has 5 parameters and no output schema. The description gives a clear overview of the core functionality, but it does not explain the return format (e.g., salary range, currency) or explicitly differentiate between this tool and the sibling 'job_salary', leaving some ambiguity for an agent deciding between them.

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?

The schema provides full 100% coverage for all 5 parameters, so the baseline is 3. The description adds minimal value by naming job_title, location, and years_of_experience, but does not mention company or location_type, nor does it provide any syntax or format details beyond the schema.

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?

Description uses the specific verb 'Get' and clarifies the resource as 'estimated job salaries/pay', scoped to 'a specific company' with optional location and experience. This clearly distinguishes it from the sibling tool 'job_salary' (which likely covers general salary data) and other job tools.

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 company-specific salary queries by emphasizing 'in a specific company', but it does not explicitly state when to use this tool over job_salary or job_search, nor does it provide exclusions or alternative recommendations. The context is present but not fully developed.

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

job_detailsA

Get all job details, including additional information such as: application options / links, employer reviews and estimated salaries for similar jobs.

ParametersJSON Schema
NameRequiredDescriptionDefault
fieldsNoA comma separated list of job fields to include in the response (field projection). By default all fields are returned. Example: employer_name,job_publisher,job_title,job_country
job_idYesJob Id of the job for which to get details. Batching of up to 20 Job Ids is supported by separating multiple Job Ids by comma (,). Note that each Job Id in a batch request is counted as a request for quota calculation.
countryNoCountry code of the country from which to return job posting. Default: us Allowed values: See https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
languageNoLanguage code in which to return job postings. Leave empty to use the primary language in the specified country (country parameter). Allowed values: See https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It accurately describes a read operation ('Get') with no side effects, but does not disclose prerequisites, auth requirements, or performance implications like batching/quota, which are documented in the schema. The description is honest but adds minimal 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?

Single sentence, front-loaded with the main action, and no fluff. It efficiently conveys the scope and examples without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although there is no output schema, the description provides a reasonable overview of return content, including specific additional info. The schema documents all parameters, so the description is sufficiently complete for an agent to invoke the tool, though it doesn't mention batching or field projection explicitly (those are in the schema).

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?

Schema coverage is 100%, with detailed descriptions for each parameter (batching, allowed values, defaults). The description adds no parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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?

Description uses specific verb 'Get' and resource 'all job details', listing concrete additional info (application options, employer reviews, estimated salaries). This clearly distinguishes it from siblings like job_search and job_salary, which focus on searching and salary-specific data.

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 use for retrieving comprehensive details for a specific job but does not explicitly mention alternatives or provide when-not-to-use guidance. It is clear enough for an agent to know this is for detail lookup, but lacks explicit exclusions.

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

job_salaryA

Get estimated salaries / pay for a jobs around a location by job title and location. The salary estimation is returned for several periods, depending on data availability / relevance, and includes: hourly, daily, weekly, monthly, or yearly.

ParametersJSON Schema
NameRequiredDescriptionDefault
fieldsNoA comma separated list of job salary fields to include in the response (field projection). By default all fields are returned. Example: job_title,median_salary,location
locationYesFree-text location/area in which to get salary estimation.
job_titleYesJob title for which to get salary estimation.
location_typeNoSpecify the type of the location you are looking to get salary estimation for additional accuracy. Allowed values: ANY, CITY, STATE, COUNTRY Default: ANY
years_of_experienceNoGet job estimation for a specific experience level range (years). Allowed values: ALL, LESS_THAN_ONE, ONE_TO_THREE, FOUR_TO_SIX, SEVEN_TO_NINE, TEN_TO_FOURTEEN, ABOVE_FIFTEEN Default: ALL

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that output periods vary based on data availability and includes hourly/daily/weekly/monthly/yearly estimates, providing some behavioral insight. However, it does not mention read-only nature, data accuracy limitations, or error handling, which would add transparency.

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 sentences, front-loaded with the primary purpose and followed by a concise detail about output periods. Every word earns its place with no redundancy or filler, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description provides key return information (the periods included), which is helpful. It could be more complete by explaining how optional parameters like years_of_experience and location_type affect results, but the core behavior is adequately covered for a simple salary lookup 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?

Schema coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema by naming job_title and location, but it does not elaborate on location_type or years_of_experience, which the schema already describes. It effectively restates what is in the schema.

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 states the specific verb 'Get' targeting 'estimated salaries / pay' for jobs by title and location, which clearly defines the resource and scope. It also mentions the output periods (hourly to yearly), distinguishing it from sibling tools like job_search and job_details, and from company_job_salary by focusing on general salary estimation.

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 use for obtaining salary estimates by title and location, but it does not explicitly state when to use this tool versus alternatives like company_job_salary. It lacks exclusions or alternative guidance, relying on the tool name to suggest the appropriate use case.

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. 4 tool updatesv1.0.0
    • First observedcompany_job_salary
    • First observedjob_details
    • First observedjob_salary
    • First observedjob_search

TDQS

A3.9/5.0

Scored across 4 tools

Disambiguation4/5

The tools are mostly distinct: job_search finds jobs, job_details retrieves details for a specific job, job_salary estimates salary by title/location, and company_job_salary estimates salary by company/title. However, job_salary and company_job_salary both deal with salary estimation, and job_details also includes salary estimates, creating minor overlap.

Naming Consistency4/5

All tools use lowercase snake_case with a descriptive prefix. job_search uses a verb (search), while job_details and job_salary use nouns, and company_job_salary combines company and job. The pattern is readable but not perfectly uniform.

Tool Count5/5

With only 4 tools, the server is well-scoped for a job search API. Each tool serves a distinct, essential function (search, details, salary by title, salary by company) without unnecessary proliferation.

Completeness4/5

The tool set covers the core job-search lifecycle: searching, viewing details, and salary estimation. Minor gaps exist, such as lack of tools for managing saved searches or applying to jobs, but for a search-focused server the coverage is solid.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    MCP server that exposes job search data from multiple boards, enabling clients to query and manage job listings via natural language.
    7
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    MCP server for job search and application tracking, enabling AI agents to search jobs, get details, manage applications, and find contacts across 128K+ jobs and 1,900+ companies.
    638 npm
    3
    MIT
  • F
    license
    Not graded
    quality
    C
    maintenance
    GetJobzi MCP server for job search, application tracking, and career forecasting.
    -
  • A
    license
    A
    quality
    C
    maintenance
    MCP server for SuperJob.ru API that enables searching for vacancies, employers, and reference data like towns and professions.
    5
    42 npm
    MIT