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 (postings we watched come off this board in the last 90 days, re-lists excluded), 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

A4.4/5.0

Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses subtle non-obvious behaviors: re-lists are excluded from closed_90d, superseded_90d is a floor, dates are lower bounds, tracking_days is capped at 90, and a takedown is explicitly not a hire. It also explains the 'unknown' record semantics as an instrument limitation rather than an employer verdict, and details layoff_filing's sources, freshness, and scope. This is far more than the annotations alone convey and is consistent with them.

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?

The description is long, but the complexity of the data semantics justifies most of the length, and the core record fields are front-loaded before the caveats. Some repetition ('Every row carries...' and the 'no part of record or any verdict' clauses) makes it slightly denser than necessary, but every sentence carries real information.

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?

For a complex tool with one parameter and an output schema, the description covers input limits, field semantics, unknown states, data sources, freshness, limitations about what a takedown means, and required authentication. It even names the complementary tool. Nothing essential for selecting or invoking the tool correctly is left unresolved.

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?

The only parameter, companyTokens, is already fully described in the schema with minItems, maxItems, and an example, and schema description coverage is 100%. The description reinforces 'up to 20 per call' and calls companyToken an employer handle, but it does not add materially new parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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 description names a specific resource (an employer's record on this board) and enumerates the exact fields returned, from open_roles now through feed_total, so an agent knows precisely what the tool produces. It also distinguishes itself from employer_growth by positioning that tool as the other half of 'Actively hiring', which separates the two in purpose.

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?

The description clearly says 'Pair with employer_growth for the other half of what the site calls Actively hiring', giving a concrete complementary alternative. It also explains when the data is meaningful (board-level, not headcount, not summed across boards), but it does not explicitly enumerate exclusions for sibling tools like board_stats or check_jobs_open.

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.