lazee.dev Jobs

Get job details

get_job

Read-onlyIdempotent

Get one job by its lazee.dev job id: title, company, hiring platform, location, workplace, department, employment type, pay (as the posting words it and as numbers), role, level, regions, when it was posted and last confirmed open, the link to apply, and this month's call usage. Returns an error once the company has taken the job down.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

Name	Required	Description	Default
`id`	Yes	The job's lazee.dev id, as returned with each job in search results.

Output Schema

Name	Required	Description
`id`	Yes	lazee.dev job id.
`url`	Yes	Link to apply on the company's own site.
`role`	No	Job function key.
`level`	No	Seniority key.
`title`	Yes	Job title.
`usage`	Yes	This month's lazee.dev tool calls for the signed-in account.
`salary`	No	Pay read as numbers, in the job's own currency; null when the posting doesn't state it.
`company`	Yes	Hiring company.
`regions`	No	Region keys the job is open to.
`location`	No	Location as the posting states it.
`platform`	No	Applicant tracking system the job is posted on.
`posted_at`	Yes	Posting date (ISO 8601).
`synced_at`	No	When lazee.dev last confirmed the job is open (ISO 8601).
`workplace`	No	remote, hybrid or onsite.
`department`	No	Team or department.
`compensation`	No	Pay as the posting words it.
`first_seen_at`	No	When lazee.dev first saw the job (ISO 8601).
`employment_type`	No	Full-time, contract, internship and so on.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover readOnly, idempotent, non-destructive, and closed-world semantics, so the description is free to add the genuinely useful behavior: an error is returned once the company has taken the job down. That delisted-job failure mode is the kind of context annotations cannot express, and it also flags that 'last confirmed open' may be stale. It does not mention any auth or rate-limit constraints, which keeps it off 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.

Conciseness4/5

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

It is front-loaded with the verb and identifier, and the delisted-job caveat is a compact, high-value closer. The long enumeration of return fields (title, company, platform, location, workplace, department, ... call usage) is largely redundant given the tool has an output schema, which keeps this 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 one-parameter read tool with annotations and an output schema, the description covers the essentials: what it returns at a high level, how to obtain the id, and the failure condition. It does not explain what an error looks like or whether a delisted job differs from an unknown id, which is the only notable gap.

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

Parameters3/5

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

With a single parameter at 100% schema coverage, the schema already documents the id fully, including where it comes from. The description only restates 'lazee.dev job id', adding no format, validation, or edge-case detail beyond the schema, so the baseline 3 applies.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Get one job by its lazee.dev job id'. The 'one job' framing plus the identifier requirement clearly separates it from search_jobs (multiple results) and get_job_stats (aggregates), and the field list confirms the single-record scope.

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?

Usage is implied rather than stated: the agent infers it should call this when it already holds a job id, and the id's provenance ('as returned with each job in search results') is only in the schema. There is no explicit when/when-not guidance and no mention of get_job_stats or search_jobs as alternatives.

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?