Resolves a company's live hiring signal from Greenhouse's public ATS JSON, including open requisitions, departments and locations hiring, remote share, hiring intensity, and newest posting.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Company Enrichment MCP enrich stripe.com and tell me how hard they're hiring"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server that turns a company domain into a live, normalized enrichment record — for any MCP client (Claude Desktop, Cursor, Cline, Continue, or your own agent).
Give it stripe.com and get back, in one call, firmographics + verified business contacts + a
tech-stack fingerprint + social links and a live hiring signal — the buying-intent layer that
static enrichment databases can't carry:
company_name · industry · hq_country · tech_stack · contacts (MX-graded) · social_links · hiring{ats_vendor, open_reqs, departments, locations, remote_share, intensity, newest_posting}
Live from source, never a resold database. Every field is read this call from the company's own public website, public DNS/MX, and public applicant-tracking JSON. No stale cache, no third-party data broker, no paid key to hold.
Zero keys, zero account, free COGS. All upstreams are keyless and public.
The hiring signal is the moat. The hiring{} block is derived live from 8 ATS platforms
(Greenhouse · Lever · Ashby · SmartRecruiters · Workday · Recruitee · Workable · BambooHR) — a
real buying-intent signal (who is hiring, how hard, in which departments) that resold-DB enrichers
do not ship because they sell static firmographics.
One parse dependency. cheerio for robust HTML extraction — no MCP SDK, no 90-package
transitive tree dragged into your agent's trust boundary.
Honest, never fabricated. Thin crawls are flagged (enrichment_status), absent fields stay
null, placeholder/noreply addresses are dropped.
Requires Node.js ≥ 18.
Add to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"company-enrichment": {
"command": "npx",
"args": ["-y", "github:rezearcher/company-enrichment-mcp"]
}
}
}Point the client at the same command (npx -y github:rezearcher/company-enrichment-mcp) as a stdio
server. In Cursor: Settings → MCP → Add new server → type command.
git clone https://github.com/rezearcher/company-enrichment-mcp
cd company-enrichment-mcp
npm install
node server.mjs # speaks MCP over stdio
npm test # real client handshake + live-data roundtripRelated MCP server: company-enrichment
Tool | What it does |
| Full live record(s) for one or more domains: firmographics, MX-graded contacts, tech-stack fingerprint, social links, and the live hiring block. Args: |
| Cheap buying-intent probe — just the live hiring block for one company, skipping the site crawl. Resolves the ATS across 8 platforms and returns open reqs, departments/locations hiring, remote share, intensity, newest posting. Args: |
| Grade a domain's mail deliverability from public DNS (keyless, free). Returns |
| The record schema, the 8 ATS platforms, the live/keyless data policy, and the public-business-data-only legal scope. No network call. |
Ask your assistant: "Enrich stripe.com and ramp.com, and tell me which is hiring harder." The model calls:
{ "name": "enrich_company",
"arguments": { "domains": ["stripe.com", "ramp.com"] } }and gets back a records[] array — each a unified company record whose hiring.hiring_intensity
(none/low/med/high) and hiring.open_reqs_count answer the question directly.
Or, for a fast buying-intent check without the full crawl: "Is bunq hiring right now?" →
{ "name": "company_hiring_signal", "arguments": { "company": "bunq.com" } }{
"input_domain": "stripe.com",
"canonical_domain": "stripe.com",
"company_name": "Stripe",
"description": "...",
"industry": "...",
"hq_country": "US",
"social_links": ["https://twitter.com/stripe", ...],
"tech_stack": [ { "name": "Next.js", "category": "..." }, ... ],
"contacts": { "emails": [ { "email": "...", "mx": true, "deliverability_grade": "B" } ], "phones": [...] },
"hiring": {
"ats_vendor": "greenhouse", "open_reqs_count": 725, "hiring_intensity": "high",
"departments_hiring": [...], "locations_hiring": [...], "remote_share": 0.18,
"newest_posting_at": "2026-10-29T..."
},
"source_freshness": "live",
"enrichment_status": "ok"
}Resold-database enrichers (the common Apify/marketplace pattern) return whatever was in a broker's
last crawl — often months stale — and need a paid data key behind them. This server reads each
company now, from sources the buyer would otherwise have to integrate and maintain themselves: a
heterogeneous website layout, a DNS/MX posture, and eight different ATS JSON shapes that drift and
that companies migrate between. That upkeep is the point — a scheduled canary
(.github/workflows/smoke.yml) exercises the live path on every push and daily and fails loudly the
moment an upstream reshapes. And because the hiring block is computed live, it reflects today's open
reqs, not a snapshot — the signal a prospector actually wants.
PUBLIC business data only — published firmographics, published business contact points (role inboxes, switchboard, public social profiles), and public ATS postings. No login, no personal/consumer PII, no scraped individual profiles, no third-party database. Respect each source's terms and rate limits.
MIT © Grey Ridge Signals Group LLC.
company-enrichment-cli — the same
enrichment core as a plain command-line tool (npx github:rezearcher/company-enrichment-cli stripe.com).
jobs-mcp-server — the raw 8-ATS job feed as an MCP server, when you want the postings themselves rather than a company-level signal.
Grade the email deliverability posture of a domain from its public DNS, keyless and free (no paid verification API). Returns {domain, resolves, has_mx, mx_hosts[], grade}. Grades: B = valid MX present (mailbox existence not probed), D = resolves but no MX (mail unlikely), F = does not resolve. Use before trusting a role inbox or scoring a lead. Accepts a bare domain or an email address (the domain part is used).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | A domain ("stripe.com") or an email ("jobs@stripe.com"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: keyless and free, no paid API, DNS-only, and the explicit limitation that mailbox existence is not probed. It also enumerates the grade meanings (B/D/F) so the agent can interpret results without a follow-up call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then return shape, then grade legend, then usage trigger. Every sentence carries information; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description spells out the returned object shape and the meaning of each grade, plus the key limitation. For a one-parameter read tool, an agent has everything needed to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents that a domain or email is accepted, so the baseline is 3. The description adds the behavioral detail that the domain part of an email is extracted, which is marginally useful beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource: 'Grade the email deliverability posture of a domain from its public DNS.' The grading semantics and the keyless/DNS-only scope make it unmistakable against siblings like enrich_company or company_hiring_signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete trigger ('Use before trusting a role inbox or scoring a lead') and implicitly rules out paid verification APIs. It does not name a specific alternative tool or state when-not to call it, which keeps it 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.
Return ONLY the live hiring signal for one company — a cheap buying-intent probe that skips the full site crawl. Resolves the company to its applicant-tracking system across 8 ATS platforms (Greenhouse, Lever, Ashby, SmartRecruiters, Workday, Recruitee, Workable, BambooHR) and returns {ats_vendor, ats_token, careers_url, open_reqs_count, departments_hiring[], locations_hiring[], remote_share, hiring_intensity (none/low/med/high), newest_posting_at}. This is the category-unique signal no resold-database enricher carries. Keyless, live from public ATS JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company slug ("bunq") or domain ("bunq.com"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does well: it discloses keyless access, live public ATS JSON as the source, the eight supported ATS platforms, and the returned fields. It does not explicitly describe failure modes, rate limits, or read-only status beyond implication, but the major operational traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and value, then supplies implementation details. It is dense but the enumerated platforms and return fields are useful for invocation and interpretation; still, it could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description is complete enough: it explains the data source, supported platforms, returned fields, and the lightweight nature of the probe. An agent has what it needs to decide and call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage and the only parameter is documented there as a company slug or domain. The description reinforces that this operates on one company but adds no additional syntax, format, or edge-case guidance beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: returns a live hiring signal for one company. It also distinguishes the tool from broader alternatives by calling it a cheap buying-intent probe that skips the full site crawl, so an agent can identify its role without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly positions this as a lightweight alternative to a full crawl or resold-database enrichment, which gives useful usage context. However, it does not explicitly name sibling tools or state when not to use this tool, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich one or more companies from their DOMAIN into a unified record, read live from the company's own public site + public DNS + public ATS JSON (no resold database, no API key). Each record carries: company_name, legal_name_guess, description, industry, founded_year, employee_size_hint, hq_country, logo_url, social_links[], tech_stack[] (fingerprinted), contacts{emails[] with MX deliverability grade, phones[]}, and a live hiring{} block (ATS vendor, open_reqs_count, departments/locations hiring, remote_share, hiring_intensity, newest_posting_at). Records are deduped by canonical domain; thin crawls are flagged (enrichment_status), never fabricated. Input accepts domains ("stripe.com") or bare names ("stripe").
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Company domains or names to enrich (e.g. ["stripe.com","ramp.com"]). At least one required. | |
| maxPages | No | Max public pages crawled per company (default 4, max 12). | |
| includeTech | No | Include the tech-stack fingerprint. Default true. | |
| maxCompanies | No | Cap the number of companies processed (0 = no cap). Default 0. | |
| includeHiring | No | Include the live multi-ATS hiring signal (the buying-intent moat). Default true. | |
| includeContacts | No | Include emails (MX-graded) + business phones. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it names the live sources, states that no API key or resold database is used, explains canonical-domain deduplication, and says thin crawls are flagged rather than fabricated. It does not mention rate limits, latency, or failure behavior, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and the description is dense but organized, moving from inputs to sources to returned record fields. The long enumeration of record fields is justified because there is no output schema, though it makes the definition less scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex enrichment tool with no output schema and no annotations, the description supplies the key context an agent needs: accepted input forms, source model, returned fields, deduplication, and thin-crawl flagging. It is nearly complete, with only operational details like rate limits or error handling absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented in the input schema. The description adds that input accepts domains like "stripe.com" or bare names like "stripe", but this largely repeats what the schema already says, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: enrich companies from domains into a unified record, using live public sources rather than a resold database. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling company_hiring_signal, even though hiring data is one of its outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus company_hiring_signal, check_email_domain, or list_capabilities. The use case is implied by the description, but no conditions, exclusions, or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the enrichment record schema, the 8 ATS platforms behind the hiring signal, the live/keyless/free-COGS data policy, and the public-business-data-only legal scope. No network call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose a meaningful behavioral trait: 'No network call', meaning it is a static/near-zero-cost lookup that cannot fail on connectivity. It also surfaces two policy dimensions an agent would otherwise discover only by trial (live/keyless/free-COGS data policy, public-business-data-only legal scope). It does not state the response shape (prose vs. structured), which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the enumerated content, and the trailing 'No network call' is a high-value, low-cost addition. Nothing is repeated from the name or title and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-annotation, no-output-schema documentation tool, the description covers the essential scope: what content comes back, the data policy, the legal boundary, and that no network access occurs. The only gap is not indicating the form of the returned content (e.g., text vs. JSON), which matters slightly since there is no output schema to explain it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema confirms an empty object with additionalProperties false, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates precisely what the tool returns: the enrichment record schema, the 8 ATS platforms, the data policy, and the legal scope. That is enough for an agent to see it is a metadata/documentation tool rather than a data lookup like its siblings (enrich_company, company_hiring_signal). It stops short of a single crisp 'returns API capability documentation' framing, so it is clear but not maximally sharp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit statement of when to call this versus the sibling tools — no 'call this first to understand the schema before using enrich_company' guidance, and no exclusions. Usage is only inferable from the listed contents. The 'No network call' note hints it is a cheap discovery step but does not frame it as such.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_email_domaincompany_hiring_signalenrich_companylist_capabilitiesScored across 4 tools
Each tool has a distinct action (probe hiring, describe schema, full enrich, grade email domain), and descriptions explicitly frame the lighter tools as cheap pre-checks versus the full enrich_company crawl. The only residual ambiguity is that company_hiring_signal and check_email_domain surface data already contained inside enrich_company's output, so an agent must judge when the lite path is worth it.
Three of four tools use a clean verb_noun snake_case pattern (list_capabilities, enrich_company, check_email_domain). company_hiring_signal breaks the pattern as a noun phrase, a minor deviation in an otherwise predictable scheme.
Four tools is small but well matched to a focused enrichment server: one meta/help tool, one heavy enrichment call, and two cheap probes. It sits at the lean edge of the 3-15 range, with the two probe tools arguably being extractable features of enrich_company rather than independent capabilities.
The surface covers the core enrichment lifecycle well: schema discovery, full domain-based enrichment with contacts/tech/hiring, plus targeted hiring and email-deliverability probes. Gaps are minor, e.g. no explicit bulk/batch status retrieval or follow-up lookup by a previously returned canonical domain, but agents can work around these by re-calling enrich_company.
Enrich any domain into a full company profile with firmographics and buying signals.
B2B data enrichment: verified work emails, phones, firmographics, tech stack, hiring signals.
Extracts verified emails, social links, 40+ tech stack signals, pricing tiers, and company summary
Domain & brand intelligence: company enrichment, tech stack detection, brand research.