Skip to main content
Glama

Nomado24 Remote Jobs

search_jobs

Search nomado24's remote/hybrid job board. Read-only, free, attribution required (see structuredContent.attribution). Answers over one of two contracts, chosen by the arguments you send. Send only q/language/page/per_page and you get the legacy v1 result shape with page-based paging. Send any structured filter (country, applicant_region, work_arrangement, employment_type, seniority, skills, salary_min/max, published_after, verified_after, source, company, sort, include_total) or a cursor and you get the v2 contract: richer job objects, per-posting provenance (salaryOrigin, firstSeenAt, lastVerifiedAt, verification.method, updatedAt), a corpus changeWatermark, a snapshotId and keyset paging via pagination.nextCursor. The two are mutually exclusive: page plus a structured filter is refused rather than silently resolved. Structured results omit the posting body and the per-field dataOrigin to stay cheap to read; call get_job for those. A filter nomado24 cannot answer honestly is refused with the reason, never answered with the unfiltered corpus. For the same reason pagination.total is null (totalRelation 'not_computed') whenever a post-projection filter (skills, seniority, salary bounds, employment_type=unknown) is in play — a null total is deliberate, not an error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFree-text search over job title/company/tags
pageNo1-based page number, default 1
sortNoOne of published_desc, verified_desc, salary_asc, salary_desc. Default published_desc
cursorNoContinuation cursor from pagination.nextCursor. Send it ALONE (with per_page at most), never alongside filters: the cursor already carries the filter set it traverses
skillsNoSkill slugs, lowercase kebab-case (react, node-js)
sourceNoFeed/source ids, lowercase kebab-case
companyNoCompany name, exact match, case-insensitive. Aggregated postings carry no verified employer identity
countryNoWhere the ROLE sits, ISO 3166-1 alpha-2 uppercase (DE, US)
languageNoFilter by job content language
per_pageNoResults per page, 1-25, default 20
seniorityNoSeniority. 'unknown' means the field is absent in the response, not a stored value
salary_maxNoUpper bound in normalized ANNUAL EUR (gross)
salary_minNoLower bound in normalized ANNUAL EUR (gross). Matches jobs whose salary interval overlaps it
skills_matchNoHow to combine skills. Requires skills
include_totalNoWhether to compute a total. 'exact' returns a number only when the database saw the whole predicate. With a post-projection filter active (skills, seniority, salary_min/salary_max, employment_type=unknown) the total is withheld: total is null and totalRelation is 'not_computed', because the base count would answer a different question than the one asked. Only at the count ceiling does 'exact' downgrade to 'estimated'.
verified_afterNoRFC 3339 date-time. Compares against the SAME value the response reports as lastVerifiedAt
employment_typeNoEmployment type. 'unknown' means the field is absent in the response, not a stored value
published_afterNoRFC 3339 date-time, e.g. 2026-08-01T00:00:00Z
salary_currencyNoISO 4217. Only EUR: every salary is normalized to EUR at ingest and no conversion is performed
applicant_regionNoWhere a CANDIDATE may be: WORLDWIDE, EU or an ISO 3166-1 alpha-2 code. EEA/DACH/EMEA are refused, nomado24 does not classify them
work_arrangementNoWork arrangement. The board serves remote and hybrid postings only, so these are the only two values

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses read-only/free status, attribution requirement, the mutually-exclusive contract behavior, filter-refusal semantics, the deliberate null total ('a null total is deliberate, not an error'), and what structured results omit. This is exhaustive behavioral disclosure compensating fully for missing annotations.

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 long (~300 words) but every sentence earns its place given 21 parameters, two response contracts, and multiple behavioral edge cases. It is front-loaded with the core purpose and contract-selection logic before edge cases. Could be marginally tightened, but the density is justified by complexity.

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 21-param, dual-contract tool with zero annotations and no output schema, the description covers purpose, contract selection, refusal semantics, result-shape differences, sibling routing, attribution, and pagination/total behavior. 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 baseline is 3. The description adds genuine value beyond the schema by explaining parameter-INTERACTION semantics: which parameter groups trigger which contract, mutual exclusivity rules, and post-projection filter effects on totals. It does not duplicate per-parameter details, which is correct — but the interaction logic is the additive layer.

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?

Opens with a specific verb + resource: "Search nomado24's remote/hybrid job board." It states scope (remote/hybrid only, single job board) and distinguishes itself from siblings by explicitly directing structured-result omissions to get_job. An agent can tell exactly what this tool does and does not cover.

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

Usage Guidelines5/5

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

The description explicitly routes to alternatives: "call get_job for those" for posting body and per-field dataOrigin. It explains the v1 vs v2 contract selection in terms of which arguments to send, states what is refused (page + structured filter) and why (never answered with unfiltered corpus). Nothing is left to inference.

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.

TDQS

A4.7/5.0
Disambiguation5/5

The three tools are completely distinct: get_job fetches a single job by ID, search_jobs performs filtered/queries searches, and get_job_statistics returns aggregate board metrics. There is no functional overlap; an agent can unambiguously choose the right tool for each task.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: get_job, get_job_statistics, and search_jobs. They are all lowercase with underscores, and while search_jobs uses 'search' instead of 'get', it still adheres to the same grammatical structure and style, making the set predictable.

Tool Count5/5

With only three tools, the server is tightly scoped to the core read-only operations of a job board: retrieving a specific posting, searching with flexible filters, and obtaining high-level statistics. Each tool serves a clear, non-redundant purpose, and the count is appropriate for the domain.

Completeness5/5

For a read-only remote jobs board, the surface is complete: search covers discovery with rich filters and paging, get_job provides full details for a specific posting, and get_job_statistics gives aggregate insights. There are no missing CRUD/lifecycle operations because the board is deliberately read-only, and the tool set covers all necessary actions.

Resources