remote_policy can be published but never filtered or read from search results

[FoundRoleApp]

Implementing an OJCP provider, we ran into an asymmetry in the remote vocabulary that looks unintentional — asking here in case the simplification is deliberate.

The four-value vocabulary is defined once and usable almost nowhere:

Where	What it carries
job-posting.json → get_job_detail	remote_policy: on_site / hybrid / remote / flexible
job object in responses/search-jobs.json	absent
tools/search-jobs-input.json	location.remote_ok: boolean
candidate-context.json	location_preference.remote_ok: boolean

So an agent can't ask for hybrid roles — the filter is boolean — and can't sort them out of the results either, because the field isn't in the search item. The only way to learn that a posting is hybrid is to call get_job_detail on each result in turn. "Show me hybrid roles near me" turns one search into N+1 calls, and remote preference is one of the most common things a candidate actually asks about.

What makes it look accidental rather than a deliberate payload-size decision: the search item already carries skills_required, baseSalary, employmentType, urgency and fit_score. It isn't restricted to identity fields — it already includes the signals an agent ranks on. remote_policy seems to be the one that got left out.

Schema extensibility means a provider can include it anyway (we do), but an agent can't rely on it, which is what a standard vocabulary is for.

Two additions would close it, both backward-compatible and neither breaking existing consumers:

1. Add remote_policy to the job object in responses/search-jobs.json — same enum, optional.
2. Add remote_policy as a filter accepting the same four values, alongside the existing remote_ok rather than replacing it. remote_ok: true stays meaningful as remote or flexible.

Happy to open a PR if this reads as a gap rather than an intentional simplification.

[fraywing]

You're right, this was a gap rather than a deliberate simplification. The point that convinced me is the one you made: the search item already carries skills_required, baseSalary, employmentType, urgency, and fit_score, so it's clearly not restricted to identity fields. remote_policy being left out was an oversight, and remote preference is too common a query to make agents pay an N+1 get_job_detail for it.

Fixed both halves, both optional and backward-compatible:

• responses/search-jobs.json now carries remote_policy on the search job item, same four-value enum as JobPosting.
• tools/search-jobs-input.json gains a remote_policy filter that accepts the four values, alongside remote_ok rather than replacing it. remote_ok: true still means "remote or flexible," so nothing that relied on it changes.

Made it an array on the input so an agent can ask for more than one policy at once, e.g. ["hybrid", "remote"].

Merged in #26 Thanks for writing it up with the coverage figures, that's exactly the kind of report that makes a gap easy to act on.