Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

datasets_jobs_search

Search live job postings from ATS boards and company career sites. Filter by keyword, location, salary, provider, remote, and employment type. Returns structured open-role data.

Instructions

Search the jobs dataset (all companies' live postings). Full-text + faceted search over every job posting crawled from every discovered company ATS board (Greenhouse, Lever, Ashby, Workday, SmartRecruiters, Workable, Recruitee, Rippling, Personio, Teamtailor, Oracle, UKG, iCIMS, Eightfold, Gem, Pinpoint) plus 5 single-company big-tech careers platforms (Amazon, Apple, Google, Meta, Tesla). Open roles only by default (set include_closed=true for historical/filled roles). Salary is parsed from a structured field when the provider has one, or from an explicit pay figure stated in the description otherwise, so coverage varies by posting rather than by provider; min_salary/max_salary filter on it and require salary_currency, since comparing raw compensation numbers across currencies is meaningless. Location is also exposed as structured city/state/country fields alongside the free-text location string, so city/state/country filter on an exact match of those parsed components rather than substring-matching the display string. job_family is an exact level-2 ISCO family label assigned from ESCO occupation evidence; ambiguous postings remain unclassified and do not match that filter. employment_type is never populated for google-jobs/meta-jobs, and posted_at (so sort=posted_desc) is never populated for meta-jobs/tesla-jobs -- their upstream APIs expose no such field. provider enum: greenhouse, lever, ashby, workday, smartrecruiters, workable, recruitee, rippling, personio, teamtailor, oracle, ukg, icims, eightfold, gem, pinpoint, amazon-jobs, apple-jobs, google-jobs, meta-jobs, tesla-jobs. workplace_type enum: onsite, hybrid, remote. sort enum: relevance, posted_desc, company_asc.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFull-text over title, company, description
cityNoExact city filter (parsed location component)
pageNoPage number, default 1
sortNoSort enum: relevance, posted_desc, company_asc
stateNoExact state/region filter (parsed location component)
remoteNoFilter by remote (true or false)
companyNoCompany name match
countryNoExact country filter (parsed location component); ISO country code or name, matched case-insensitively
locationNoLocation match
providerNoProvider filter
page_sizeNoPage size, default 20, max 100; page*page_size must be <= 10000
departmentNoExact department filter
job_familyNoExact ESCO/ISCO job-family label filter
max_salaryNoMaximum salary (matches postings whose range starts at or below this); requires salary_currency
min_salaryNoMinimum salary (matches postings whose range reaches at least this); requires salary_currency
include_closedNoInclude closed/filled roles (default false = open only)
workplace_typeNoWorkplace type filter
employment_typeNoExact employment-type filter
salary_currencyNo3-letter ISO currency code (e.g. USD) the min_salary/max_salary bounds are in; required when either bound is set

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.17.5
    • addedInput schema / properties / provider / enum
      Added value: +[
      +  "greenhouse",
      +  "lever",
      +  "ashby",
      +  "workday",
      +  "smartrecruiters",
      +  "workable",
      +  "recruitee",
      +  "rippling",
      +  "personio",
      +  "teamtailor",
      +  "oracle",
      +  "ukg",
      +  "icims",
      +  "eightfold",
      +  "gem",
      +  "pinpoint",
      +  "amazon-jobs",
      +  "apple-jobs",
      +  "google-jobs",
      +  "meta-jobs",
      +  "tesla-jobs"
      +]
    • addedInput schema / properties / sort / enum
      Added value: +[
      +  "relevance",
      +  "posted_desc",
      +  "company_asc"
      +]
    • addedInput schema / properties / workplace_type / enum
      Added value: +[
      +  "onsite",
      +  "hybrid",
      +  "remote"
      +]
  2. Changed9 schema fields changed
    • addedInput schema / properties / city
      Added value: +{
      +  "description": "Exact city filter (parsed location component)",
      +  "type": "string"
      +}
    • addedInput schema / properties / country
      Added value: +{
      +  "description": "Exact country filter (parsed location component); ISO country code or name, matched case-insensitively",
      +  "type": "string"
      +}
    • addedInput schema / properties / job_family
      Added value: +{
      +  "description": "Exact ESCO/ISCO job-family label filter",
      +  "type": "string"
      +}
    • addedInput schema / properties / max_salary
      Added value: +{
      +  "description": "Maximum salary (matches postings whose range starts at or below this); requires salary_currency",
      +  "type": "number"
      +}
    • addedInput schema / properties / min_salary
      Added value: +{
      +  "description": "Minimum salary (matches postings whose range reaches at least this); requires salary_currency",
      +  "type": "number"
      +}
    • changedInput schema / properties / provider / description
      Previous value: -"ATS provider filter. Enum: greenhouse, lever, ashby, workday, smartrecruiters, workable, recruitee, rippling, personio, teamtailor, oracle, ukg"New value: +"Provider filter"
    • addedInput schema / properties / salary_currency
      Added value: +{
      +  "description": "3-letter ISO currency code (e.g. USD) the min_salary/max_salary bounds are in; required when either bound is set",
      +  "type": "string"
      +}
    • addedInput schema / properties / state
      Added value: +{
      +  "description": "Exact state/region filter (parsed location component)",
      +  "type": "string"
      +}
    • addedInput schema / properties / workplace_type
      Added value: +{
      +  "description": "Workplace type filter",
      +  "type": "string"
      +}
  3. Addedv1.6.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries full behavioral burden and does so richly. It discloses open-roles-by-default, salary parsing variability, exact-match location semantics, incomplete job_family classification, missing employment_type for google-jobs/meta-jobs, and unavailable posted_at for meta-jobs/tesla-jobs. These caveats are exactly what an agent needs to interpret results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and carries essential caveats, but it is a single dense paragraph and redundantly repeats the provider, workplace_type, and sort enums that already exist in the input schema. Some restructuring or trimming of duplicated enum lists would make it tighter.

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

Completeness5/5

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

For a 19-parameter search tool with no annotations and no output schema, the description covers the necessary semantic context: data scope, provider coverage, filter semantics, and known data gaps. An agent can confidently construct correct queries and interpret partial or unexpected results from this description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description substantially enriches parameter meaning: salary_currency's necessity, min/max_salary semantics, city/state/country exact-match behavior versus the free-text location, job_family's exact ISCO/ESCO label, and the include_closed default. This goes well beyond the baseline 3 and actually explains how filter parameters behave.

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 opens with a specific verb and resource: 'Search the jobs dataset (all companies' live postings).' It then enumerates the exact ATS board providers and big-tech platforms covered, which clearly distinguishes this aggregated search from sibling board-specific tools like jobs_greenhouse_board or companies like datasets_jobs_company_item.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the usage context clear: it is for full-text and faceted search across every discovered company posting, not a single employer or board. However, it does not explicitly name alternatives or state when NOT to use it, so it stops short of a 5.

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

Deploy Server

Other Tools