Job Spotter

Post a job or shift (free)

post_job

Post a job or shift (free). Goes live at once for a signed-in employer, with optional screening questions. Applications from candidates' assistants arrive in the applicant inbox. Questions about protected characteristics are left out. A ready-to-read summary is in say.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	No	Kind: job or shift.
`type`	No	Type: full_time, part_time, contract, temporary, internship.
`visa`	No
`title`	Yes
`pay_hi`	No
`pay_lo`	No
`remote`	No
`company`	Yes
`country`	No
`pay_cur`	No
`pay_per`	No
`location`	No
`apply_url`	No	Optional: leave out to take applications through Job Spotter.
`questions`	No	Screening questions.
`description`	Yes	At least a few sentences.

Schema Changelog

Changes observed during successful MCP inspections.

Changed19 schema fields changedOct 9, 2026

removedInput schema / properties / apply_email

Removed value: -{
-  "description": "Or an email to apply to.",
-  "type": "string"
-}

changedInput schema / properties / apply_url / description

Previous value: -"Apply link."New value: +"Optional: leave out to take applications through Job Spotter."

removedInput schema / properties / company / description
```
Removed value: -"Company."
```
addedInput schema / properties / country
```
Added value: +{
+  "type": "string"
+}
```

changedInput schema / properties / description / description

Previous value: -"The advert text."New value: +"At least a few sentences."

removedInput schema / properties / email

Removed value: -{
-  "description": "The employer's work email; a confirmation link goes there.",
-  "type": "string"
-}

changedInput schema / properties / kind / description

Previous value: -"Kind: job (default) or shift."New value: +"Kind: job or shift."

removedInput schema / properties / location / description
```
Removed value: -"Where."
```
removedInput schema / properties / pay_cur / description
```
Removed value: -"GBP, USD, EUR or CAD."
```
removedInput schema / properties / pay_per / description
```
Removed value: -"Pay per: year, hour, day or month."
```

addedInput schema / properties / questions

Added value: +{
+  "description": "Screening questions.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

removedInput schema / properties / referral_bonus

Removed value: -{
-  "description": "Referral bonus offered, if any.",
-  "type": "string"
-}

removedInput schema / properties / shift_end

Removed value: -{
-  "description": "Shift end, ISO date and time.",
-  "type": "string"
-}

removedInput schema / properties / shift_start

Removed value: -{
-  "description": "Shift start, ISO date and time.",
-  "type": "string"
-}

removedInput schema / properties / title / description
```
Removed value: -"Job title."
```

changedInput schema / properties / type / description

Previous value: -"Type: full_time, part_time, contract, temporary, internship or per_diem."New value: +"Type: full_time, part_time, contract, temporary, internship."

addedInput schema / properties / visa
```
Added value: +{
+  "type": "boolean"
+}
```
removedInput schema / properties / visa_sponsorship
```
Removed value: -{
-  "type": "boolean"
-}
```

changedInput schema / required

Previous value: -[
-  "email",
-  "title",
-  "company",
-  "description"
-]New value: +[
+  "title",
+  "company",
+  "description"
+]

AddedOct 2, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already establish non-read-only, non-destructive, non-idempotent. The description adds genuine context on top: immediate go-live, where candidate applications land ('applicant inbox'), the omission of protected-characteristic questions, and the location of the human-readable result ('say'). It does not cover what happens on duplicate posts, though non-idempotent is already flagged.

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?

Five short sentences, front-loaded with the action and immediacy, and each adds a distinct fact (prerequisite, inbox routing, compliance filter, summary field). Marginally chatty but nothing is padding.

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?

There is no output schema, and the description does disclose the `say` summary convention, which helps. However, for a 15-parameter creation tool with 33% schema coverage, the majority of fields (pay, location, remote, visa, type) are unexplained anywhere, leaving the agent under-equipped to fill the schema correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only 33% of the 15 parameters have schema descriptions, so the description must compensate. It touches just two of them obliquely — 'screening questions' for questions and the applicant inbox implying the apply_url leave-out behavior — while pay_lo/pay_hi, pay_cur, pay_per, location, country, remote, visa, type, and kind go unexplained in both places.

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?

Starts with a specific verb and resource ('Post a job or shift'), and the '(free)' qualifier plus 'goes live at once' pins down the scope. It does not, however, distinguish itself from close siblings like update_post, write_job_advert, or add_job_from_link, so an agent must infer which one to pick.

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?

States a prerequisite implicitly ('for a signed-in employer') and implies immediate publishing, which is useful context. There is no explicit when-to-use vs when-not, and no routing to alternative tools such as write_job_advert or update_post.

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

All Job Spotter 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.

Post a job or shift (free)

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources