H1R3: Australian job board for bots

search_jobs

Search live Australian jobs; every result has pay_type verified (ABN-verified employer on H1R3) | advertised (stated in source ad) | unclear (a figure in the ad that looks wrong or partial; not counted as advertised) | estimate (H1R3 estimate from ABS/JSA medians, not from the employer, with estimate_basis) | none, plus one normalised pay object {type,min,max,unit,text}; estimates are included by default (include_estimates=false for stated pay only); filter with pay=verified|advertised|estimate|any; sourced results carry job_url, posted_ago, and (for everyone, no key or verification) direct_to {apply_url, go_url, method, login_required, anti_bot_seen, notes} to send the candidate straight to the employer page, plus apply_mode (candidate_bot_ok / candidate_bot_grey / human_only). source=verified (paid, verified H1R3 employers) | sourced (public ATS listings; apply at original) | all (default; verified ranked first). Seek-style filters: industry (ANZSIC division), category/occupation (ANZSCO), location (state/region/remote), q (keywords), min_pay (annual A$) + include_estimates, page/per_page. Options: GET /api/v1/jobs/filters.

Input Schema

Name	Required	Description
`q`	No
`pay`	No
`near`	No
`page`	No	Page number (1-based). When set, the reply includes total (approximate when total_approximate), pages, per_page. Window = first 200 matches: when more match, total is 200 and total_is_capped=true (total_label "200+").
`sort`	No	closing = soonest closing date first (jobs with no closing date last)
`skills`	No
`source`	No
`suburb`	No	Suburb or 4-digit postcode (e.g. Southport or 4215): results sorted nearest first with distance_km (first 120 matches). Centroids: GeoNames (CC BY 4.0).
`min_pay`	No	Minimum pay, annual A$ (e.g. 80000). Hourly/daily/weekly pay is annualised (hour x 1976 = 38 h x 52 weeks, full-time equivalent, before super) and compared on the top of the range. Jobs with no pay figure are excluded. Casual hourly/daily rates are not annualised (they include the casual loading), so they do not meet min_pay.
`pay_min`	No
`category`	No	Job category: ANZSCO major group (1 digit, e.g. 2 Professionals) or sub-major group (2 digits, e.g. 25 Health Professionals). Alias of occupation; see /api/v1/jobs/filters
`industry`	No	ANZSIC 2006 code: division letter + digits, e.g. K, K64, K641 (Q = Health Care and Social Assistance); see /api/v1/jobs/filters
`location`	No	State code (qld nsw vic wa sa tas act nt), region code (e.g. qld-gold-coast, qld-brisbane, nsw-sydney, vic-melbourne) or remote; see /api/v1/jobs/filters
`per_page`	No	1-50; default 20 when page is set, else 50
`pay_shown`	No
`work_type`	No	Seek's work types, comma-separated for several: full_time (Full time), part_time (Part time), contract (Contract/Temp), casual (Casual/Vacation). Unclassified jobs only show when this is empty (Any).
`occupation`	No	ANZSCO 2022 code prefix (1-6 digits), e.g. 2613 software, 2544 registered nurses; see /api/taxonomy/occupations
`include_estimates`	No	With min_pay: also include jobs whose only pay figure is an H1R3 estimate (pay_type estimate, never from the employer). Default true; set false for stated pay only.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedInput schema / properties / min_pay / description

Previous value: -"Minimum pay, annual A$ (e.g. 80000). Hourly/daily/weekly pay is annualised (hour x 1976 = 38 h x 52 weeks, full-time equivalent, before super) and compared on the top of the range. Jobs with no pay figure are excluded."New value: +"Minimum pay, annual A$ (e.g. 80000). Hourly/daily/weekly pay is annualised (hour x 1976 = 38 h x 52 weeks, full-time equivalent, before super) and compared on the top of the range. Jobs with no pay figure are excluded. Casual hourly/daily rates are not annualised (they include the casual loading), so they do not meet min_pay."

Changed1 schema field changedNov 4, 2026

changedInput schema / properties / page / description

Previous value: -"Page number (1-based). When set, the reply includes total (approximate when total_approximate), pages, per_page. Window = first 200 matches."New value: +"Page number (1-based). When set, the reply includes total (approximate when total_approximate), pages, per_page. Window = first 200 matches: when more match, total is 200 and total_is_capped=true (total_label \"200+\")."

Changed3 schema fields changedOct 24, 2026

changedInput schema / properties / include_estimates / description

Previous value: -"With min_pay: also include jobs whose only pay figure is an H1R3 estimate (pay_type estimate, never from the employer). Default false (stated pay only); set true to opt in."New value: +"With min_pay: also include jobs whose only pay figure is an H1R3 estimate (pay_type estimate, never from the employer). Default true; set false for stated pay only."

addedInput schema / properties / sort

Added value: +{
+  "description": "closing = soonest closing date first (jobs with no closing date last)",
+  "enum": [
+    "closing"
+  ],
+  "type": "string"
+}

addedInput schema / properties / suburb

Added value: +{
+  "description": "Suburb or 4-digit postcode (e.g. Southport or 4215): results sorted nearest first with distance_km (first 120 matches). Centroids: GeoNames (CC BY 4.0).",
+  "type": "string"
+}

Changed1 schema field changedOct 23, 2026

changedInput schema / properties / include_estimates / description

Previous value: -"With min_pay: also include jobs whose only pay figure is an H1R3 estimate (pay_type estimate, never from the employer). Default true."New value: +"With min_pay: also include jobs whose only pay figure is an H1R3 estimate (pay_type estimate, never from the employer). Default false (stated pay only); set true to opt in."

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / work_type / description

Added value: +"Seek's work types, comma-separated for several: full_time (Full time), part_time (Part time), contract (Contract/Temp), casual (Casual/Vacation). Unclassified jobs only show when this is empty (Any)."

Changed2 schema fields changedOct 21, 2026

addedInput schema / properties / include_estimates

Added value: +{
+  "description": "With min_pay: also include jobs whose only pay figure is an H1R3 estimate (pay_type estimate, never from the employer). Default true.",
+  "type": "boolean"
+}

addedInput schema / properties / min_pay

Added value: +{
+  "description": "Minimum pay, annual A$ (e.g. 80000). Hourly/daily/weekly pay is annualised (hour x 1976 = 38 h x 52 weeks, full-time equivalent, before super) and compared on the top of the range. Jobs with no pay figure are excluded.",
+  "type": "number"
+}

Changed5 schema fields changedOct 19, 2026

addedInput schema / properties / category

Added value: +{
+  "description": "Job category: ANZSCO major group (1 digit, e.g. 2 Professionals) or sub-major group (2 digits, e.g. 25 Health Professionals). Alias of occupation; see /api/v1/jobs/filters",
+  "type": "string"
+}

changedInput schema / properties / industry / description

Previous value: -"ANZSIC 2006 code: division letter + digits, e.g. K, K64, K641; see /api/taxonomy/industries"New value: +"ANZSIC 2006 code: division letter + digits, e.g. K, K64, K641 (Q = Health Care and Social Assistance); see /api/v1/jobs/filters"

addedInput schema / properties / location

Added value: +{
+  "description": "State code (qld nsw vic wa sa tas act nt), region code (e.g. qld-gold-coast, qld-brisbane, nsw-sydney, vic-melbourne) or remote; see /api/v1/jobs/filters",
+  "type": "string"
+}

addedInput schema / properties / page

Added value: +{
+  "description": "Page number (1-based). When set, the reply includes total (approximate when total_approximate), pages, per_page. Window = first 200 matches.",
+  "type": "number"
+}

addedInput schema / properties / per_page

Added value: +{
+  "description": "1-50; default 20 when page is set, else 50",
+  "type": "number"
+}

Changed2 schema fields changedOct 18, 2026

addedInput schema / properties / industry

Added value: +{
+  "description": "ANZSIC 2006 code: division letter + digits, e.g. K, K64, K641; see /api/taxonomy/industries",
+  "type": "string"
+}

addedInput schema / properties / occupation

Added value: +{
+  "description": "ANZSCO 2022 code prefix (1-6 digits), e.g. 2613 software, 2544 registered nurses; see /api/taxonomy/occupations",
+  "type": "string"
+}

Changed1 schema field changedOct 17, 2026

addedInput schema / properties / pay

Added value: +{
+  "enum": [
+    "verified",
+    "advertised",
+    "estimate",
+    "any"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 17, 2026
- addedInput schema / properties / pay_shown
```
Added value: +{
+  "type": "boolean"
+}
```
First observedOct 17, 2026

TDQS

A3.5/5.0

Behavior4/5

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

With zero annotations, the description carries the full burden and does substantial work: it defines the pay_type provenance taxonomy, discloses the 200-match result window, source ranking, and the direct_to/apply_mode fields returned for every result. It also notes no key or verification is needed. It stops short of describing error behavior or rate limits for the undocumented filter parameters.

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

Conciseness3/5

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

The purpose is correctly front-loaded, and most clauses carry real information (defaults, ranking, result fields). But it is one dense pipe-and-semicolon run-on paragraph, which makes the pay taxonomy and the source semantics hard to parse for an agent scanning it.

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?

For an 18-parameter tool with no annotations and no output schema, it covers the highest-value filters and the shape of returned pay/job fields well. It is still incomplete: four parameters remain undefined, duplicate-looking parameters are not disambiguated, and there is no guidance on pagination interplay despite the cap note living only in the schema.

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?

The description explains the meaning and defaults of pay, include_estimates, min_pay, source, and the Seek-style filters beyond what the schema states. But several of the 18 parameters — notably near, pay_min, pay_shown, and skills — are undocumented in both the description and the schema, and near/pay_min appear to duplicate suburb/min_pay without any disambiguation.

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?

Opens with a specific verb+resource: 'Search live Australian jobs', which is clearly distinct from siblings like search_seekers or list_bot_applicable_jobs. It never explicitly says it is not for those other resources, but the domain is unambiguous from the first clause.

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?

Gives concrete filtering guidance ('include_estimates=false for stated pay only', 'pay=verified|advertised|estimate|any', 'source=all default; verified ranked first'), which implies when to pick each mode. However, there is no explicit statement of when to use this tool versus list_bot_applicable_jobs or search_seekers, and no prerequisites are stated.

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

All H1R3: Australian job board for bots 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?