io.github.gzchenhao/openhire

Overview Schema Source Related Servers Score Discussions Admin

search_jobs

Filter a live index of jobs sourced from employer career sites by skills, remote scope, salary, and currency, then receive ranked postings with verified metadata.

Instructions

Search the live job index by hard filters; returns ranked JobPosting[].

The server does ONLY a hard filter plus a fixed ranking of match-quality × freshness — precise re-ranking is left to you, the client, which holds the user's context. Every result includes the five protocol fields (verified_at, source, ghost_score, response_sla_days, apply_channel) plus datePosted, days_open, remote_scope and eligible_regions.

Args: skills: skill tags, ANY-overlap match (union), e.g. ["rust", "k8s"]. required_skills: skills that must ALL be present (AND), e.g. ["rust"]. remote: if true, only fully-remote roles. remote_scope: filter remote roles by reach: "worldwide" | "region_locked" | "country_locked". min_salary: salary floor. By default roles with NO stated pay are KEPT (they can't be ruled out); set require_stated_salary=true to drop them. currency: restrict to a stated-pay currency, e.g. "USD" (implies stated pay). require_stated_salary: if true, drop roles that publish no salary. role_family: coarse family filter, e.g. "engineering" (v0.1: unpopulated → no-op). limit: max results (default 20).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`remote`	No
`skills`	No
`currency`	No
`min_salary`	No
`role_family`	No
`remote_scope`	No
`required_skills`	No
`require_stated_salary`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.2Sep 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses that only hard filtering is done, ranking is fixed as match-quality × freshness, roles without stated pay are kept by default, require_stated_salary changes that behavior, and role_family is currently a no-op. It also lists exactly which fields every result contains.

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?

The description is front-loaded with the core purpose, followed by an important behavioral caveat, then a clean parameter list. Every sentence conveys necessary information without fluff or repetition.

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 9-parameter tool with no annotations and zero schema description coverage, this description is fully self-sufficient. It covers semantics, edge cases, output fields, and the server's ranking behavior, so an agent can invoke it correctly and interpret results confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully document all 9 parameters, and it does. It explains union vs. AND matching for skills, remote_scope enum values, the salary floor interaction with require_stated_salary, currency implying stated pay, role_family no-op status, and limit default.

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 opens with a specific verb and resource: 'Search the live job index by hard filters; returns ranked JobPosting[]'. It clearly distinguishes this as a filtering/search tool and is not confusable with the unrelated sibling tools (get_company_info, watch_intent, etc.).

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 explains that the server performs only hard filtering plus a fixed ranking, and that precise re-ranking is left to the client holding user context. This gives the agent a clear sense of when this tool is appropriate. However, it does not name an alternative search-like sibling or state explicit exclusion conditions.

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

Install Server