Remote Jobs MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

get_jobs

Read-only

Fetch legacy-compatible remote job listings as full JSON objects, filtered by geo, keyword, category, or industry, with no authentication required.

Instructions

Legacy-compatible public jobs feed. Keeps the original full job objects and JSON array in content.text. Use search_jobs for compact results and more filters. Geo means candidate eligibility: country, parent region, or globally available jobs may match. No authentication.

Input Schema

TableJSON Schema

Name	Required	Description
`geo`	No	Public text.
`tag`	No	Search keyword.
`count`	No
`search`	No	Public text.
`keyword`	No	Public text.
`category`	No	Public text.
`industry`	No	Public text.
`location`	No	Public text.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`jobs`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv2.0.0Oct 3, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / category

Added value: +{
+  "description": "Public text.",
+  "type": "string"
+}

removedInput schema / properties / count / description

Removed value: -"Number of jobs to return, from 1 to 100. Default is 100."

changedInput schema / properties / count / maximum
```
Previous value: -100New value: +200
```

changedInput schema / properties / geo / description

Previous value: -"Location slug. Run get_taxonomies with type='locations' first to discover valid slugs."New value: +"Public text."

changedInput schema / properties / industry / description

Previous value: -"Industry slug. Run get_taxonomies with type='industries' first to discover valid slugs."New value: +"Public text."

addedInput schema / properties / keyword

Added value: +{
+  "description": "Public text.",
+  "type": "string"
+}

addedInput schema / properties / location

Added value: +{
+  "description": "Public text.",
+  "type": "string"
+}

addedInput schema / properties / search

Added value: +{
+  "description": "Public text.",
+  "type": "string"
+}

changedInput schema / properties / tag / description

Previous value: -"Search keyword, from 3 to 50 characters."New value: +"Search keyword."

addedInput schema / required
```
Added value: +[]
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "jobs": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changed2 schema fields changedv0.1.5Jun 15, 2026
- removedInput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
- removedInput schema / additionalProperties
```
Removed value: -false
```

Changed6 schema fields changedv0.1.4Jun 10, 2026

changedInput schema / properties / count / description

Previous value: -"Number of jobs to return (default 100)"New value: +"Number of jobs to return, from 1 to 100. Default is 100."

changedInput schema / properties / geo / description

Previous value: -"Location slug (e.g., 'europe', 'usa', 'uk')"New value: +"Location slug. Run get_taxonomies with type='locations' first to discover valid slugs."

changedInput schema / properties / industry / description

Previous value: -"Industry slug (e.g., 'dev', 'marketing')"New value: +"Industry slug. Run get_taxonomies with type='industries' first to discover valid slugs."

changedInput schema / properties / tag / description

Previous value: -"Search keyword (3-50 chars)"New value: +"Search keyword, from 3 to 50 characters."

addedInput schema / properties / tag / maxLength
```
Added value: +50
```
addedInput schema / properties / tag / minLength
```
Added value: +3
```

First observedv0.1.0Jun 9, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), yet the description adds genuinely useful behavior: it preserves original full job objects and a JSON array in content.text, and requires no authentication. The geo-eligibility rule (country, parent region, globally available) is non-obvious semantics not present in the 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?

Four short sentences, front-loaded with what the tool is, then output format, then the sibling alternative, then the geo caveat. Dense and waste-free, though the telegraphic phrasing ("Geo means candidate eligibility") reads more like notes than polished documentation.

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?

An output schema exists, so return values need not be described, and the description still adds the legacy content.text layout detail. The main residual gap is behavior around count/pagination and how the several filter parameters interact, which neither the schema nor the description resolves.

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 88%, so the baseline is 3; the description exceeds it by clarifying that geo means candidate eligibility rather than a plain location filter, which the schema only labels as "Public text." It does not disambiguate the overlapping search/keyword/tag/category/industry parameters, leaving that gap.

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?

The description identifies the resource and scope clearly ("Legacy-compatible public jobs feed") and explicitly contrasts itself with search_jobs, so an agent can distinguish it from the sibling that returns compact results. It stops short of a crisp verb+object statement like "retrieve full job objects," but the resource and its legacy nature are unambiguous.

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?

"Use search_jobs for compact results and more filters" gives an explicit alternative plus the condition that selects it, and "Legacy-compatible" implies this is the choice when old-format payloads are needed. It does not spell out a full when-not-to-use case, but the routing guidance is concrete.

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

Deploy Server