lazee.dev Jobs

Search jobs

search_jobs

Read-onlyIdempotent

Search open tech jobs from company career pages tracked by lazee.dev, newest first. Filter by role, level, region, workplace, company, salary and posting date; every filter is optional and they combine with AND (values inside one filter combine with OR). Returns one page of jobs with title, company, location, salary when posted, and the link to apply on the company's own site. Accepted values for each filter are listed in its parameter schema.

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": "search_jobs"
  }
}

Input Schema

Name	Required	Description
`page`	No	Which page of results to return; the result's meta.total_pages says how many there are. Default 1.
`role`	No	Job functions to include; a job matches any of them. "engineering" covers every engineering function at once.
`sort`	No	posted_desc (newest first, the default) or posted_asc.
`level`	No	Seniority to include; a job matches any of the levels given.
`limit`	No	How many jobs to return on each page. Default 10.
`query`	No	Words to look for in the job title, company name or location, e.g. "react" or "Bangalore". Leave it out to search by filters alone.
`region`	No	Countries or regions the person can work from; a job matches if it is open to any of them.
`company`	No	Companies to include, matched on the full company name ignoring case; a partial name matches nothing.
`platform`	No	Hiring platforms the job must be posted on. Rarely needed: leave it out unless the person asks for a specific platform.
`workplace`	No	Where the work happens; a job matches any of the arrangements given. Jobs whose posting doesn't say are left out when this is set.
`has_salary`	No	Only jobs that state their pay.
`salary_max`	No	Highest yearly pay wanted, in salary_currency.
`salary_min`	No	Lowest yearly pay wanted, in salary_currency. Jobs in other currencies are converted at the day's rate.
`posted_after`	No	Only jobs posted on or after this date, YYYY-MM-DD.
`salary_currency`	No	Currency that salary_min and salary_max are written in, e.g. USD, INR or EUR. Default USD.

Output Schema

Name	Required	Description	Default
`data`	Yes	Jobs on this page.
`meta`	Yes	Paging and freshness.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 11, 2026

addedOutput schema / properties / data / items / properties / last_checked_at

Added value: +{
+  "description": "When lazee.dev last read the job's board and found the job still listed (ISO 8601).",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / data / items / properties / source_status

Added value: +{
+  "description": "How the last sync of the job's board went: ok, failed (job kept from the last good read) or gone.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / properties / data / items / properties / synced_at / description

Previous value: -"When lazee.dev last confirmed the job is open (ISO 8601)."New value: +"When lazee.dev last added or changed the job (ISO 8601)."

removedOutput schema / properties / usage

Removed value: -{
-  "description": "This month's lazee.dev tool calls for the signed-in account.",
-  "properties": {
-    "calls_left": {
-      "description": "Calls left this month.",
-      "type": "integer"
-    },
-    "calls_limit": {
-      "description": "Calls allowed per month on the account's plan.",
-      "type": "integer"
-    },
-    "calls_used": {
-      "description": "Calls used this month, including this one.",
-      "type": "integer"
-    },
-    "resets_at": {
-      "description": "When the count resets (ISO 8601, UTC).",
-      "type": "string"
-    }
-  },
-  "required": [
-    "calls_used",
-    "calls_limit",
-    "calls_left",
-    "resets_at"
-  ],
-  "type": "object"
-}

changedOutput schema / required

Previous value: -[
-  "data",
-  "meta",
-  "usage"
-]New value: +[
+  "data",
+  "meta"
+]

First observedNov 10, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses non-obvious behavior: results are newest first, one page at a time, jobs with unstated workplace are excluded when the workplace filter is set, salaries in other currencies are converted at the day's rate, and company names require full matches. These are exactly the facts an agent could not derive from annotations alone.

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?

Three dense, front-loaded sentences that cover purpose, filtering logic, and return content in order of importance. The closing pointer that accepted values are in the parameter schema is mildly redundant given full schema coverage, but it is one short clause.

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

Completeness5/5

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

For a 15-parameter, all-optional search tool with full schema coverage, rich annotations, and an output schema, the description supplies everything else needed: combination logic, default ordering, pagination expectations, and what a result contains. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the baseline is 3; the description rises above it by explaining cross-parameter combination semantics (AND across filters, OR within one) that no individual parameter schema states. It also clarifies that enum values live in the parameter schemas rather than duplicating them.

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?

States a specific verb and resource ("Search open tech jobs") plus scope ("from company career pages tracked by lazee.dev") and ordering ("newest first"). It does not explicitly contrast with siblings like get_job or get_job_stats, so an agent must infer the distinction from the verb alone.

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

Usage Guidelines4/5

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

Gives real usage context: every filter is optional, filters combine with AND while values within a filter combine with OR, and query is meant for free-text matching with "Leave it out to search by filters alone." It also includes an explicit when-not for platform ("Rarely needed: leave it out unless the person asks for a specific platform"). It stops short of naming alternative tools for related needs.

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

All lazee.dev Jobs 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.

Resources

Need Help?