Skip to main content
Glama
Sign In
subimpact

subimpact-data-mcp

Official
by subimpact
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

company_career_jobs

Scrape live job postings from company career pages and ATS boards like Greenhouse, Lever, Ashby, and Workday, normalize them into one schema, and monitor for new jobs.

Instructions

Company Career Page Monitor & ATS Jobs API

Get live job postings straight from company career pages — Greenhouse, Lever, Ashby, Workday, SmartRecruiters — normalized into one schema, with new-job monitoring for HR-tech, VCs, and AI agents.

Pricing (pay per event, billed to your Apify account): Job scraped: $0.001; Company monitored: $0.02; platform usage billed to your account.

Runs on Apify as subimpact/ats-jobs-api.

Input Schema

NameRequiredDescriptionDefault
_maxItemsNoHow many dataset items to return to the model (1-1000, default 50). Truncates the response only; it does not change what the Actor collects or charges for.
companiesYesCareers page or ATS board URLs to scrape, e.g. https://boards.greenhouse.io/anthropic, https://jobs.ashbyhq.com/OpenAI, https://nvidia.wd5.myworkdayjobs.com/en-US/NVIDIAExternalCareerSite, https://recruiting.ultipro.com/{tenant}/JobBoard/{boardId}, https://{company}.jobs.personio.de
onlyNewJobsNoOutput only jobs not seen in previous runs (state persists across runs). Ideal for scheduled runs with a webhook to Slack/CRM.
maxTotalJobsNoGlobal cap on jobs delivered across ALL companies in one run. Defaults to 200 to prevent bill shock — raise it once you know what you need, or set 0 for no limit. Monitoring state is tracked for every scraped job regardless of this cap.
_maxChargeUsdNoPer-run spending cap in USD (default 0.5). Passed to Apify as the run option maxTotalChargeUsd, so the run stops when it reaches this charge.
includeDetailsNoFetch each job's detail page for richer fields (Workday: location, employment type, description). Adds one request per job.
stateStoreNameNoNamed key-value store used to remember previously seen jobs.ats-jobs-state
maxJobsPerCompanyNoCap the number of jobs collected per company. 0 = no limit.
includeDescriptionNoFetch full description text/HTML for each job. Slower and uses more requests, especially on Workday and Ashby.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.4/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 usefully discloses the pay-per-event pricing model, Apify billing, and that it runs as an Apify Actor, but it does not describe auth requirements, rate limits, persistence of monitoring state across runs, or other operational constraints 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?

The definition is reasonably short and front-loads the core capability before pricing and platform provenance. Some marketing language such as 'for HR-tech, VCs, and AI agents' is not essential, but the overall structure is efficient.

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 nine-parameter tool with no output schema, the description explains the source coverage and cost model but does not describe what the returned dataset looks like beyond saying it is normalized. It is adequate for invocation but leaves return-shape expectations partly inferred.

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 input schema already documents all nine parameters thoroughly. The description adds no parameter-specific meaning beyond repeating that monitoring exists and that results are normalized; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: get live job postings from company career pages/ATS boards, normalized into one schema. It names supported platforms and mentions monitoring, so the core purpose is clear. It does not explicitly distinguish itself from sibling tools like google_jobs or google_maps_places.

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 career page monitoring and notes it is for HR-tech, VCs, and AI agents, but it does not explicitly say when to choose this over google_jobs or other job-related siblings. The monitoring angle is present, but alternatives and exclusions are left to inference.

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