webdata-tools-mcp

Find companies hiring for given roles

find_hiring_companies

Read-onlyIdempotent

Find companies hiring for roles you care about from jobs-page URLs or job-search phrases, with counts, freshness, seniority, and locations for account prioritization.

Instructions

Buying-intent signal: which companies are hiring for the roles you care about, how many roles, how fresh, and seniority/locations. Give target accounts (their jobs-page URLs on Greenhouse, Lever, Ashby, Workday, SmartRecruiters, Recruitee, Personio, Teamtailor) and/or job-search phrases to discover companies. Runs the Apify Actor tacps126/hiring-signals on your Apify account (about $0.01 per company with a matching signal; companies without one are free; spend per call is capped at $0.5).

Input Schema

TableJSON Schema

Name	Required	Description
`searches`	No	Job-search phrases to discover companies you do not know yet, e.g. "head of security".
`companies`	No	Target accounts' jobs-page URLs, e.g. "https://boards.greenhouse.io/stripe".
`locations`	No	Keep roles in these locations.
`max_items`	No	Maximum results to return (default 50, max 500). Cost scales with this.
`extra_input`	No	Advanced: extra Actor input fields, merged over the defaults.
`role_keywords`	No	A role counts when its title contains any of these words, e.g. ["data engineer","security"]. Empty = every role.
`posted_within_days`	No	Only roles posted in the last N days.

Output Schema

TableJSON Schema

Name	Required	Description
`tool`	Yes	Name of the tool that produced the result.
`count`	Yes	Number of records the Actor returned.
`items`	Yes	The records. Long text fields are shortened to 600 characters.
`shown`	Yes	Number of records included in `items` (can be lower than count when the result is long).
`truncated`	Yes	True when records were left out to keep the result short; ask for fewer items.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.1Oct 17, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "count": {
+      "description": "Number of records the Actor returned.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "items": {
+      "description": "The records. Long text fields are shortened to 600 characters.",
+      "items": {
+        "additionalProperties": {},
+        "propertyNames": {
+          "type": "string"
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "shown": {
+      "description": "Number of records included in `items` (can be lower than count when the result is long).",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "tool": {
+      "description": "Name of the tool that produced the result.",
+      "type": "string"
+    },
+    "truncated": {
+      "description": "True when records were left out to keep the result short; ask for fewer items.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "tool",
+    "count",
+    "shown",
+    "truncated",
+    "items"
+  ],
+  "type": "object"
+}

First observedv0.1.0Oct 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/open-world, but the description goes further with billing and safety context: it runs a specific Apify Actor on the caller's own Apify account, costs ~$0.01 per company with a matching signal, companies without a signal are free, and spend is capped at $0.5 per call. That is exactly the cost/auth/limit disclosure annotations cannot provide.

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?

Front-loaded with the value proposition and the key scoping fact (which companies are hiring) before inputs and cost. It is a single dense paragraph; the 'Buying-intent signal' opener is slightly marketing-flavored, but little of the text is wasted.

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?

With an output schema present, annotations covering the safety profile, and full schema description coverage, the description supplies everything else an agent needs: the two discovery modes, supported ATS sources, and the cost ceiling. Nothing required for correct invocation is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents all seven parameters. The description adds meaning by enumerating the supported ATS boards (Greenhouse, Lever, Ashby, Workday, SmartRecruiters, Recruitee, Personio, Teamtailor), which constrains what the 'companies' URL values may be — a modest but real addition.

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 — discovering which companies are hiring — and enumerates the output dimensions (how many roles, freshness, seniority/locations), so the agent knows this returns companies rather than job listings. The 'discover companies you do not know yet' framing implicitly separates it from a single-company job fetch like get_company_jobs.

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?

Explains the two input modes clearly: pass target-account jobs-page URLs for known accounts, and/or job-search phrases to discover unknown companies. It gives context for when each mode applies but names no alternative sibling tool and states no exclusions.

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

Deploy Server