New jobs from 13,000+ company career sites, newest first, for Claude Code, Codex and any agent.
Scored across 6 tools
Each tool has a clearly distinct purpose: count_jobs previews search size, search_jobs returns results, get_job refreshes one record, get_changes tracks lifecycle changes, list_my_jobs shows unlocked roles, and get_usage checks credits. Descriptions explicitly differentiate the free count from the paid search and explain when to use each. No overlapping or confusing boundaries exist.
All tool names follow a consistent snake_case verb_noun pattern (count_jobs, get_changes, get_job, get_usage, list_my_jobs, search_jobs). There are no mixed conventions or vague verbs. The naming is predictable and readable.
Six tools is well-scoped for a job search and tracking server. Each tool covers a distinct operation (search, count, get, changes, list, usage) and none feels redundant. The count is neither thin nor heavy.
The surface covers search, preview, single-record retrieval, change tracking, unlocked job listing, and usage checks, which is a solid lifecycle for job discovery. However, it lacks a way to retrieve full job descriptions (explicitly deferred to an external web tool) and there is no explicit tool to unlock or manage saved jobs beyond listing them. These are minor gaps manageable with workarounds.
Count the roles a search_jobs call would match, up to 1,000. Free: no jobs returned, no credits used.
Use it to narrow a search (add a location, exclude words, posted_within_hours) before paying for results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Whole words matched in the title or company, e.g. "product manager" or "quant". Empty for any. | |
| roles | No | Several titles at once, matching any, e.g. ["Product Manager", "Software Engineer"]. Up to 40. | |
| family | No | "product_adjacent" finds product, product marketing, growth, customer success, forward deployed and business operations titles in one search; query narrows within it. | any |
| remote | No | Only remote roles. | |
| source | No | Only roles from one source (gh is Greenhouse), or "any". | any |
| exclude | No | Leave out titles containing any of these words, e.g. "senior staff intern". | |
| location | No | One country ("United States", "UK", "India"), or a city or state as written. Empty for anywhere. | |
| locations | No | Several places at once, matching any, e.g. ["United States", "London", "Remote"]. Up to 8. | |
| experience | No | Years of experience the posting asks for; any of "0-1", "1-3", "3-5", "5-8", "8+", "not_stated" (we read the posting and it names none) and "unchecked" (not read yet, or no text to read: many big-company and Workday roles). Include both unless you mean to drop them. | |
| posted_within_hours | No | Only roles posted within this many hours; 0 for any time. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint, so the safety profile is covered. The description adds value beyond those fields: the 1,000-result cap and the billing behavior (free, no jobs returned, no credits used), which an agent needs in order to decide whether to call this instead of search_jobs.
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 short sentences, cap and cost stated first, then the usage rationale. No wasted text.
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 free counting tool with rich annotations and an output schema, the description covers the essentials: what is counted, the cap, and the cost model. Nothing critical is missing, though it could note that results are an approximation of search_jobs matching.
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 10 parameters are already documented with examples and enum semantics. The description adds only a passing reference to location, exclude and posted_within_hours as narrowing levers, so the 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?
States a specific verb+resource (count roles) and precisely scopes it as an equivalent of what search_jobs would match, with a hard cap of 1,000. Naming search_jobs lets an agent distinguish it from get_job, list_my_jobs, and the other siblings without opening a 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?
Explicitly says to use it to narrow a search (add a location, exclude words, posted_within_hours) before paying for results, which effectively positions it as the free preview of search_jobs. It lacks an explicit when-not/no-op statement, but the routing condition is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get new, updated, reopened, and closed jobs. Save next_cursor for the next check.
Excludes baseline imports. History lasts 90 days; expired cursors need a fresh search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return, 1 to 20. | |
| cursor | No | next_cursor from your last get_changes call; 0 starts from the beginning of the 90-day history. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: baseline imports are excluded, history is capped at 90 days, and cursors expire. That retention/expiry detail is exactly the kind of trait annotations cannot express.
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?
Three short clauses, all load-bearing: scope of returned changes, cursor persistence instruction, and retention/expiry caveat. Fully front-loaded with no 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?
With an output schema present, return-value structure needs no prose, and the description covers the two parameters, retention, and polling mechanics. An agent has everything needed to call it correctly; only sibling routing is left implicit.
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%, so the baseline is 3, but the description adds meaning the schema lacks: that the cursor represents a point in a 90-day window and that expiry forces a fresh start. This complements the schema's '0 starts from the beginning' note rather than repeating it.
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?
States a specific verb ('Get') and enumerates exactly what is returned: new, updated, reopened, and closed jobs. This is enough to distinguish it as a change-feed tool from list_my_jobs or search_jobs, though it never names those siblings to make the distinction explicit.
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 clear operational context: it is a polling tool ('Save next_cursor for the next check') and states that expired cursors require a fresh search, which is a real usage condition. It stops short of naming an alternative tool for the restart case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a job's metadata, original posting and application URLs, and latest known status.
No job description is returned. Search already includes these fields; use this to refresh one record.
Check closed_at and last_checked before applying. Reading the source page needs a separate web tool.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | A job id from search results, e.g. "gh:stripe:1234567". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, so the bar is lower. The description still adds genuine non-structured context: no job description body is returned, the source page must be fetched via another tool, and closed_at/last_checked gate a decision. It stops short of noting staleness or null-field behavior, so not 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?
Three short sentences, each earning its place: what it returns, how it differs from search, and what to check before acting. Scoping constraint is front-loaded.
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?
An output schema exists so return-field enumeration is unnecessary, and the description still covers the gaps an agent needs: field exclusions, the decision-relevant last_checked/closed_at hints, and the out-of-band step for the source page. Nothing material is missing for a one-parameter read tool.
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 the single job_id parameter already documents its format with an example ('gh:stripe:1234567'). The description adds no further parameter syntax or constraints, so the baseline 3 for schema-does-the-work 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?
States a specific verb (get) and resource (a job) and enumerates the returned fields: metadata, original posting and application URLs, latest known status. It also explicitly scopes out what is NOT returned ('No job description is returned'), which separates it from search_jobs without the agent opening a 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?
Gives an explicit when-to-use ('use this to refresh one record') plus a when-not ('Search already includes these fields'), and adds a pre-flight condition ('Check closed_at and last_checked before applying'). The alternative path for the source page is named ('needs a separate web tool').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your remaining monthly allowance. This tool doesn't use your data allowance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a useful non-obvious behavioral fact: calling this tool does not consume the user's data allowance. It does not describe return format or rate limits, but with an output schema present, that gap is acceptable.
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, both earning their place. The purpose is front-loaded in the first sentence, and the second sentence adds a concrete behavioral caveat without padding or repetition.
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?
Given the tool's low complexity (zero parameters), rich annotations, and an existing output schema, the description covers what an agent needs: it states the purpose and adds that the call does not consume data allowance. A minor gap is that 'monthly allowance' is not further specified, but the output schema likely supplies return details.
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 has zero parameters, so there are no parameter semantics to explain. The input schema is empty and fully covered at 100%. The description appropriately does not invent parameter details. Baseline 4 applies for a zero-parameter tool.
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: 'Check your remaining monthly allowance.' This clearly identifies a read-only usage/allowance check. However, it does not differentiate itself from the sibling tools, which are all job-related (count_jobs, get_changes, get_job, my_jobs, search_jobs), so an explicit contrast is missing.
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 provides no guidance on when to use this tool versus alternatives. It does not mention the purpose of checking allowance, any prerequisites, or when another tool might be more appropriate. The only contextual note is a behavioral fact, not a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List roles this account already unlocked, newest first. Free, and doesn't use credits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return, 1 to 100. | |
| offset | No | Skip this many results; pass next_offset from the previous page. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds genuinely new context beyond that: the result ordering (newest first) and the fact that the call is free and consumes no credits, which affects agent planning.
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 short sentences, no wasted words, with the scoping ('already unlocked', 'newest first') front-loaded ahead of the cost note. Nothing could be trimmed without losing information.
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?
With an output schema present, return values need not be described, and both parameters are documented in the schema. The description supplies scope, ordering and cost, covering everything needed to invoke it correctly; only the sibling routing is left implicit.
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% and both parameters are fully documented in the schema, including the next_offset pagination hint. The description adds nothing about limit/offset, so the 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?
States a specific verb and resource ('List roles this account already unlocked') plus ordering ('newest first'), which is more precise than the title 'My unlocked jobs'. It implies a distinction from search_jobs and count_jobs, but never names them explicitly, so sibling differentiation is left to inference.
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 'Free, and doesn't use credits' note is a useful cost signal that helps an agent prefer this over credit-consuming siblings. However, no alternative tool is named and no condition for choosing it over search_jobs or count_jobs is given, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find open jobs checked within 24 hours. Up to 20 results, newest posted first.
query matches whole words in the title or company (e.g. "product manager", "quant", "ml engineer").
location takes a country ("United States", "UK", "India") or a city or state as written.
exclude drops titles containing any of these words ("senior staff intern").
remote=true keeps remote roles only. posted_within_hours keeps recent postings.
Call count_jobs first (free) to size a search before spending credits.
Use published_since for source dates and discovered_since for new discoveries excluding baselines.
Follow next_offset to paginate. No JD text is returned.
experience keeps roles whose posting asks for these years of experience: any of
"0-1", "1-3", "3-5", "5-8", "8+", "not_stated" (read, names none), "unchecked" (not read, or no text).
Read from each posting; include not_stated and unchecked unless you mean to drop those roles.
family="product_adjacent" finds product, product marketing, growth, customer success,
forward deployed and business operations titles in one search; query narrows within it.
roles takes several titles at once (["Product Manager", "Software Engineer"]) and matches any;
locations likewise (["United States", "London", "Remote"]).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page, 1 to 20. | |
| query | No | Whole words matched in the title or company, e.g. "product manager" or "quant". Empty for any. | |
| roles | No | Several titles at once, matching any, e.g. ["Product Manager", "Software Engineer"]. Up to 40. | |
| family | No | "product_adjacent" finds product, product marketing, growth, customer success, forward deployed and business operations titles in one search; query narrows within it. | any |
| offset | No | Skip this many results; pass next_offset from the previous page. | |
| remote | No | Only remote roles. | |
| source | No | Only roles from one source (gh is Greenhouse), or "any". | any |
| exclude | No | Leave out titles containing any of these words, e.g. "senior staff intern". | |
| location | No | One country ("United States", "UK", "India"), or a city or state as written. Empty for anywhere. | |
| locations | No | Several places at once, matching any, e.g. ["United States", "London", "Remote"]. Up to 8. | |
| experience | No | Years of experience the posting asks for; any of "0-1", "1-3", "3-5", "5-8", "8+", "not_stated" (we read the posting and it names none) and "unchecked" (not read yet, or no text to read: many big-company and Workday roles). Include both unless you mean to drop them. | |
| published_since | No | ISO date or time: only roles the company dated on or after it. Empty for any. | |
| discovered_since | No | ISO date or time: only roles we first found on or after it, excluding baseline imports. Empty for any. | |
| posted_within_hours | No | Only roles posted within this many hours; 0 for any time. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive safety. The description adds cost behavior ('spending credits'), result recency ('checked within 24 hours'), ordering, pagination, and output limitation ('No JD text is returned'), which are not in the annotations.
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 usage, then organized by parameter, which suits a 14-parameter search. It is somewhat long because many parameter sentences duplicate the already-complete schema, but the structure remains clear.
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?
Output schema exists, so return values need not be explained; the description still notes the absence of JD text and pagination behavior. Together with annotations and 100% schema coverage, it gives an agent enough context to call the tool 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?
Schema description coverage is 100%, so the schema already documents all 14 parameters. The description mostly repeats those same parameter details (query matching, location formats, experience enums) rather than adding substantial new semantics beyond the schema.
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 first sentence states a specific verb and resource ('Find open jobs') with scope ('checked within 24 hours') plus result ordering. It explicitly names count_jobs as the sizing alternative, distinguishing it from that sibling and from retrieval tools like get_job.
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?
Explicitly tells the agent to call count_jobs first before spending credits, when to use published_since vs discovered_since, and to follow next_offset for pagination. It also states no JD text is returned and advises including not_stated/unchecked unless intentionally dropping roles.
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.
count_jobs1 field changedInput schema / properties / source / enumPrevious value: -[
- "any",
- "gh",
- "ashby",
- "lever",
- "workday",
- "amazon",
- "microsoft",
- "netflix",
- "apple",
- "google",
- "meta",
- "eightfold",
- "jibe",
- "phenom",
- "atlassian",
- "successfactors"
-]New value: +[
+ "any",
+ "gh",
+ "ashby",
+ "lever",
+ "workday",
+ "amazon",
+ "microsoft",
+ "netflix",
+ "apple",
+ "google",
+ "meta",
+ "eightfold",
+ "jibe",
+ "phenom",
+ "atlassian",
+ "successfactors",
+ "radancy"
+]search_jobs1 field changedInput schema / properties / source / enumPrevious value: -[
- "any",
- "gh",
- "ashby",
- "lever",
- "workday",
- "amazon",
- "microsoft",
- "netflix",
- "apple",
- "google",
- "meta",
- "eightfold",
- "jibe",
- "phenom",
- "atlassian",
- "successfactors"
-]New value: +[
+ "any",
+ "gh",
+ "ashby",
+ "lever",
+ "workday",
+ "amazon",
+ "microsoft",
+ "netflix",
+ "apple",
+ "google",
+ "meta",
+ "eightfold",
+ "jibe",
+ "phenom",
+ "atlassian",
+ "successfactors",
+ "radancy"
+]count_jobs1 field changedInput schema / properties / source / enumPrevious value: -[
- "any",
- "gh",
- "ashby",
- "lever",
- "workday",
- "amazon",
- "microsoft",
- "netflix",
- "apple",
- "google",
- "meta",
- "eightfold",
- "jibe",
- "phenom",
- "atlassian"
-]New value: +[
+ "any",
+ "gh",
+ "ashby",
+ "lever",
+ "workday",
+ "amazon",
+ "microsoft",
+ "netflix",
+ "apple",
+ "google",
+ "meta",
+ "eightfold",
+ "jibe",
+ "phenom",
+ "atlassian",
+ "successfactors"
+]search_jobs1 field changedInput schema / properties / source / enumPrevious value: -[
- "any",
- "gh",
- "ashby",
- "lever",
- "workday",
- "amazon",
- "microsoft",
- "netflix",
- "apple",
- "google",
- "meta",
- "eightfold",
- "jibe",
- "phenom",
- "atlassian"
-]New value: +[
+ "any",
+ "gh",
+ "ashby",
+ "lever",
+ "workday",
+ "amazon",
+ "microsoft",
+ "netflix",
+ "apple",
+ "google",
+ "meta",
+ "eightfold",
+ "jibe",
+ "phenom",
+ "atlassian",
+ "successfactors"
+]count_jobs1 field changedInput schema / properties / source / enumPrevious value: -[
- "any",
- "gh",
- "ashby",
- "lever",
- "workday",
- "amazon",
- "microsoft",
- "netflix",
- "apple",
- "google",
- "meta",
- "eightfold",
- "jibe",
- "phenom"
-]New value: +[
+ "any",
+ "gh",
+ "ashby",
+ "lever",
+ "workday",
+ "amazon",
+ "microsoft",
+ "netflix",
+ "apple",
+ "google",
+ "meta",
+ "eightfold",
+ "jibe",
+ "phenom",
+ "atlassian"
+]search_jobs1 field changedInput schema / properties / source / enumPrevious value: -[
- "any",
- "gh",
- "ashby",
- "lever",
- "workday",
- "amazon",
- "microsoft",
- "netflix",
- "apple",
- "google",
- "meta",
- "eightfold",
- "jibe",
- "phenom"
-]New value: +[
+ "any",
+ "gh",
+ "ashby",
+ "lever",
+ "workday",
+ "amazon",
+ "microsoft",
+ "netflix",
+ "apple",
+ "google",
+ "meta",
+ "eightfold",
+ "jibe",
+ "phenom",
+ "atlassian"
+]count_jobs1 field changedInput schema / properties / source / enumPrevious value: -[
- "any",
- "gh",
- "ashby",
- "lever",
- "workday",
- "amazon",
- "microsoft",
- "netflix",
- "apple",
- "google",
- "meta",
- "eightfold"
-]New value: +[
+ "any",
+ "gh",
+ "ashby",
+ "lever",
+ "workday",
+ "amazon",
+ "microsoft",
+ "netflix",
+ "apple",
+ "google",
+ "meta",
+ "eightfold",
+ "jibe",
+ "phenom"
+]search_jobs1 field changedInput schema / properties / source / enumPrevious value: -[
- "any",
- "gh",
- "ashby",
- "lever",
- "workday",
- "amazon",
- "microsoft",
- "netflix",
- "apple",
- "google",
- "meta",
- "eightfold"
-]New value: +[
+ "any",
+ "gh",
+ "ashby",
+ "lever",
+ "workday",
+ "amazon",
+ "microsoft",
+ "netflix",
+ "apple",
+ "google",
+ "meta",
+ "eightfold",
+ "jibe",
+ "phenom"
+]count_jobs1 field changedInput schema / properties / source / enumPrevious value: -[
- "any",
- "gh",
- "ashby",
- "lever",
- "workday",
- "amazon",
- "microsoft",
- "netflix",
- "apple",
- "google",
- "meta"
-]New value: +[
+ "any",
+ "gh",
+ "ashby",
+ "lever",
+ "workday",
+ "amazon",
+ "microsoft",
+ "netflix",
+ "apple",
+ "google",
+ "meta",
+ "eightfold"
+]search_jobs1 field changedInput schema / properties / source / enumPrevious value: -[
- "any",
- "gh",
- "ashby",
- "lever",
- "workday",
- "amazon",
- "microsoft",
- "netflix",
- "apple",
- "google",
- "meta"
-]New value: +[
+ "any",
+ "gh",
+ "ashby",
+ "lever",
+ "workday",
+ "amazon",
+ "microsoft",
+ "netflix",
+ "apple",
+ "google",
+ "meta",
+ "eightfold"
+]count_jobs2 fields changedInput schema / properties / experience / descriptionPrevious value: -"Years of experience the posting asks for; any of \"0-1\", \"1-3\", \"3-5\", \"5-8\", \"8+\", \"not_stated\" (about a third of postings don't say; include it unless you mean to drop them)."New value: +"Years of experience the posting asks for; any of \"0-1\", \"1-3\", \"3-5\", \"5-8\", \"8+\", \"not_stated\" (we read the posting and it names none) and \"unchecked\" (not read yet, or no text to read: many big-company and Workday roles). Include both unless you mean to drop them."Input schema / properties / experience / items / enumPrevious value: -[
- "0-1",
- "1-3",
- "3-5",
- "5-8",
- "8+",
- "not_stated"
-]New value: +[
+ "0-1",
+ "1-3",
+ "3-5",
+ "5-8",
+ "8+",
+ "not_stated",
+ "unchecked"
+]search_jobs2 fields changedInput schema / properties / experience / descriptionPrevious value: -"Years of experience the posting asks for; any of \"0-1\", \"1-3\", \"3-5\", \"5-8\", \"8+\", \"not_stated\" (about a third of postings don't say; include it unless you mean to drop them)."New value: +"Years of experience the posting asks for; any of \"0-1\", \"1-3\", \"3-5\", \"5-8\", \"8+\", \"not_stated\" (we read the posting and it names none) and \"unchecked\" (not read yet, or no text to read: many big-company and Workday roles). Include both unless you mean to drop them."Input schema / properties / experience / items / enumPrevious value: -[
- "0-1",
- "1-3",
- "3-5",
- "5-8",
- "8+",
- "not_stated"
-]New value: +[
+ "0-1",
+ "1-3",
+ "3-5",
+ "5-8",
+ "8+",
+ "not_stated",
+ "unchecked"
+]count_jobs10 fields changedInput schema / properties / exclude / descriptionAdded value: +"Leave out titles containing any of these words, e.g. \"senior staff intern\"."Input schema / properties / experience / descriptionAdded value: +"Years of experience the posting asks for; any of \"0-1\", \"1-3\", \"3-5\", \"5-8\", \"8+\", \"not_stated\" (about a third of postings don't say; include it unless you mean to drop them)."Input schema / properties / family / descriptionAdded value: +"\"product_adjacent\" finds product, product marketing, growth, customer success, forward deployed and business operations titles in one search; query narrows within it."Input schema / properties / location / descriptionAdded value: +"One country (\"United States\", \"UK\", \"India\"), or a city or state as written. Empty for anywhere."Input schema / properties / locations / descriptionAdded value: +"Several places at once, matching any, e.g. [\"United States\", \"London\", \"Remote\"]. Up to 8."Input schema / properties / posted_within_hours / descriptionAdded value: +"Only roles posted within this many hours; 0 for any time."Input schema / properties / query / descriptionAdded value: +"Whole words matched in the title or company, e.g. \"product manager\" or \"quant\". Empty for any."Input schema / properties / remote / descriptionAdded value: +"Only remote roles."Input schema / properties / roles / descriptionAdded value: +"Several titles at once, matching any, e.g. [\"Product Manager\", \"Software Engineer\"]. Up to 40."Input schema / properties / source / descriptionAdded value: +"Only roles from one source (gh is Greenhouse), or \"any\"."get_changes2 fields changedInput schema / properties / cursor / descriptionAdded value: +"next_cursor from your last get_changes call; 0 starts from the beginning of the 90-day history."Input schema / properties / limit / descriptionAdded value: +"How many to return, 1 to 20."get_job1 field changedInput schema / properties / job_id / descriptionAdded value: +"A job id from search results, e.g. \"gh:stripe:1234567\"."list_my_jobsmy_jobssearch_jobs14 fields changedInput schema / properties / discovered_since / descriptionAdded value: +"ISO date or time: only roles we first found on or after it, excluding baseline imports. Empty for any."Input schema / properties / exclude / descriptionAdded value: +"Leave out titles containing any of these words, e.g. \"senior staff intern\"."Input schema / properties / experience / descriptionAdded value: +"Years of experience the posting asks for; any of \"0-1\", \"1-3\", \"3-5\", \"5-8\", \"8+\", \"not_stated\" (about a third of postings don't say; include it unless you mean to drop them)."Input schema / properties / family / descriptionAdded value: +"\"product_adjacent\" finds product, product marketing, growth, customer success, forward deployed and business operations titles in one search; query narrows within it."Input schema / properties / limit / descriptionAdded value: +"Results per page, 1 to 20."Input schema / properties / location / descriptionAdded value: +"One country (\"United States\", \"UK\", \"India\"), or a city or state as written. Empty for anywhere."Input schema / properties / locations / descriptionAdded value: +"Several places at once, matching any, e.g. [\"United States\", \"London\", \"Remote\"]. Up to 8."Input schema / properties / offset / descriptionAdded value: +"Skip this many results; pass next_offset from the previous page."Input schema / properties / posted_within_hours / descriptionAdded value: +"Only roles posted within this many hours; 0 for any time."Input schema / properties / published_since / descriptionAdded value: +"ISO date or time: only roles the company dated on or after it. Empty for any."Input schema / properties / query / descriptionAdded value: +"Whole words matched in the title or company, e.g. \"product manager\" or \"quant\". Empty for any."Input schema / properties / remote / descriptionAdded value: +"Only remote roles."Input schema / properties / roles / descriptionAdded value: +"Several titles at once, matching any, e.g. [\"Product Manager\", \"Software Engineer\"]. Up to 40."Input schema / properties / source / descriptionAdded value: +"Only roles from one source (gh is Greenhouse), or \"any\"."count_jobsget_changesget_jobget_usagemy_jobssearch_jobsLive job openings from Workday, Greenhouse, Lever, Ashby, Workable and Personio career sites.
Job search for Claude, ChatGPT, Cursor. 250K+ jobs, 5,400+ companies. OAuth or stdio.
Search 690k open jobs from official ATS feeds, and what changed since your last check.
Job alerts for AI agents: describe a role once, get only new postings from 1,000+ tech job boards.
Add one secure layer between your agents and this server.
