SiteCheck Jobs & Property

SEEK job ads for keywords and a location: title

jobs_seekingalpha

Read-only

SEEK job ads (Australia or New Zealand) for keywords and a location: title, advertiser, location, work type and arrangement, salary text when shown, classification, short teaser, bullet points, listing date and job URL, plus the total number of matching ads. From SEEK's public job-search JSON. Full ad text and applicant data are not included. Takes about 10 s; allow a 30 s timeout. Related tools on this server, for a different need: jobs_seek when you need job ads on SEEK Australia or New Zealand for keywords; jobs_indeed when you need Indeed job search: title, company, location, salary range. 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>"
    },
    "name": "jobs_seekingalpha"
  }
}

Input Schema

Name	Required	Description
`page`	No	Results page 1 to 20 (default 1)
`where`	No	Location, e.g. Sydney NSW (default: whole country)
`country`	No	au (default) or nz
`keywords`	Yes	Job title or keywords, e.g. nurse (required)
`pageSize`	No	Ads per page 1 to 30 (default 20)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations only declare readOnly/openWorld, so the description carries real weight here and delivers: ~10 s runtime with a 30 s timeout recommendation, no full ad text or applicant data, total match count included, and a per-call price of $0.002 with failed calls not charged. The x402 payment mechanism is disclosed as a prerequisite. It stops short of describing rate limits or failure modes beyond non-billing.

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 return fields, source, and exclusions are front-loaded in the first two sentences, then latency, alternatives, and price. The field enumeration is a long list, but each item tells the agent what data is available, so the length earns its place. Slightly dense but well ordered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema and annotations already present, the description does enough: it adds latency, cost, payment auth, and explicit data exclusions. The one material gap is that it never clarifies how this differs from the near-identical jobs_seek sibling, which is the decision an agent most needs to make.

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 every parameter (page, where, country, keywords, pageSize) is already documented at the field level. The description only restates the keywords/location axis and adds no format, default, or interaction detail beyond the schema, which is the expected baseline.

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 and resource ("SEEK job ads (Australia or New Zealand) for keywords and a location") and enumerates the returned fields plus the source (SEEK's public job-search JSON). An agent knows exactly what this returns before opening the schema.

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

Usage Guidelines3/5

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

It does give related-tool routing ("jobs_seek when you need job ads on SEEK Australia or New Zealand for keywords; jobs_indeed when you need Indeed"), but the jobs_seek condition is essentially identical to this tool's own purpose, so the routing clause fails to discriminate between the two SEEK tools. The Indeed comparison is genuinely useful, but the closest alternative is left ambiguous.

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?