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

OpenHire — Real Job Postings, Ghost Jobs Scored

Company trust signals

get_company_info
Read-onlyIdempotent

Retrieve aggregate, anonymous employer trust signals—ghost score average, active jobs, hiring trend, and index freshness—to evaluate hiring health without exposing candidate data.

Instructions

Aggregate, anonymous trust signals for one employer.

Returns ghost_score_avg, active_jobs, and index_built_at (when the index was last built). NEVER returns any individual candidate data: the server holds none.

posting_dates_reported is false when no live posting of this employer carries the employer's own posting date (first-party mirrors such as Li Auto report none), and postings_without_reported_date counts those rows; their days_open, and so this employer's median_days_open and ghost_score_avg, are counted from the day this index first saw each posting, a lower bound on age rather than the employer's timeline.

active_jobs and every aggregate count only postings the employer's own system returned within the last 30 days of this index; unverified_over_30d counts the ones it still holds that went unconfirmed longer (most often a careers board that moved). Those are not shown by search_jobs. Nonzero means a gap in our reading, never a fact about the employer.

claimed is true only when the employer has claimed this tenant and we verified them by corporate identity, never by payment, and it never affects ranking. It is the only signal here that comes from the employer rather than from their public ATS data, and it is what makes response_sla_days non-null on their postings.

hiring_trend counts what the employer's own system shows: postings published in the 30 days up to the index's newest verification, the 30 days before, and postings taken down in the last 30, with in_words (zh, en) to quote. Use it when the user is about to sign or bet months on an internship and asks whether the company is growing or shrinking. Report the counts; never turn them into "they are about to lay off" or "safe to join".

Takes an id or any part of the name in either language, like search_jobs' company.

Known-but-not-indexed employers (Momenta, 小马智行 Pony.ai, 智元 AgiBot, MiniMax, 智谱 Zhipu, 商汤 SenseTime, 逐际动力 LimX, 自变量 X Square, 千寻智能 Spirit AI, 加速进化 Booster, 穹彻智能 Noematrix, 众擎 EngineAI) return a structured answer instead of ERR_COMPANY_NOT_FOUND: indexed: false, careers_url (their own portal), reason (their careers site runs on Feishu Recruitment, whose job-list API requires a request signature; we treat that as access control and do not work around it) and employer_opt_in (the employer can authorize the read-only Feishu open-platform scopes hire:site:readonly and hire:site_job_post:readonly). 蔚来 NIO gets the same shape with its own reason: its careers page's security policy blocks this crawler (HTTP 567), which we do not work around. There are no trust signals in that answer because we hold none of their postings; do not read the absence as a verdict on the employer.

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_id": "<company_id>"
    },
    "name": "get_company_info"
  }
}

Input Schema

NameRequiredDescriptionDefault
company_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, but the description adds substantial context beyond that: it explains that no individual candidate data is returned, defines lower-bound age semantics for postings without reported dates, explains what unverified_over_30d means, clarifies that claimed is employer-provided and never affects ranking, and describes the structured fallback response for known-but-not-indexed employers.

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?

The description is front-loaded with purpose and return fields, and each paragraph explains a distinct signal or caveat. It is still quite long for a one-parameter tool, especially the enumerated list of known-but-not-indexed employers, but most of the length earns its place by preventing misinterpretation.

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?

Given that there is no output schema and the input schema has no parameter descriptions, the description carries the full burden and does so thoroughly: it explains the returned fields, the special fallback shape, the meaning of key flags, and how to interpret the counts without overclaiming.

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 single company_id parameter is undocumented in the schema. The description compensates fully by stating that it takes an id or any part of the name in either language, like search_jobs' company parameter.

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 opening sentence states a specific resource and operation: aggregate, anonymous trust signals for one employer. It also explicitly contrasts with search_jobs regarding unverified_over_30d, so the agent can distinguish it from a sibling without opening either 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?

It gives explicit when-to-use guidance for hiring_trend (when the user is about to sign or bet months on an internship and asks whether the company is growing or shrinking), and it clarifies that certain counts are not shown by search_jobs. It does not give a full routing rule for the whole tool versus check_employer or other siblings, but the context is clear.

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