Skip to main content
Glama

4dayweek.io Jobs

Get job

get_job
Read-onlyIdempotent

Fetch one live job listing in full by its slug, as returned by search_jobs.

Returns the complete description, the schedule type and what it means, weekly hours, work arrangement and locations, category, seniority, contract type, required skills, acceptable timezones where the employer listed them, visa sponsorship where the employer stated one, the work-life score, and salary ONLY where the employer published one — we never estimate a salary.

A very long description is truncated on a paragraph boundary; when that happens the response says so and gives the url of the full listing.

Applying happens on the job's page on 4dayweek.io, which the url field points to. apply_method says what a person finds there: "external" means the page hands off to the employer's own application form, "on_page" means they apply on 4dayweek.io itself. There is no separate employer link in this response, and constructing one is not possible from it.

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": {
      "slug": "<slug>"
    },
    "name": "get_job"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesThe slug, as returned by the matching search tool.

Output Schema

NameRequiredDescriptionDefault
urlNo
roleNo
slugNo
levelNo
stackNo
titleNo
toolsNo
salaryNo
skillsNo
companyNo
categoryNo
locationsNo
posted_atNo
timezonesNo
expires_atNo
company_urlNo
descriptionNo
apply_methodNo
company_slugNo
contract_typeNo
schedule_typeNo
hours_per_weekNo
work_life_scoreNo
description_noteNo
schedule_meaningNo
visa_sponsorshipNo
work_arrangementNo
application_closes_atNo
description_truncatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing real behavior: descriptions are truncated on paragraph boundaries with a truncation notice plus full-listing URL, salary is never estimated and appears only when published, and several fields appear only when the employer supplied them. It also explains apply_method semantics and warns that constructing an employer link from this response is impossible.

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?

Front-loaded with the core action, then behavior, then the applying caveat; sentences are dense and non-redundant. The middle paragraph enumerating returned fields is partly duplicative given an output schema exists, which slightly inflates length.

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?

An output schema covers return shape, so the description correctly spends its words on non-obvious behavior: truncation, conditional fields, no salary estimation, and the application handoff model. For a single-param fetch tool, 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.

Parameters3/5

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

Schema description coverage is 100% for the single slug parameter, so the schema already documents its type and meaning. The description reinforces the slug's provenance ('as returned by search_jobs'), which matches what the schema says, so it adds no new syntax or format detail. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb (Fetch) and resource (one live job listing in full) scoped by slug, and ties the slug to search_jobs so the agent immediately knows the relationship to a sibling. It is clearly distinguishable from search_jobs, search_companies, and get_company.

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?

The phrase 'by its slug, as returned by search_jobs' establishes the retrieval workflow and routes the agent to the correct upstream tool. There is no explicit when-not guidance or comparison against other single-resource tools such as get_company, so the guidance is clear context rather than full routing rules.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.