Site Audit MCP Server

Pay-transparency posting monitor

monitor_pay_transparency

Idempotent

Screen public job postings on Greenhouse, Lever, or Ashby boards for potential pay-transparency issues and flag missing or unclear pay ranges for human review.

Instructions

Screen the public job postings on Greenhouse, Lever or Ashby careers boards for POTENTIAL pay-transparency issues (missing, open-ended or unparseable pay ranges, missing benefits or close-date wording where a law asks for it) under US state and city laws, with Canadian and EU notes. Every flagged item is a potential issue that needs human review, not a finding of violation, and this is not legal advice. Re-run with the same watchlistId to get changes since the last run. Pay per event: $0.02 per initial or changed posting check, $0.005 per verified unchanged recheck (maxJobsPerCompany bounds the cost).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "boardUrls": "<boardUrls>"
    },
    "name": "monitor_pay_transparency"
  }
}

Input Schema

Name	Required	Description
`dryRun`	No	Not supported by this Actor; ignored.
`boardUrls`	Yes	Public Greenhouse, Lever or Ashby board URLs, for example https://job-boards.greenhouse.io/acme (1-20).
`maxCostUsd`	No	Optional hard cap in USD for this call. The underlying Actor stops when the cap is reached. Minimum 0.05 (the Apify per-run minimum). Default: a small amount computed from the number of URLs, never below 0.05.
`watchlistId`	No	Name of the watchlist (default "mcp"). Keep it the same between calls to get changes.
`hiringStates`	No	US state codes you hire in (for example CA, NY, WA, CO, or NYC) to screen remote roles against; default all in-force state laws.
`employeeCount`	No	Employer size, to skip laws with higher thresholds.
`maxJobsPerCompany`	No	Cap on postings audited per board (default 25). Each posting is billed: $0.02 first check or changed, $0.005 unchanged recheck.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Nov 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true) by disclosing per-event pricing ($0.02 initial/changed, $0.005 unchanged recheck), that results are advisory flags for human review rather than violation findings, that it is not legal advice, and how re-runs produce deltas. These are exactly the cost and liability traits an agent needs before spending money on an open-world Actor.

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?

Front-loads the core action and scope, then layers the human-review/legal caveat, the re-run instruction, and the pricing model in descending order of importance. Every sentence carries decision-relevant information with no padding.

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?

Covers the two things most likely to cause misuse in an open-world, paid Actor: cost control and re-run/watchlist behavior, plus a jurisdiction caveat. With no output schema, the description sketches that flagged items are returned, but does not indicate the shape or fields of the response, leaving a small gap for an agent planning to parse results.

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?

Schema description coverage is 100%, so all seven parameters are already documented in the schema, including watchlistId persistence and maxJobsPerCompany billing. The description only restates the watchlist re-run semantics and that maxJobsPerCompany bounds cost, adding little syntax or meaning beyond the schema, which matches the baseline 3.

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 (Screen) plus the exact resource (public job postings on Greenhouse, Lever or Ashby careers boards) and enumerates the defect classes it looks for (missing/open-ended/unparseable pay ranges, missing benefits or close-date wording). An agent can tell this apart from monitor_page_changes or audit_accessibility without opening any 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?

Gives clear operating context: jurisdiction scope (US state/city laws with Canadian and EU notes), re-run semantics via the same watchlistId to get changes, and cost bounds via maxJobsPerCompany. It does not explicitly name when to prefer a sibling tool or when not to run it, so it stops short of a full when/when-not routing statement.

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

Deploy Server