Nomado24 Remote Jobs

get_job

Fetch ONE nomado24 job posting by id, with the complete v2 payload: the posting body where the source permits redistribution, per-field provenance (dataOrigin: who asserted each field, by which method, when), salaryOrigin, firstSeenAt, lastVerifiedAt with its verification method, and updatedAt (the last genuine content change). Returns an error result for an id that is not a live posting; expired and withdrawn postings are not served. Read-only, free, attribution required (see structuredContent.attribution).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	Job id as returned by search_jobs ('job_<slug>'). A bare slug is also accepted

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description fully carries the behavioral burden and does so admirably: it declares read-only, free, attribution required, the specific payload fields, verification and provenance, and the error behavior for non-live postings. This is a comprehensive disclosure.

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

Conciseness5/5

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

A single well-structured paragraph that leads with the primary action, then details the payload and operational constraints. Every sentence adds value, and the length is justified by the tool's 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?

Despite having no output schema, the description enumerates the key elements of the response (posting body, dataOrigin, salaryOrigin, timestamps, verification method, attribution) plus error semantics. This is sufficient for an agent to call the tool correctly and understand what it will receive.

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 coverage is 100% and the schema description already explains the parameter fully (including accepted bare slugs). The tool description adds no new parameter semantics beyond what the schema provides, matching the baseline for high schema coverage.

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 states a specific verb ('Fetch') and a specific resource ('ONE nomado24 job posting by id'), clearly distinguishing this from the sibling tools search_jobs (plural) and get_job_statistics. The 'ONE' and 'by id' scoping makes its purpose unmistakable.

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 description implies usage when you have a job id, and even notes that expired/withdrawn postings are not served, setting expectations. It does not explicitly name sibling alternatives, but the single-by-id scope is self-evident; a slight gap is not comparing to get_job_statistics.

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

All Nomado24 Remote Jobs tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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

Need Help?