Skip to main content
Glama
Sign In
OpenHire — Real Job Postings, Ghost Jobs Scored

OpenHire — Real Job Postings, Ghost Jobs Scored

by gzchenhao
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Refresh one employer

refresh_index

Manually re-crawls one employer's public ATS to get today's job listings when the weekly index lags behind. Use it only when a user is about to act on that specific employer.

Instructions

Re-crawl ONE employer's public ATS now. Takes about a minute. Throttled to 6h.

The index is refreshed weekly, so search_jobs can be up to seven days behind and check_watches has nothing new to report until it moves. This is the manual nudge for the case that matters: the user is about to act on one employer and wants today's truth.

Rules worth knowing before you call it:

  • ONE employer per call. A full crawl is 20+ minutes and no client will wait; a vague word like "robot" is refused with the list of candidates rather than fanned out into eleven live crawls.

  • At most one crawl per employer per 6 hours. A throttled call returns immediately with refreshed: false, reason: "throttled" and last_refreshed_at — no network request is made. That is not an error: it means the data you already hold is that fresh.

  • An employer we know but deliberately do not index (the Feishu-hosted ones, 蔚来 NIO, the ones whose own site has no readable job list, and 毫末智行 which has ceased operations; see search_jobs) returns reason: "known_not_indexed" with the same portal, reason and employer_opt_in the other tools give, never unknown_company.

  • Do NOT call this speculatively or in a loop. Every call hits somebody else's public endpoint. Search first; refresh only when the user needs today's state of one employer.

Args: company: one employer — an id ("unitree") or any part of the name in either language ("宇树", "XPeng"). Ambiguous input is refused, not guessed.

Returns: refreshed plus last_refreshed_at / next_allowed_at; when it did run, also jobs_new / jobs_updated / jobs_delisted / jobs_unchanged, delisted (job_id and title of the rows this crawl took down, first 20), new (the rows it added, first 20), posting_dates_changed (rows whose employer- reported posting date moved since the last crawl, was / now; say so and quote both) and counts_note on what the counts mean.

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": {
      "company": "<company>"
    },
    "name": "refresh_index"
  }
}

Input Schema

NameRequiredDescriptionDefault
companyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.3

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses ~1 minute runtime, a 6-hour per-employer throttle, that throttled calls return immediately with refreshed:false and make no network request, and that this is not an error. It also documents the known_not_indexed path with concrete examples and the employer_opt_in field, and warns that each call hits a third-party public endpoint. This is unusually rich behavioral context for a mutating, open-world tool.

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?

Front-loaded with the core action and timing, then organized into rules, Args, and Returns. Mostly every line earns its place, but the known_not_indexed bullet is dense with case-specific detail (Feishu, 蔚来 NIO, 毫末智行) that lengthens the block without changing how an agent calls the tool.

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?

There is no output schema, and the description compensates fully with a Returns section covering refreshed, last_refreshed_at, next_allowed_at, the job count deltas, delisted/new samples, posting_dates_changed, and counts_note. Combined with the throttle and refusal semantics, nothing an agent needs to call and interpret this correctly is missing.

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 coverage is 0% and the schema is a bare string, so the description carries the full burden — and does: company accepts an id ("unitree") or any part of the name in either language ("宇树", "XPeng"), and ambiguous input is refused rather than guessed. That is meaning the schema cannot convey.

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?

Opens with a specific verb and resource plus scope: "Re-crawl ONE employer's public ATS now." It also differentiates against siblings by naming search_jobs and check_watches and explaining the staleness relationship between them. An agent knows exactly what this does and what it does not do.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ("the user is about to act on one employer and wants today's truth"), explicit when-not ("Do NOT call this speculatively or in a loop. Search first"), and named alternatives (search_jobs, check_watches). The one-employer constraint and the refusal of ambiguous input are also stated as routing rules.

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

Deploy Server

Other Tools