SiteCheck Jobs & Property

Job search on Jooble's aggregator through its official REST

jobs_jooble

Read-only

Job search on Jooble's aggregator through its official REST API: title, company, location, salary text, employment type, snippet, original source, last update time and Jooble link, plus the total match count. A jooble.org key covers US listings only. Requires the operator's JOOBLE_API_KEY. Related tools on this server, for a different need: jobs_usajobs when you need US federal job openings from the official USAJOBS Search; jobs_bayt when you need Bayt.com job search for the Middle East and North Africa. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

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": {
      "keywords": "<keywords>",
      "location": "<location>"
    },
    "name": "jobs_jooble"
  }
}

Input Schema

Name	Required	Description
`page`	No	Result page, 1 to 50 (default 1)
`radius`	No	Radius in km: 0, 4, 8, 16, 26, 40 or 80 (optional)
`salary`	No	Minimum salary (optional, whole number)
`keywords`	Yes	Keywords or job title (required)
`location`	Yes	City, region or country (required)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds materially more: an operator-supplied JOOBLE_API_KEY is required, a jooble.org key limits results to US listings, and each successful call costs $0.002 in USDC via x402 on Base, Solana or Arc while failed calls are free. Cost, auth and scope limits are disclosed, which is well beyond the annotation payload.

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 opening clause nearly restates the title ('Job search on Jooble's aggregator through its official REST'), which is minor redundancy. Otherwise the sentences are packed with distinct, front-loaded value — output fields, regional scope, credential, pricing — with no filler.

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 read-only search tool with five simple parameters and an existing output schema, the description covers everything an agent needs: what it returns, geographic coverage limits, required credential and exact per-call cost. No ambiguity remains about whether it is safe, free, or globally scoped.

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%, so page, radius, salary, keywords and location are already documented with their constraints (radius enum values, page 1-50). The description adds no parameter-level meaning such as salary currency or how keywords interact with location, so the schema carries the weight and the baseline of 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 names a specific verb and resource (job search on Jooble's aggregator via its official REST API) and enumerates the result fields (title, company, location, salary text, employment type, snippet, source, update time, Jooble link, total match count). It is clearly distinguishable from the named siblings jobs_usajobs and jobs_bayt, which cover federal US and MENA markets respectively.

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?

It explicitly routes the agent: use jobs_usajobs for US federal openings from the official USAJOBS Search, and jobs_bayt for Middle East/North Africa listings. It also states the coverage constraint that a jooble.org key covers US listings only, which is exactly the kind of when-to-use/when-not-to-use condition an agent needs.

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

All SiteCheck Jobs & Property 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?