Skip to main content
Glama
paulet4a-commits

webdatatools-leads-mcp

by paulet4a-commits
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

hiring_signals

Scrape company job postings from Greenhouse, Lever, Ashby, and Workable boards to return one row per job or a company hiring summary for recruiting and sales intelligence.

Instructions

Scrape company job postings and hiring signals from Greenhouse, Lever, Ashby and Workable job boards — one row per job, or one hiring summary per company. Billed to your own Apify account: ~$0.002 per result (Apify free-plan price, lower on paid plans).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
companiesYesCompanies — Enter the companies whose job board you want to scrape. Use the ATS slug on its own, e.g. stripe, or paste a full job-board URL, e.g. https://boards.greenhouse.io/stripe, https://jobs.lever.co/spotify, https://jobs.ashbyhq.com/ashby, https://apply.workable.com/blueground/, https://jobs.smartrecruiters.com/smartrecruiters, https://bunq.recruitee.com, https://personio.jobs.personio.de, https://storytel.teamtailor.com, https://euna.bamboohr.com/careers/list or https://<tenant>.wd<N>.myworkdayjobs.com/<site>. A bare slug is probed against every board except Workday (which needs a full URL — a tenant and a site, not just a slug) and every board that actually has postings is returned. Example: ["stripe"].
outputModeNoOutput mode — Choose what one dataset row means. Pick "One row per job" to get every open posting (best for job aggregators and recruiters), or "One row per company" to get a single hiring summary per company with job counts, department and location breakdowns and a hiring-velocity score (best for sales intelligence and competitor watching). Options: jobs = One row per job; companies = One row per company (hiring summary).jobs
maxJobsPerCompanyNoMax jobs per company — Enter how many of the newest postings to keep per company, e.g. 200. This caps both cost and row count in "One row per job" mode. It is deliberately ignored in "One row per company" mode, where the summary always counts the whole board so totals and hiring velocity stay accurate.
includeDescriptionsNoInclude job descriptions — Turn this on to add the full job description as plain text (HTML stripped, truncated to 5,000 characters). Leave it off for faster, smaller runs — on Workable it also saves one extra request per job, because that board only serves descriptions from a per-job endpoint. SmartRecruiters and Workday never return a description here (their list endpoints carry no job body), regardless of this setting.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations the description carries the full behavioral burden, and it delivers unusually well: it discloses billing to the user's own Apify account with a per-result price, notes that maxJobsPerCompany is deliberately ignored in company mode, and warns that SmartRecruiters/Workday never return descriptions. It omits failure modes and any rate/quota behavior beyond cost.

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?

A single dense paragraph with the core purpose and pricing front-loaded; every clause carries information. It is slightly run-on, but nothing is padding.

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 four-parameter scraper with no output schema and no annotations, the description covers output shape, cost, and per-source limitations well enough to call it correctly. Return-field details are left implicit, which is a minor gap given no output schema exists.

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 description coverage is 100%, so the schema already documents all four parameters in detail; the description adds only the cost framing around result count. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb+resource ('Scrape company job postings and hiring signals') and names the exact ATS sources (Greenhouse, Lever, Ashby, Workable). The output-shape clause ('one row per job, or one hiring summary per company') further distinguishes it from the sibling remote_jobs_aggregator.

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?

Each outputMode option carries an explicit 'best for' context (job aggregators/recruiters vs. sales intelligence/competitor watching), which is genuine when-to-use guidance. It stops short of naming or excluding sibling tools, so it is clear context without full alternative routing.

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