Must a job post show pay? Rules for US states and cities, Canada and all 27 EU countries. Sourced.
Scored across 4 tools
check_job_post is clearly the distinct action tool, and list_capabilities serves a meta/coverage purpose. However, list_pay_transparency_laws (status filter including 'enacted not yet in force', 'pending', 'overdue') and list_upcoming_pay_transparency_changes (date window) overlap substantially, since an agent asking about upcoming laws could reasonably pick either.
All names are snake_case and lead with a verb (check_*, list_*), making the pattern predictable. list_upcoming_pay_transparency_changes inserts an extra modifier rather than a strict verb_noun form, a minor deviation but still readable.
Four tools is lean but reasonable for a rules-lookup server: one action tool plus three listing/meta tools. Each has a defensible role, though the surface is on the thin side.
The core workflow (checking a post, listing current laws, listing upcoming changes, exposing coverage/freshness) is well covered for the domain. Minor gaps remain, e.g. no way to retrieve a single law's full detail or batch-check multiple posts, but agents can work around these via the list tools.
Checks a job post against pay transparency laws before it is published. Give every location the job is based in or could be done from, whether it can be done remotely, the employer headcount and the posting date. Returns each law that applies (or may apply, with the reason), a merged checklist of what the post must include (for example a good-faith minimum and maximum pay range and a description of benefits), salary history question bans, penalties and the official source and citation per law. Covers US states and cities, Canadian provinces and the EU Pay Transparency Directive (EU) 2023/970 country by country, including countries that have not transposed it yet. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Posting date, YYYY-MM-DD. Defaults to today. Future dates include laws already enacted with a later start. | |
| remote | No | True if the job can be done remotely. Many US laws then apply to remote jobs that could be done in their state. | |
| locations | Yes | Where the job is based or could be done. Each item is a string like "Denver, CO", "New York City", "Ontario, Canada", "Germany", or an object {country, state, city}. | |
| remote_scope | No | If remote, where from: "US", "EU", "Canada" or "anywhere". Default: the countries of the locations given. | |
| employer_employees | No | Total employees. Several laws only cover employers above a size. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the evaluation point in the workflow, the deposited coverage (US states/cities, Canadian provinces, EU 2023/970 including non-transposed countries), that 'may apply' results come with a reason, and that the service is free. It omits auth requirements, rate limits or determinism guarantees.
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?
Four tight sentences ordered as purpose, required inputs, return contents, and coverage/cost. Every sentence earns its place and nothing is repeated.
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?
There is no output schema, so the description must describe the return values, and it does so in detail (applicable laws, reasons for 'may apply', merged checklist with example requirements, salary-history bans, penalties, per-law citation). Combined with full parameter documentation, an agent has everything needed to call and interpret it.
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?
Schema coverage is 100% so the baseline is 3, but the description adds rationale beyond the schema by explaining why the caller must enumerate every base or workable location, remote status, headcount and posting date — linking each input to whether a law applies.
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 ('Checks a job post against pay transparency laws') and scopes the timing ('before it is published'), which clearly distinguishes it from the sibling list_* tools that only enumerate laws or changes.
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?
Gives clear invocation context ('before it is published') and tells the caller exactly what inputs to supply, but never names an alternative tool or states when to use list_pay_transparency_laws instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists coverage (laws by country and status), the date the data was last checked, and related Nero Labs Rules servers. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the shape of what comes back (coverage, freshness date, related servers) and adds the cost note 'Free', which is genuinely useful. It says nothing about authentication needs, rate limits, or whether the result is cached, leaving a meaningful gap.
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?
A single, front-loaded sentence that lists the return contents with no filler. The trailing one-word 'Free.' is slightly informal but still earns its place as a cost signal.
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?
With no parameters, no annotations, and no output schema, the description takes on the job of describing returns, which it does adequately by naming the three content categories. It is close to complete for a parameterless listing call, only lacking any hint of format or scope limits.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level explanation is required or missing.
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 the verb 'Lists' and enumerates the resource contents: coverage of laws by country and status, the last-checked date, and related Nero Labs Rules servers. This is specific enough to distinguish it from the law-listing siblings, though it never names those siblings or clarifies what 'capabilities' means.
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?
There is no explicit when-to-use guidance, no prerequisites, and no routing to alternatives such as list_pay_transparency_laws or list_upcoming_pay_transparency_changes. An agent can only infer that this is a metadata/discovery call from the content listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists pay transparency laws with status (in force, enacted not yet in force, pending, EU transposition overdue), start date, who is covered and what a posting must include. Filter by country ("US", "CA", "EU" or an EU country name) and status. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Optional: in_force, enacted_not_yet_in_force, pending, transposition_overdue. | |
| country | No | Optional: "US", "CA", "EU", or a country name such as "Germany". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses the shape of the returned record (status, effective date, covered parties, posting contents) and notes the tool is free, which is real operational context. It omits pagination, result volume, and freshness/update cadence, so it is not fully transparent.
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?
Two tight sentences with no filler: the return contract comes first and the filtering options second, with the trailing "Free." costing almost nothing and conveying useful context.
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?
With no output schema and no annotations, the description must explain what comes back, and it does list the key fields and the enum-like status values. It stops short of describing ordering, limits, or how the country/status filters interact, leaving a small completeness gap.
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?
Schema description coverage is 100%, and the description largely restates the schema's parameter values rather than adding new syntax or semantics. The parenthetical gloss of the four statuses adds only marginal meaning beyond the schema, so the baseline 3 applies.
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 (lists pay transparency laws) and enumerates the returned dimensions: status, start date, coverage, posting requirements. It is clearly a retrieval tool, but it never explicitly contrasts itself with the sibling list_upcoming_pay_transparency_changes, which sounds like the nearest alternative.
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?
It supplies concrete filter values ("US", "CA", "EU", country name, and the four status values), which implies how to narrow results, but there is no explicit when-to-use guidance or routing versus the sibling change-tracking and capability tools. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists pay transparency laws and amendments starting in a date window, soonest first, so a recruiter or HR agent can prepare. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | 1 to 730, default 365. | |
| from_date | No | YYYY-MM-DD, default today. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add real value by declaring ordering ('soonest first') and cost ('Free'), which tells the agent there is no billing or approval gate. It is silent on pagination, result caps, and whether an empty result means no upcoming changes or an error.
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?
A single front-loaded sentence covering what, scope, ordering, audience, and cost, with no repetition or filler. The trailing 'Free.' is terse but informative rather than wasted.
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?
For a no-required-parameter read tool with no output schema and full schema coverage, the description supplies the essentials: the resource, the date-window scoping, ordering, and cost. Only the absence of pagination/empty-result behavior keeps it from being fully complete.
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?
Schema coverage is 100%, so both parameters (days with its 1-730 range and default 365, from_date with its format and default) are already fully documented in structured data. The description's 'date window' phrasing adds no format or semantics beyond that, so the baseline 3 applies.
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 ('Lists pay transparency laws and amendments'), the scope ('starting in a date window'), and the ordering ('soonest first'), so an agent knows exactly what it gets. It does not, however, distinguish itself from the sibling list_pay_transparency_laws, which an agent could easily confuse it with.
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?
The clause 'so a recruiter or HR agent can prepare' implies the usage context but states no when-to-use condition versus list_pay_transparency_laws, and gives no exclusions or prerequisites. It is enough to guess intent, not enough to route reliably between siblings.
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_postlist_capabilitieslist_pay_transparency_lawslist_upcoming_pay_transparency_changesScan a job posting against 16 US state/DC pay-transparency disclosure laws.
Bulk job post pay transparency checks for US, Canada and EU laws, per check billing via Apify.
Live healthcare pay data: advertised ranges by role/state/city, offer checks, transparency scores.
Live job postings worldwide: search by role, country, remote, salary, visa; pay and demand stats.
Add one secure layer between your agents and this server.