ai-toolkit

check_posting

Determine whether a job posting's page is still live by fetching the URL server-side, classifying it as LIVE, DEAD, or UNVERIFIABLE to guide lead handling.

Instructions

Check whether a job posting's canonical page is still live.

Fetches url from this server (not from the caller's network, so it works from sandboxes that block employer domains) and reports one of three statuses. LIVE: the page loaded with a closed notice absent and an application path present. DEAD: HTTP 404/410, another 4xx, or a "no longer accepting applications" style notice on the page. UNVERIFIABLE: a JavaScript shell with nothing to read, a 5xx or a bot block, a timeout, a refused URL, or a page that loaded without a recognisable apply control — this is not a finding about the posting, and the caller's rule is to hold the lead rather than drop or surface it. Pass expected_title (a distinctive fragment of the job title) to guard against a careers site that redirects dead postings to its listing page with a 200: if the title is missing the result is UNVERIFIABLE, not LIVE.

For Greenhouse, Lever, Ashby, and Workday postings prefer ats_fetch_board with a title_filter: the board API is authoritative and needs no page read. Use this for employer-hosted careers sites and aggregator-sourced leads.

Only public https URLs are fetched; the request carries no credentials and follows at most five redirects, each checked.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`expected_title`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 24, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden of behavioral disclosure, and it fully delivers: it states the fetch happens server-side, only public https URLs are fetched, no credentials are sent, up to five redirects are followed and checked, and the three statuses (LIVE, DEAD, UNVERIFIABLE) are precisely defined including edge cases like JS shells, bot blocks, timeouts, and redirect traps.

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?

The description is longer than average, but every sentence earns its place by adding operational detail needed for correct invocation. It is front-loaded with the core purpose, then progressively covers status semantics, parameter guidance, alternatives, and security behavior, with clear structure and no wasted words.

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?

Given no annotations and no parameter descriptions in the schema, the description is remarkably complete: it explains the tool's network behavior, credentials, redirect policy, status outcomes, parameter semantics, and when to choose an alternative. The exact return shape is covered by the output schema, so nothing an agent needs to call this tool successfully is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it does. It explains that url is fetched from the server side and must be public https, and it defines expected_title as a distinctive title fragment used to detect false positives from redirects, including the consequence if the title is missing (UNVERIFIABLE rather than LIVE).

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 opening sentence states a specific verb ('Check') and resource ('a job posting's canonical page is still live'), making the tool's function immediately clear. It is distinguished from siblings like ats_fetch_board by explicitly describing what this tool checks (a fetched HTML page) and when the ATS board API is preferred instead.

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?

The description gives explicit when-to-use guidance: prefer ats_fetch_board with a title_filter for Greenhouse, Lever, Ashby, and Workday postings; use this tool for employer-hosted careers sites and aggregator-sourced leads. It also explains the expected_title parameter as a guard for redirect-to-listing sites, providing concrete decision logic for calling the tool correctly.

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