Resume Booster Job Board

An employer's hiring record on this board

employer_hiring_record

Read-onlyIdempotent

For each employer handle (companyToken, up to 20 per call), that employer's own record on this board: open_roles now, closed_90d (takedown events we watched on this board in the last 90 days, re-lists excluded — one posting that came back and came down again counts each time), superseded_90d (the re-lists, a floor), the two medians from the employer's own stated dates (lower bounds), tracking_days (how long we have watched THIS board, capped at 90) and feed_total (what its feed advertised at the last check). A takedown is not a hire — a filled role, a cancelled one and a withdrawn one look identical from here — and it is a record of one BOARD, never summed across an employer's boards, never a headcount. A board with no closure observed answers record:'unknown' with the reason, never a verdict about the employer: on a board bigger than one visit can read, no closure is observable to us until we complete a provable full pass and then watch a role go after it, so silence there is about our instrument. Every row carries its basis. Every row also carries layoff_filing — the newest layoff filing joined to that employer by a hand-curated alias or an exact multi-token name match, a US state WARN notice or an SEC 8-K Item 2.05 disclosure, printed as a filing (filer verbatim, its dates with their bases, count, state or form, link), read hourly from SEC EDGAR and nightly from state notices, null when none qualifies within 90 days, and no part of record or any verdict; layoff_basis on the response says what it is and is not. Pair with employer_growth for the other half of what the site calls "Actively hiring". Needs a key or a sign-in.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`companyTokens`	Yes	companyToken values from job cards or search_jobs (a vendor tenant, e.g. 'acme' or 'gici~wd5~Careers'). Up to 20; more is refused with the count named.

Output Schema

TableJSON Schema

Name	Required	Description
`asked`	No
`basis`	Yes
`employers`	Yes	One row per token asked, in the order asked. A token the board does not carry still answers, as unknown.
`layoff_read`	Yes	"ok" when the filing reader answered for every employer; otherwise "unread: <fault>" and every layoff_filing on this response is null for that reason, never because nothing qualified. The record is unaffected either way.
`window_days`	No
`layoff_basis`	Yes	What layoff_filing is and is not, beside every row's record.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 18, 2026

addedOutput schema / properties / employers / items / properties / layoff_filing

Added value: +{
+  "additionalProperties": false,
+  "description": "The newest qualifying layoff filing joined to this employer, or null when none qualifies. A fact about the employer on one date, beside the record and no part of it.",
+  "properties": {
+    "effective_date": {
+      "description": "The date the WARN notice gives for the separations; null when it gives none or on an SEC filing.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "event_basis": {
+      "type": "string"
+    },
+    "event_date": {
+      "description": "The filing's own date: the WARN notice date or the 8-K report date. Named by event_basis.",
+      "type": "string"
+    },
+    "event_type": {
+      "description": "What the WARN notice says it is, as the state classifies it; null on an SEC filing.",
+      "enum": [
+        "closure",
+        "layoff",
+        "relocation",
+        "unknown",
+        null
+      ],
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "filer": {
+      "description": "The employer as the source names it, verbatim — never the board's own display name.",
+      "type": "string"
+    },
+    "form": {
+      "description": "The SEC form (an amendment never appears); null on a WARN notice.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "headcount": {
+      "description": "Positions the 8-K states, as parsed; null when it states none or on a WARN notice.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "more_n": {
+      "description": "Further qualifying filings for this employer beyond this newest one.",
+      "type": "integer"
+    },
+    "pct": {
+      "description": "Workforce share the 8-K states, as parsed; null when it states none or on a WARN notice.",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "public_basis": {
+      "type": "string"
+    },
+    "public_date": {
+      "description": "When it became public: the SEC file date or the state's received/processed/posted stamp. Named by public_basis.",
+      "type": "string"
+    },
+    "read_at": {
+      "description": "When we read it. Our stamp, never a date basis for the filing.",
+      "type": "string"
+    },
+    "relation": {
+      "description": "filer: the filer is this board's employer. subsidiary_site: the filer is the parent company of this board's employer.",
+      "enum": [
+        "filer",
+        "subsidiary_site"
+      ],
+      "type": "string"
+    },
+    "site": {
+      "description": "The notice's site as the state lists it; null when not stated or on an SEC filing.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "source": {
+      "description": "state_warn: a US state WARN notice. sec_8k_205: an SEC 8-K Item 2.05 disclosure.",
+      "enum": [
+        "sec_8k_205",
+        "state_warn"
+      ],
+      "type": "string"
+    },
+    "source_name": {
+      "description": "SEC EDGAR, or the state agency as it names itself.",
+      "type": "string"
+    },
+    "source_url": {
+      "description": "The filing itself, at the source.",
+      "type": "string"
+    },
+    "state": {
+      "description": "Two-letter state of a WARN notice; null on an SEC filing.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "workers": {
+      "description": "Positions the WARN notice states at that site. Null on an SEC filing — never zero.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "source",
+    "relation",
+    "filer",
+    "event_date",
+    "event_basis",
+    "public_date",
+    "public_basis",
+    "state",
+    "site",
+    "workers",
+    "event_type",
+    "effective_date",
+    "pct",
+    "headcount",
+    "form",
+    "source_url",
+    "source_name",
+    "read_at",
+    "more_n"
+  ],
+  "type": [
+    "object",
+    "null"
+  ]
+}

changedOutput schema / properties / employers / items / required

Previous value: -[
-  "company_token",
-  "record",
-  "basis"
-]New value: +[
+  "company_token",
+  "record",
+  "basis",
+  "layoff_filing"
+]

addedOutput schema / properties / layoff_basis

Added value: +{
+  "description": "What layoff_filing is and is not, beside every row's record.",
+  "type": "string"
+}

addedOutput schema / properties / layoff_read

Added value: +{
+  "description": "\"ok\" when the filing reader answered for every employer; otherwise \"unread: <fault>\" and every layoff_filing on this response is null for that reason, never because nothing qualified. The record is unaffected either way.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "employers",
-  "basis"
-]New value: +[
+  "employers",
+  "basis",
+  "layoff_basis",
+  "layoff_read"
+]

First observedSep 18, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower. The description adds real interpretive behavior: 'A takedown is not a hire', that silence yields record:'unknown' and is about the instrument rather than the employer, that values are board-scoped lower bounds/never headcount, that layoff_filing is 'no part of record or any verdict', and refreshes ('read hourly from SEC EDGAR and nightly'). Much of the remaining text explains output fields the output schema already covers.

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 core purpose is front-loaded, but the body is a dense wall of nested parentheticals and em-dash clauses covering field semantics, caveats and filing provenance. For a complex tool the length is partly justified, yet the readability cost is high and several clauses border on restating the output schema.

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?

An output schema exists, so return-value enumeration is not strictly required, and annotations cover the safety profile. The description still supplies the auth requirement, the board-scoping caveat, the 'unknown' semantics and the takedown-is-not-a-hire warning, making it complete enough to call correctly.

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?

Only one parameter, and schema description coverage is 100%, so the schema already documents companyToken format, the 20-item cap and the refusal behavior. The description restates the handle concept and 'up to 20 per call' but adds no syntax or meaning beyond the schema, so baseline 3 applies.

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 specific verb+resource ('that employer's own record on this board') and enumerates the concrete outputs (open_roles, closed_90d, superseded_90d, medians, tracking_days, feed_total, layoff_filing). It also names a sibling ('Pair with employer_growth for the other half'), so an agent can distinguish it from the other employer/board tools without opening schemas.

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?

It implies the context ('Pair with employer_growth for the other half of what the site calls "Actively hiring"') and notes it 'Needs a key or a sign-in', which is useful routing. But it never states an explicit when-to-use / when-not rule or which sibling to prefer over employer_growth, board_stats or check_jobs_open, leaving selection to inference.

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

All Resume Booster Job Board 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.