Skip to main content
Glama

VeritaHire live jobs

Is this job posting still open?

is_job_still_open
Read-only

Checks whether a job posting is still on the employer's own careers site (VeritaHire re-reads employer sites and marks a posting closed within about 36 hours of it leaving). Returns open, closed or unknown, with the last time it was confirmed. Works for postings found anywhere, given the employer's careers-site link.

Input Schema

NameRequiredDescriptionDefault
urlNoThe posting URL (careers site or veritahire.com/j/)
job_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description adds real behavioral context they don't: a ~36-hour detection latency after a posting leaves the site, and the three-valued return (open/closed/unknown) plus a last-confirmed timestamp, which tells the agent how much to trust the result.

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

Conciseness5/5

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

Three tight sentences: purpose first, then mechanism/freshness, then return values. The parenthetical latency figure is the only elaboration and it earns its place. No filler.

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?

With no output schema, the description usefully enumerates the return states and timestamp, and discloses the freshness window. It is slightly incomplete on error/unknown-edge behavior and on the two-optional-parameter relationship, but otherwise complete for a simple status check.

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?

Schema coverage is only 50% and neither parameter is required. The phrase 'given the employer's careers-site link' loosely maps to url, but the job_id parameter is unexplained, and the description never clarifies the url-vs-job_id precedence or whether one is needed. It adds little beyond the schema.

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 precise verb+resource ('checks whether a job posting is still on the employer's own careers site') and scopes it against the employer-freshness domain rather than the local index siblings like get_job or search_live_jobs serve. An agent can tell what this answers without 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 Guidelines4/5

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

'Works for postings found anywhere, given the employer's careers-site link' gives a clear applicability condition and input source. It does not name an alternative or an exclusion (e.g. when to prefer search_live_jobs), so it stops short of the top band.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources