Live jobs from employer career pages. Read-only. Hit Apply on theyond.com. You land on the employer.
Scored across 3 tools
Each tool has a distinct role: search_jobs discovers jobs, get_job retrieves details for a selected job, and hiring_now shows recent additions. The explicit overlap between hiring_now and search_jobs with new=true is clarified in descriptions, but it still creates a minor source of confusion.
All names use snake_case and are readable, with get_job and search_jobs following a verb_noun pattern. hiring_now deviates by using a state phrase rather than a verb, which is a minor inconsistency.
Three tools are at the low end but reasonable for a focused job-discovery surface. Each tool earns its place, though the set feels minimal.
The core lifecycle of discovering jobs, seeing recent additions, and viewing job details is covered. Missing pagination and limited result caps are intentional constraints, but they leave minor gaps for broader exploration.
Use after search_jobs or hiring_now when the user picked one job. Pass that job's url from search_jobs or hiring_now (or its slug). Do not use this to search. Plain-text description, cut at 2000 characters when description_truncated is true. Cite hub URLs on the card. No employer apply URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The theyond.com job URL from search_jobs or hiring_now. Prefer this. | |
| slug | No | Job slug from search_jobs or hiring_now. Use if you don't have the URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), so the description focuses on return-value behavior: plain-text description truncated at 2000 characters when description_truncated is true, plus citation rules ('Cite hub URLs on the card. No employer apply URL.'). It doesn't explain error behavior or what happens with a stale/invalid url, which keeps it from 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?
Front-loaded with the trigger condition and input source; every sentence carries instruction. The trailing 'Cite hub URLs on the card' sentence is slightly cryptic out of context but still earns its place as output-usage guidance.
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, and the description steps in to describe the returned content (plain-text, truncation flag), attribution expectations, and what is deliberately absent (employer apply URL). For a two-parameter read tool that is enough to call it 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 coverage is 100% and the parameter descriptions already state provenance and preference ('Prefer this'), so the description's 'Pass that job's url ... (or its slug)' largely restates the schema. 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?
States a specific action (fetch one job) and distinguishes it from the search siblings by name: 'Use after search_jobs or hiring_now when the user picked one job' plus 'Do not use this to search.' An agent can tell exactly what this tool is for 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?
Gives explicit preconditions (after search_jobs or hiring_now, once a job is picked), the input source ('Pass that job's url from search_jobs or hiring_now (or its slug)'), and an explicit exclusion ('Do not use this to search'). This is when/when-not coverage with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What's new on theyond.com with no keyword. Hiring now companies, plus up to 10 just-added jobs. job_count is how many were just added. Show the theyond.com URLs you were given, including title_hub_url, location_hub_url, or location_title_hub_url when present. Not posted_at, not an employer apply URL. Empty when nothing was just added.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, idempotent, non-destructive. The description adds real value beyond them: a cap of 10 just-added jobs, the meaning of job_count, that the result is empty when nothing was just added, and explicit guidance on which URLs to surface and which to avoid (posted_at, employer apply URLs). No auth or rate-limit detail, but the response-shaping behavior is well disclosed.
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?
Short and front-loaded with the core purpose, and every clause carries information. The telegraphic fragments ('Not posted_at, not an employer apply URL') are efficient but slightly cryptic in isolation.
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 discovery feed with rich annotations and no output schema, the description covers what is returned, the 10-item cap, the empty case, and the URL fields to surface. It stops short of explaining what qualifies a company as 'hiring now' or any ordering, but nothing blocks a correct call.
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?
Zero input parameters, so the baseline is 4. The description's mention of job_count refers to a response field rather than a parameter, which is useful orientation but outside parameter semantics proper.
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 the specific resource: hiring-now companies plus up to 10 just-added jobs from theyond.com, with no keyword. The 'with no keyword' framing implicitly separates it from keyword-based search_jobs, though it never names the sibling or uses a crisp verb like 'list' or 'fetch'.
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 phrase 'with no keyword' hints that this is the keyword-less alternative to search_jobs, but it never explicitly says 'use search_jobs when you have a query' or states any exclusion or prerequisite. Usage is implied, not instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find live jobs when the user has a keyword, place, company, remote, and/or seniority, not a theyond job URL (use get_job for that). Need q, location, company, remote=true, seniority, or new=true. new=true searches just-added jobs on homepage Hiring now (same set as hiring_now), still max 10. Not posted_at. Returns at most 10 theyond.com pages, no pagination, no employer apply URLs. Cite title_hub_url, location_hub_url, or location_title_hub_url when the card includes them. Do not invent a hub slug. theyond_verified_at is when theyond last saw the listing on the employer board, not the posted date. salary is the employer feed wage, or the amount harvested from the JD when the feed had none. People apply from the theyond page.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Keywords for title, company, or description. Optional if location, company, remote, seniority, or new is set. Do not pass a theyond.com/jobs URL here. | |
| new | No | If true, only just-added jobs on homepage Hiring now (same set as hiring_now). Still max 10. Can be the only filter. Not posted_at. | |
| remote | No | If true, only remote jobs. The title or location says remote, or the description was read as remote. Combine with q or company. | |
| company | No | Employer name, case-insensitive. nvidia matches NVIDIA. Optional if q, location, remote, seniority, or new is set. | |
| location | No | City, region, or country. Optional if q, company, remote, seniority, or new is set. | |
| seniority | No | If set, only jobs at that level: intern, entry, mid, senior, staff_lead, or director. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe read-only search, and the description adds substantial behavior: max 10 results, no pagination, no employer apply URLs, URL citation rules, hub-slug caution, and field meanings for theyond_verified_at and salary. No contradiction with 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?
Front-loaded with the purpose and alternative tool, and most sentences carry operational value. Some return-field details are dense and slightly fragmented, but overall it is appropriately sized for the tool’s complexity.
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?
Because there is no output schema, the description usefully covers result limits, pagination, citation rules, and return-field semantics. For a read-only search tool with full schema coverage and annotations, this is complete enough for correct invocation.
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 each parameter in detail. The description reinforces the anyOf filter requirement and new=true behavior, but adds little parameter syntax or semantics beyond what the schema provides.
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?
Clearly states a specific verb and resource: find live jobs. It distinguishes this from get_job for URL cases and from hiring_now via the new=true clause, so an agent can select it confidently.
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 explicit when-to-use criteria (keyword, place, company, remote, seniority, or new), states that at least one filter is required, and names get_job as the alternative for theyond job URLs. The sibling hiring_now is also related to the new=true behavior.
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.
get_job2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "url"
+ ]
+ },
+ {
+ "required": [
+ "slug"
+ ]
+ }
+]hiring_now1 field changedInput schema / additionalPropertiesAdded value: +falsesearch_jobs6 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "q"
+ ]
+ },
+ {
+ "required": [
+ "location"
+ ]
+ },
+ {
+ "required": [
+ "company"
+ ]
+ },
+ {
+ "required": [
+ "remote"
+ ]
+ },
+ {
+ "required": [
+ "seniority"
+ ]
+ },
+ {
+ "required": [
+ "new"
+ ]
+ }
+]Input schema / properties / new / descriptionPrevious value: -"If true, only just-added jobs behind the homepage Hiring now chips (same set as hiring_now). Still max 10. Can be the only filter. Not posted_at."New value: +"If true, only just-added jobs on homepage Hiring now (same set as hiring_now). Still max 10. Can be the only filter. Not posted_at."Input schema / properties / remote / descriptionPrevious value: -"If true, only remote jobs: title/location looks remote, or Jev labeled the JD remote. Combine with q or company."New value: +"If true, only remote jobs. The title or location says remote, or the description was read as remote. Combine with q or company."Input schema / properties / seniority / descriptionPrevious value: -"If set, only jobs Jev labeled at that level: intern, entry, mid, senior, staff_lead, or director."New value: +"If set, only jobs at that level: intern, entry, mid, senior, staff_lead, or director."Input schema / properties / seniority / enumAdded value: +[
+ "intern",
+ "entry",
+ "mid",
+ "senior",
+ "staff_lead",
+ "director"
+]get_jobhiring_nowsearch_jobsLive job postings from company career pages on Greenhouse, Lever, Ashby and SmartRecruiters.
Live job openings from Workday, Greenhouse, Lever, Ashby, Workable and Personio career sites.
Career-site jobs from Workday, Greenhouse, Lever, Ashby, iCIMS and more, with salaries where posted.
Newest jobs from 25,500+ company career sites: Greenhouse, Lever, Workday and more.
Add one secure layer between your agents and this server.