Search live jobs pulled straight from employer career sites (about 11M openings), read full postings with pay and the employer's apply link, find similar roles, and look up employers' open jobs, pay bands and local hiring demand. Free, no sign-in.
Scored across 7 tools
Each tool has a distinct resource and action: job search, job detail by id, similar jobs by id, company profile by slug, company jobs by slug, local demand by place, and market insights for a role+place. The overlapping-sounding market/demand tools are clearly separated by inputs and outputs, and search vs. similar vs. company jobs are distinguishable by context and return shape.
All tool names follow a consistent snake_case verb_noun pattern: find_similar_jobs, get_company, get_job, get_local_demand, get_market_insights, list_company_jobs, search_jobs. There is no mixing of casing or verb styles.
Seven tools is well-scoped for a job search server: search, detail, similar jobs, company profile, company jobs, local demand, and market insights. Each tool earns its place without obvious redundancy.
The surface covers the core discovery workflow: search, inspect a posting, find similar roles, inspect employers, list employer jobs, and read local/market demand. Minor gaps exist around company lookup by name rather than slug and saved/search-history style workflows, but these are workable given the read-only search domain.
More openings like one job, by its id: the same kind of role in the same place (or remote, when the job is remote), as up to 10 cards. Use it when a job is closed, a near miss, or the person wants more like it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds behavior beyond that: the similarity criteria (role type + location, with remote propagated from the source job) and the hard cap of 10 result cards. It does not describe ranking, ordering, or what happens when no similar jobs exist.
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, front-loaded with the core operation and closing with usage triggers. Dense but not padded. The parenthetical about remote jobs slightly interrupts the flow but carries real meaning.
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 two-parameter read-only lookup with no output schema and annotations already covering safety, the description supplies what matters: similarity semantics, result cap, and when to reach for it. The only real gap is that `limit` is invisible to an agent reading only the prose.
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 0%, so both parameters rely on the description. It clarifies `id` well ('by its id' identifying the source job) and implies the 10-item ceiling that bounds `limit`. It never mentions that `limit` exists, that it defaults to 6, or that the caller can lower it, leaving one of two parameters semantically thin.
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 concrete operation on a concrete resource: it returns other job openings similar to the job identified by `id`. It even defines what 'similar' means (same kind of role in the same place, or remote when the job is remote) and the result cap ('as up to 10 cards'). It does not explicitly name sibling tools like search_jobs or get_job to differentiate itself, so it stops short of a 5.
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 triggering conditions: use it when a job is closed, when the original is a near miss, or when the person asks for more like it. That is clear when-to-use guidance. It does not name alternatives (e.g. 'use search_jobs for a fresh query'), so an agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an employer's profile by its slug (companySlug on a job): what it does, size, observed pay bands, work arrangement, benefits, recent events and how it is hiring. hiring.definitions says what each hiring number measures: medianOpenPostingAgeDays is the age of open listings, not time to fill, and removedRoles30d counts postings taken down, not roles filled. Its page is https://www.metaintro.com/company/.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description goes beyond that by disclosing the returned sections and by correcting two likely misinterpretations (medianOpenPostingAgeDays is listing age, not time to fill; removedRoles30d counts takedowns, not roles filled). It omits error behavior for missing slugs and any rate/auth constraints, 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?
Purpose is front-loaded and the whole definition is three sentences with no filler. The transition into the definitions caveat is clumsy ("how it is hiring. hiring.definitions says..."), which slightly hurts readability.
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 read tool with full annotations and no output schema, the description does the needed work: it lists what is returned, defines the ambiguous hiring metrics, and explains the slug source. Only the not-found/empty-profile case is left unaddressed.
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 0%, so the description must carry the meaning of the single parameter, and it partially does: it identifies the value as the companySlug found on a job and the URL template illustrates the expected bare-slug format. It still does not state case sensitivity, whether the slug is globally unique, or what a valid slug looks like beyond the URL example.
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 gives a specific verb and resource ("Read an employer's profile by its slug") and enumerates the payload contents, so the agent knows this returns a company-level profile rather than job-level data. It links the key to jobs ("companySlug on a job"), which implicitly separates it from list_company_jobs, but never names that sibling explicitly.
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?
Usage is implied rather than stated: the parenthetical "companySlug on a job" tells the agent where to source the identifier, which is a real usage hint. However, there is no explicit when-to-use versus list_company_jobs or get_job, and no statement about what to do when a slug is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one posting in full by its id: description, requirements, pay, location and the employer's apply link. The title, summary and description are employer source text; licence requirements and eligibility remain unassessed. posting gives its age, when it was last seen live and closesAtLocal, the closing weekday and time.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-structured context: title/summary/description are unverified employer source text, licence requirements and eligibility are unassessed, and posting carries first-seen/last-seen-live timing plus closesAtLocal with its weekday/time meaning. Missing only failure behavior for a bad or expired id.
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 sentences, front-loaded with the action and its payload, then the data-quality caveat, then the timing fields. The final sentence is slightly compressed — "posting gives its age" reads as a return-field note and takes a moment to parse — but nothing is redundant.
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 a single required parameter and no output schema, the description carries the return-value burden and does so reasonably: it lists the fields returned and explains the temporal fields. The main gap is the absence of any not-found or expired-posting behavior, which matters for a lookup 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 description coverage is 0%, so the only parameter is documented solely by its uuid format and pattern. The description's "by its id" confirms it identifies a single posting but adds no guidance on obtaining an id or handling a malformed one, leaving the schema to do nearly all the work.
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?
"Read one posting in full by its id" gives a specific verb and resource, and the enumerated payload (description, requirements, pay, location, apply link) makes it clear this is a single-record retrieval rather than a search. It distinguishes itself from search_jobs and list_company_jobs in practice, though it never names a sibling explicitly.
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?
Usage is only implied: an agent can infer this is the drill-down after a search result, since it takes a single id. There is no stated when-to-use versus find_similar_jobs or list_company_jobs, and no mention of what to do if the id is unknown or the posting is closed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read which kinds of roles are hiring most in a place (city, region, country): open jobs by role category, with total open jobs, employers and sectors. When a place has too few role types it widens to the region, the country or worldwide; scope and locationLabel say which. Use it when someone does not yet know what to look for.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No | ||
| region | No | ||
| country | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and closed-world semantics, yet the description adds genuine behavioral detail: the result silently widens from city to region, country, or worldwide when too few role types exist, and the caller can detect this via scope and locationLabel. That auto-fallback is the main thing an agent could misinterpret, and it is 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?
Three tight sentences: what it returns, how the scope falls back, and when to reach for it. All load-bearing, front-loaded, 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?
The description names two return fields (scope, locationLabel) which partially compensates for the absent output schema, and it explains the geo-fallback logic. However, it leaves the geography parameters' interaction and the limit cap unexplained, which an agent needs to call this correctly on the first try.
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 0% and the description leaves semantics thin: it does not say whether city, region and country can be combined or which wins, and the limit parameter (1-12, presumably capping role categories) is only hinted at via 'too few role types'. With four undocumented parameters, this is a real gap.
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: read which role categories are hiring most in a place, returning open jobs by role, totals, employers and sectors. This is clearly distinct from siblings like search_jobs (keyword lookup) and get_market_insights.
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 trigger: 'Use it when someone does not yet know what to look for', which implicitly contrasts with search_jobs that requires a known query. It stops short of naming alternatives or stating exclusions, so it is strong but not fully routing-aware.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize the live market for a role and place: how many openings match, the median listed pay, the most common work arrangement and the top requested skills, with how the request was understood. Takes a query and the same filters as search_jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| locale | No | ||
| filters | No | ||
| commuteRadiusMiles | No | ||
| fallbackToVisitorPlace | No | When the query names no place and the search is not remote, search the signed-in person's saved country, or the country of an anonymous visitor's IP address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=false, so the safety profile is fully covered. The description adds that results are aggregated/derived (counts, medians, top skills) and that the query interpretation is echoed back, which is a modest behavioral signal. It says nothing about latency, caching freshness of 'live' data, or failure behavior when too few matches exist.
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 what the agent gets back, followed by the input contract. No filler; the awkward 'with how the request was understood' clause still carries real information about an output field.
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 no output schema, describing the return payload inline is exactly the right compensation and largely succeeds. However, for a tool with a deeply nested filters object and only 20% schema text, the definition is thin on how the nested filter values should be formed, and it does not say what happens when the market has zero or very few matching openings.
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 only 20% — just fallbackToVisitorPlace is documented — and the description covers only 'query' and the filters object. The pointer that filters are 'the same as search_jobs' genuinely helps the agent borrow semantics for the ~17 nested filter fields, but locale, commuteRadiusMiles, and the filters' optionality/nullability are left unexplained.
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?
Uses the specific verb 'Summarize' on a defined resource ('the live market for a role and place') and enumerates the exact outputs: matching opening count, median listed pay, most common work arrangement, top requested skills, plus request interpretation. That aggregate framing cleanly separates it from the listing-oriented siblings like search_jobs and list_company_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?
The clause 'Takes a query and the same filters as search_jobs' implicitly positions this as the aggregate counterpart to search_jobs, which is useful routing context. But it never states when to prefer this over search_jobs or over get_local_demand, nor any exclusions or prerequisites, so the agent must infer the choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List an employer's open jobs by its slug, newest first, as compact cards with posting age and the employer's title and summary as source text; read one in full with get_job. Pages are cut to fit the response size, so continue with nextCursor until it is null.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| limit | No | ||
| cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent read, so the description correctly spends its words elsewhere: result ordering (newest first), result payload (compact cards with posting age, employer title and summary as source text), and the truncation behavior that forces cursor paging. That truncation disclosure is real value the 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?
One dense sentence front-loads the core action and folds the sibling reference and pagination rule into the same breath; there is little waste, though the second clause is packed tightly enough to be parsed twice.
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 three-param read tool with no output schema, the definition covers what comes back, how it is ordered, and how to page through it — the only meaningful omission is any hint about the limit parameter's effect on page size.
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 0%, so the description carries the burden: it explains slug ('by its slug') and the cursor concept via 'nextCursor'. It never mentions the limit parameter or the fact that cursor is an integer bounded 0-1000, leaving one of three params undocumented in both places.
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 an employer's open jobs by its slug') plus the ordering and output shape ('compact cards with posting age'), and explicitly separates itself from the sibling get_job, which reads a single posting in full.
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 when-to-use routing to get_job for full detail and precise continuation instructions ('continue with nextCursor until it is null'). It does not contrast against search_jobs or find_similar_jobs, which is the remaining gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search jobs: find live job openings from employer career sites and job boards that match what the person wants, by role or keywords, place, remote work, employment type and pay. filters.jobTypes takes FULL_TIME, PART_TIME, CONTRACT or other listed types; any of them match. filters.salaryListedOnly keeps only jobs that post pay. filters.minSalary is annual pay in the requested currency, and ranges that only overlap it are included. Each card carries fit (every applied filter as met, partial, unknown or not_met, and verdict match or near_match: present a near_match as a near match, never as a match; a match meets only the applied filters, so lead stays conditional while unconfirmed names pay, hours, commute or licence, and label is the heading to use), posting (age, freshness, last seen live) and the employer's title and summary as source text. Licence requirements and eligibility remain unassessed. coverage says what was searched and whether more pages exist; an empty or short result covers only this search, not every job. Up to 10 cards a page; page with offset. Each job opens at https://www.metaintro.com/job/.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| cursor | No | ||
| locale | No | ||
| offset | No | ||
| filters | No | ||
| purpose | No | ||
| variants | No | Up to 4 more wordings of the same search, such as other job titles for the same work. They run at the same time as query, with the same filters, radius, limit and page, and each counts as one search toward the search limit. Results come back in variants, one entry per wording, leaving out jobs already listed above them; repeatedJobIds names those. Use this instead of separate searches for alternative titles. | |
| commuteRadiusMiles | No | ||
| fallbackToVisitorPlace | No | When the query names no place and the search is not remote, search the signed-in person's saved country, or the country of an anonymous visitor's IP address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only annotations, the description explains important behavior: fit verdicts including near_match versus match, how to label results, posting freshness, coverage limits, empty-result caveats, and that licence requirements remain unassessed. This materially improves correct interpretation of results without an output schema.
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 the tool purpose and stays focused on operational details. It is dense and somewhat run-on, but most sentences carry useful behavioral or filter semantics rather than 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 complex search tool with nested filters and no output schema, the description covers result interpretation, fit semantics, coverage, pagination, and job URLs well. It is not fully complete because several nested filter parameters are left undocumented in both the description and schema.
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 description adds useful semantics for key filters, including jobTypes matching any listed type, salaryListedOnly, minSalary as annual pay in the requested currency with overlap inclusion, and offset pagination. However, with only 20% schema description coverage, many parameters such as locations, remoteOk, hybridOk, commuteRadiusMiles, cursor, and locale remain unexplained.
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: search live job openings from employer career sites and job boards, with role, place, remote, type, and pay criteria. It is clear enough to distinguish the tool from get_job or list_company_jobs, but it does not explicitly name or contrast those siblings.
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 gives implied usage guidance by describing the matching criteria a person may want, such as role, keywords, place, remote work, employment type, and pay. It does not explicitly say when not to use this tool or when to use alternatives like find_similar_jobs or list_company_jobs.
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.
find_similar_jobsget_companyget_jobget_local_demandget_market_insightslist_company_jobssearch_jobs
Add one secure layer between your agents and this server.