When a job was first posted and whether it is still open, from the employer's own job link.
Scored across 1 tool
There is only one tool, so there is no possibility of an agent confusing it with another. Its purpose (reporting job posting age/status from an employer link) is stated explicitly and unambiguously.
A single tool named check_job_posting_age uses a clear, readable snake_case verb_noun pattern. With one tool there are no competing conventions to clash with it.
One tool is thin for a standalone server, even though the surface's scope is genuinely narrow (a single lookup operation). It earns its place but a companion operation (e.g. batch/company-level check) would make the count feel better scoped.
For the stated purpose the tool covers the lifecycle question well: first-published date, open/closed status, and last-updated for some ATS providers, plus explicit guidance on refused sources (LinkedIn/Indeed). Minor gaps remain, such as no batch or multi-link checking, but agents can work around this with repeated calls.
Find out when a job posting was first published and whether it is still open, from the company's own job link (Greenhouse, Lever, Ashby, SmartRecruiters, Workday, Workable, Recruitee, BambooHR, Teamtailor, JazzHR, Breezy HR, Personio, Oracle Recruiting Cloud, iCIMS, UKG Pro Recruiting, Rippling, Dayforce, ADP Workforce Now, Eightfold; job pages on Jobvite, Pinpoint, Paylocity, Taleo Business Edition, JOIN, softgarden, Homerun; or any careers page with JobPosting structured data). Greenhouse, Recruitee and UKG also give a last-updated date. Use it when someone asks how old a job listing is, whether it is still accepting applications, or whether it might be a "ghost job": the dates are evidence for that question, but they show age and status, not whether the company intends to hire. LinkedIn and Indeed links are refused; pass the employer's apply link instead. Free, no account; by Cursu (cursu.ai).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The job posting's URL on the employer's careers site or ATS, starting with https://. |
| Name | Required | Description |
|---|---|---|
| link | Yes | This result on cursu.ai. |
| title | No | |
| source | Yes | Where the dates came from: the ATS name, "the <ATS> job page" for a page read, or "the company's job page". |
| status | Yes | |
| ageDays | No | |
| company | No | |
| checkedAt | Yes | ISO time of the check (results are cached for up to 24 hours). |
| confidence | Yes | |
| dateSource | Yes | |
| firstPosted | No | First-published date, YYYY-MM-DD (UTC). |
| lastUpdated | No | Last-updated date, YYYY-MM-DD (UTC); Greenhouse, Recruitee and UKG only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety behavior is covered. The description adds genuinely useful context beyond annotations — free/no account, the supported ATS list, that only Greenhouse/Recruitee/UKG return a last-updated date, and that unsupported link types are refused. This is solid but not exhaustive on things like rate limits or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and the key caveat and refusal rule come early. The long parenthetical enumeration of ATS providers is heavy, but it carries information an agent needs to judge coverage, so it earns most of its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the description covers source coverage, refusal behavior, and the interpretive limits of the returned dates. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter and 100% schema coverage, the schema already carries the format and length constraints. The description adds real semantic value by clarifying which URL sources are accepted versus refused and steering the agent to the employer's apply link rather than an aggregator URL.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — determining a job posting's first-published date and open/closed status — and scopes it to the employer's own job link. An agent knows exactly what question this answers and what input surface it covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the triggering questions (how old is a listing, still accepting applications, possible ghost job) and draws a clear boundary: the dates are evidence for the ghost-job question but do not reveal hiring intent. It also states the refusal case (LinkedIn/Indeed) and the correct substitute input (the employer's apply link).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_job_posting_ageSearch open jobs from employers' own career sites: roles, companies and posting status.
Is this company actually hiring, or is the board just still up? Real dates on 187,923 roles.
Live US jobs from employers' own career sites, still-open checks, competitive hiring reports.
Search open jobs on employers' own careers sites, each confirmed open in the last 3 days.
Add one secure layer between your agents and this server.