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: get_job retrieves a specific job from a URL, search_jobs performs filtered searches, and hiring_now returns just-added jobs without filters. The descriptions explicitly clarify edge cases like new=true overlap, so misselection is unlikely.
The naming is somewhat mixed: 'get_job' and 'search_jobs' follow a verb_noun pattern, but 'hiring_now' is a gerund phrase that breaks the convention. All names are still readable and intuitive, but not fully consistent.
With only 3 tools, the set is tightly scoped to the server's read-only job board purpose. Each tool serves a clear need—searching, retrieving, and surfacing new listings—without redundancy or bloat.
The core job discovery flow is covered: search, get by URL, and see new listings. Minor gaps exist (e.g., no pagination, no employer apply URLs, no employer details beyond jobs), but the surface is sufficient for the intended use case.
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. 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 (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already carry the safety profile, so the bar is lower. The description adds value by disclosing output traits beyond the schema: the response is plain-text and contains no employer apply URL. This level of added context exceeds baseline for an annotated read-only tool.
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?
Four short sentences with zero waste. The usage context is front-loaded, the search prohibition is explicit, and the output traits are stated in two punchy fragments. Every sentence earns its place.
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 simple two-parameter, read-only, idempotent tool, nothing critical is missing. The description covers invocation source, parameter choice, the search exclusion, and the key output characteristics (plain-text, no employer apply URL) — the latter being important since no output schema exists to document return values.
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 baseline of 3 applies. The description reinforces the schema ('Pass that job's url from search_jobs or hiring_now (or its slug)') and mirrors the preference hierarchy (url preferred, slug fallback), but it adds no new semantic information beyond what the schema already documents.
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 implies the purpose — fetch a specific job's details after a search — via usage context ('Use after search_jobs or hiring_now when the user picked one job') rather than a crisp verb+resource statement. It does differentiate from siblings with 'Do not use this to search,' and the output hints ('Plain-text description. No employer apply URL') clarify what the agent gets back, but the core function 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?
Explicitly states when to use ('after search_jobs or hiring_now when the user picked one job'), what input to pass (that job's url or slug), and the exclusion ('Do not use this to search'). This is textbook routing guidance that distinguishes the tool from its siblings without ambiguity.
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. Same companies as the homepage Hiring now chips, plus every just-added job that counts toward those chips — not the 25-job homepage sample, not posted_at. theyond.com job and company URLs only. No employer apply URLs. 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?
Beyond the readOnly, openWorld, and idempotent annotations, the description adds exact output-scope behavior: it includes chip companies and just-added jobs, excludes the 25-job homepage sample and posted_at, returns only theyond.com URLs, excludes employer apply URLs, and returns empty when nothing was added. There is 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?
The text is short and the main idea is front-loaded, but the second sentence is a dense run-on with multiple exceptions ('not the 25-job homepage sample, not posted_at') that an agent must untangle. It could be restructured to list criteria more clearly.
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 read-only tool with no output schema, the description covers what it returns (job and company URLs), what it excludes, and the empty case. The invocation and result semantics are sufficiently clear.
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 schema has zero parameters, so the baseline is 4, and the description reinforces that no keyword is involved. There are no parameter-level details to add.
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 identifies the tool's scope ('what's new on theyond.com with no keyword') and lists specific inclusions and exclusions (just-added jobs, theyond.com URLs only). It does not use a crisp verb like 'list' or 'get,' and the homepage-chip reference makes the purpose slightly less immediate, but it is distinguishable from get_job and search_jobs.
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?
It conveys the condition for using this tool ('with no keyword') and the empty case, and it excludes certain data types, but it never names search_jobs or get_job as the alternatives for keyword-based or single-job lookup. The usage context is present only implicitly.
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 behind the homepage Hiring now chips (same set as hiring_now), still max 10. Not posted_at. Returns at most 10 theyond.com pages, no pagination, no employer apply URLs. 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 behind the homepage Hiring now chips (same set as hiring_now). Still max 10. Can be the only filter. Not posted_at. | |
| remote | No | If true, only remote jobs: title/location looks remote, or Jev labeled the JD 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 Jev labeled 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 indicate a safe, read-only, idempotent call. The description goes beyond them with concrete constraints: maximum 10 results, no pagination, no employer apply URLs, semantics of theyond_verified_at and salary, and the fact that applications happen on the theyond page. No contradictions 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?
Although longer than average, every sentence contributes a distinct fact: scope, URL exclusion, required filter combination, new semantics, result cap, absence of pagination/apply URLs, field meanings, and apply flow. It is front-loaded with the core purpose and routing rule.
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 6-parameter search tool with no output schema, the description is unusually complete: it covers result limits, omitted features (pagination, employer apply URLs), field semantics for potentially confusing values, and the application path. An agent has enough context to invoke the tool and interpret results 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%, so the baseline is 3, but the description adds the critical at-least-one-filter requirement that the schema's all-optional fields do not convey. It also clarifies that new=true is not posted_at and explains what remote=true means, adding real value beyond parameter names and schema descriptions.
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 opens with 'Find live jobs' and enumerates the specific filter dimensions (keyword, place, company, remote, seniority). It explicitly distinguishes from get_job by excluding theyond job URLs and references hiring_now for the new-set, making the tool's scope unmistakable.
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?
It states an explicit precondition ('Need q, location, company, remote=true, seniority, or new=true') and gives a direct routing rule for the URL case ('use get_job for that'). Hiring_now is mentioned only as an equivalent result set for new=true rather than a fully spelled-out when-to-use alternative, so the guidance is strong but slightly incomplete.
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_jobhiring_nowsearch_jobsRead job postings live from employer career sites across 10 applicant tracking systems.
Search 490k+ live jobs from company ATS boards, save roles, follow companies, manage talent profile.
Semantic search over 3.5M+ live US job postings pulled straight from company ATSes. Read-only.
Search 6.3M+ live jobs from companies' own career pages, plus resume tailoring & cover letters.
Add one secure layer between your agents and this server.
