APIVerve

Job Search

JobSearch

Read-only

Job Search: Job Search is a jobs API that searches the open positions at thousands of companies at once. Search by job title keywords, location, country, remote work, employment type, posting date or company, and get the newest matching jobs first, each with its title, company, location, country, workplace type, posting date and apply link. Paid plans add salary ranges, a minimum salary filter, larger pages and each job's full description. (Cost: 20 credits)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "JobSearch"
  }
}

Input Schema

Name	Required	Description
`id`	No	A job id from a search result.
`page`	No	Page of results: 10 jobs per page up to page 5 on the free plan, 50 per page up to page 10 on paid plans.
`remote`	No	true returns only jobs open to remote work; false only jobs that are not.
`company`	No	Return only jobs at this company, by its career board name, usually the company name in lowercase, for example airbnb.
`country`	No	Return only jobs in this country: an ISO 3166 code or a name, for example US, GB or Germany.
`keyword`	No	Words that must all appear in the job title, for example data engineer or product designer.
`location`	No	Return only jobs with a location containing this text, for example London, New York or Bavaria.
`minSalary`	No	Return only jobs whose salary range reaches at least this amount, in the job's own currency and pay period. Jobs that publish no salary are left out when this is set.
`postedSince`	No	Return only jobs first published at or after this date or date-time (ISO 8601, for example 2026-10-01), or within this age: a number followed by h, d or w, for example 12h, 7d or 2w.
`employmentType`	No	Return only jobs of this employment type. Jobs that give no employment type are kept, since many companies leave it blank; only jobs of another type are left out.

Output Schema

Name	Required	Description
`data`	No
`error`	No	Error message, null on success
`status`	No	"ok" on success

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond annotations: newest-matching-first ordering, the fields returned per job, paid-plan-only salary data and full descriptions, and a 20-credit cost. It omits authentication or rate-limit details, but is substantially transparent for a search API.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single well-structured paragraph that front-loads purpose, then filters, return fields, plan differences, and cost. The opening 'Job Search: Job Search is a jobs API' is redundant, and 'thousands of companies at once' is slightly promotional, keeping it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter open-world search tool with an output schema and full schema descriptions, it covers purpose, searchable dimensions, return fields, result ordering, plan limits, and credit cost. It lacks sibling-tool differentiation and does not state the exact free/paid pagination caps, though those are in the schema.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds plan-gated meaning not present in the schema: salary ranges and the minimum salary filter are paid-plan features, and paid plans allow larger pages. It otherwise mostly restates the filter categories already documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('searches') and resource ('open positions at thousands of companies at once'), and names filter dimensions and return fields. It never differentiates this tool from sibling job-related tools such as JobPostings or JobsReport, and opens with a redundant title restatement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies the tool is for finding jobs and lists what can be searched, which gives some usage context. However, it provides no explicit when-to-use versus alternatives, no when-not guidance, and never names a sibling tool to route an agent toward or away from.

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

All APIVerve tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.