China state-owned enterprise campus recruitment: search jobs, deadlines, official source links.
Scored across 5 tools
search_jobs is the general query tool while get_job_detail, get_stats, and list_deadlines each target a distinct angle (single record, aggregates, deadline window). The main overlap is between list_deadlines and whats_new, since both surface soon-to-expire jobs; descriptions clarify the difference (whats_new bundles new + deadlines, list_deadlines has richer filters), so confusion is limited.
Four of five tools follow a clean verb_noun pattern (get_job_detail, get_stats, list_deadlines, search_jobs). whats_new is the one deviation, breaking the convention with a colloquial 'what's new' style, but overall the set is readable and predictable.
Five tools is well-scoped for a read-only campus recruitment radar: search, record detail, deadline tracking, aggregate stats, and a changelog. Each tool earns its place with no redundancy bloat.
Core lifecycle for a data-browsing service is covered: discovery (search_jobs), detail (get_job_detail), temporal views (list_deadlines, whats_new), and aggregate context (get_stats). No write operations are expected for a radar service, though a company/org-oriented browse or filter-by-employer tool is a minor gap.
按 id 取单条岗位全字段（含岗位介绍/要求原文与原公告链接）。先 search_jobs 拿 id。
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It usefully reveals that the response includes full fields, original requirement text, and the announcement link, and it implies read-only retrieval. It does not explicitly confirm side-effect-freeness, auth requirements, or not-found behavior, which is a minor gap for a simple get-by-id tool.
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 short sentences with no filler. The core operation is front-loaded in the first sentence, and the prerequisite search step is given compactly in the second.
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?
This is low-complexity tool: one parameter, an output schema, and no nested objects. The description covers the return content, the required id, and the prerequisite search_jobs call. It omits error/not-found behavior and the list_deadlines sibling, but those are not essential for this straightforward detail lookup.
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 schema only provides 'job_id: integer' with no description (0% coverage). The description supplies the missing semantic by explaining that the id identifies a single job and is obtained from search_jobs. It does not name the 'job_id' property explicitly, but the schema already exposes that property name.
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?
The description states a specific verb ('取' / fetch by id), the resource ('单条岗位' / single job), and the scope ('全字段', including original job description/requirements and announcement link). It clearly differentiates from search_jobs by framing this as the id-based detail lookup that follows a search.
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 explicitly instructs '先 search_jobs 拿 id', telling the agent to call search_jobs first and then use the returned id here. It gives clear usage context but does not discuss list_deadlines or negative conditions, so it stops short of full when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
数据总览：库容/开放量/企业性质分布/数据源数/近期新增。适合回答"国央企校招现在整体什么情况"。
返回：总量、开放中、按企业性质分布、数据源数、今日新增、近7天新增、数据截至日期。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the return payload (totals, open count, distribution, data source count, recent additions, as-of date) and implies a read-only overview. However, it does not explicitly state read-only behavior, data freshness policy, or definitions of terms like '库容'.
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?
The description is compact and well-structured: the first sentence defines scope and gives a usage example, the second enumerates the return fields. Every sentence adds value and the key purpose is front-loaded.
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?
Given the tool has no parameters, an output schema is present, and the description covers purpose, usage context, and return fields, an agent has everything needed to select and invoke it correctly. No critical information is missing.
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 has zero parameters and the schema is empty, so there is nothing to document. The baseline for 0-parameter tools is 4, and the description appropriately adds no parameter information because none is needed.
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?
The description clearly identifies the tool as a data overview ('数据总览') and enumerates the metrics it covers: capacity, open positions, enterprise-type distribution, data source count, and recent additions. It also states what is returned. It does not explicitly contrast itself with sibling tools, but the aggregate-stats nature is distinguishable from search/detail/deadline tools.
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 description gives a concrete use case: answering questions like '国央企校招现在整体什么情况' (what is the overall situation of state-owned enterprise campus recruitment). This is clear context for when to use the tool, though it does not name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出未来 N 天内截止的招聘项目/岗位（求职最刚需的"倒计时"查询）。
days_within: 往前看几天（默认 7，最大 90） include_events: 是否包含宣讲会信号（默认 False） org_nature: 企业性质筛选（"国央企"=央国企+地方国企+银行，默认；"全部"=不限）
单次最多返回 50 条；total 是窗口内真实总数，truncated=true 说明被截断，可缩小 days_within。
| Name | Required | Description | Default |
|---|---|---|---|
| org_nature | No | 国央企 | |
| days_within | No | ||
| include_events | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It usefully discloses the 50-result cap, that total is the true window count, and that truncated=true signals a cut-off, which is real behavioral context. However it says nothing about read-only semantics, auth/permission needs, rate limits, or latency, leaving the disclosure partially incomplete.
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?
Purpose is front-loaded in the first line, followed by compact per-parameter notes and a closing pagination note. Nothing is wasted, though the parameter lines partially restate schema defaults, making it slightly denser than strictly necessary.
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?
An output schema exists, so return-value explanation is not required, yet the description still covers the pagination contract (50 cap, total, truncated). Combined with complete coverage of all three parameters, the definition is nearly self-sufficient; only sibling routing/usage guidance is missing.
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 0%, so the description must compensate, and it does: it explains days_within (default 7, max 90), include_events (whether to include info-session signals, default False), and — most valuably — the semantics of the org_nature values ('国央企' expands to central SOEs + local SOEs + banks; '全部' means unrestricted), which the schema does not encode as enums or descriptions.
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 with a clear scope: '列出未来 N 天内截止的招聘项目/岗位' (list recruitment projects/positions closing within N days), and frames itself as the countdown query. It is distinguishable from siblings like search_jobs and whats_new by the deadline filter, but it never names those siblings explicitly.
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?
Usage is implied by the framing as the 'most critical countdown query', but there is no explicit when-to-use/when-not guidance or routing to alternatives such as search_jobs or get_stats. The only actionable guidance is the truncation workaround ('可缩小 days_within'), which is about narrowing, not about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按条件搜索国央企校招岗位/招聘项目。
参数： city: 工作地点关键词（如 "深圳"、"广东"；为空查全部）。"雄安"会自动带上容城/安新/雄县。 major: 专业关键词。先匹配"专业要求原文"（major_raw）；原文缺失时在公告正文里找， 所以能覆盖那些只有公告、没拆出专业字段的岗位（如 "计算机"、"会计"） graduate_year: 届别，如 "2027"。严格匹配公告标注的届别——未标注届别的记录不会被返回； 想广撒网就别传这个参数。 keywords: 对岗位名/单位名做包含匹配 kind: "岗位" | "招聘项目" | "宣讲会"（为空查前两类） org_nature: 企业性质筛选。默认 "国央企"（=央国企+地方国企+银行）； 传 "全部" 看所有（含顺带覆盖的民企/事业单位/未知长尾）； 也可精确传：央国企/地方国企/银行/事业单位/民企/外企/未知 employment_type: 批次筛选："校招" | "实习" | "提前批"（为空查全部） only_open: 只返回未截止的（默认 True，按北京日期判断） limit/offset: 分页（默认每页 20，上限 50）
返回字段含截止日、剩余天数、截止状态、专业要求原文、企业性质、原公告链接、数据复核日期。 未写明的条件留空（null），本服务不猜测；重大决策请打开 source_url 核对原文。
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| kind | No | ||
| limit | No | ||
| major | No | ||
| offset | No | ||
| keywords | No | ||
| only_open | No | ||
| org_nature | No | 国央企 | |
| graduate_year | No | ||
| employment_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注解，描述补充了重要行为：only_open 默认 True 按北京日期判断、graduate_year 严格匹配且未标注届别不返回、kind 为空查前两类、org_nature 默认国央企及全部含义、分页上限 50。还说明了返回字段（截止日、剩余天数、来源链接等），透明度较高，但未提及速率限制或权限需求。
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?
采用参数列表结构清晰，关键约束（默认值、枚举）前置。内容较长但每句都有实质信息，无明显冗余。
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?
有输出 schema 但描述仍概括了返回字段（截止日、剩余天数、状态、专业原文、企业性质、公告链接、复核日期），并提示未明字段为 null、需核对原文。对于搜索类工具，参数行为、返回概览、决策提示均已覆盖，完整度高。
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 描述覆盖率为 0%，描述对全部 10 个参数逐一解释，包括枚举取值、默认值、特殊逻辑（如“雄安”自动带容城/安新/雄县、major 匹配原文与公告正文、graduate_year 严格匹配）。补偿充分，远超 schema 提供的信息。
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?
明确说明了动词（搜索）和资源（国央企校招岗位/招聘项目），并限定了目标人群范围。与 get_job_detail（详情）、list_deadlines（截止日）、whats_new（新品）等兄弟工具区分明显，但未直接点名替代工具。
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?
对关键参数给出了使用建议（如只查未截止的用 only_open，想广撒网不传 graduate_year），并提示重大决策需核对原文。但未明确说明何时应改用 get_job_detail 或 list_deadlines 等兄弟工具。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
看动态：最近 N 天新收录的岗位 + 未来 N 天即将截止的岗位（默认各 20 条）。
适合每天问一句"有什么新岗位/快截止的"，也适合生成校招日报。 days: 回看/前看的天数（1-14，默认 3） limit: 每组最多条数（1-50，默认 20）
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the dual-section output, per-section defaults, lookback/lookforward windows, and parameter constraints. Some details like ordering and exact date-boundary semantics are omitted, but nothing is misleading.
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?
Core behavior is front-loaded in the first sentence, use cases follow in the second, and parameter semantics are compressed into two clear lines. Every element earns its place with no redundancy.
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 tool with two optional parameters, an output schema, and no required fields, the description is complete: it covers purpose, usage context, defaults, and constraints. An agent has enough information to select and invoke this tool correctly.
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 input schema provides only types and defaults, with 0% description coverage. The description fully compensates by explaining days as the lookback/lookforward window with range 1-14 and default 3, and limit as the per-group maximum with range 1-50 and default 20.
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?
The description states a concrete action ('看动态') and a clear resource: recently added jobs plus jobs with upcoming deadlines, presented as a combined feed. It implies differentiation from siblings like list_deadlines and search_jobs, but does not explicitly name or contrast them, so it stops short of a 5.
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 explicitly names suitable use cases: daily questions about new/expiring jobs and generating campus-recruitment daily reports. It does not provide exclusion guidance such as 'for deadlines only, use list_deadlines', so no when-not-to-use instruction is present.
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.
get_statssearch_jobs1 field changedInput schema / properties / employment_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}whats_newlist_deadlines1 field changedInput schema / properties / org_natureAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": "国央企"
+}search_jobs1 field changedInput schema / properties / org_natureAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": "国央企"
+}get_job_detaillist_deadlinessearch_jobs中国校园招聘（秋招/春招/实习/提前批）在招岗位、企业档案、投递截止与求职攻略数据。免 API Key、免注册、只读。
TPool — Agent-only 招聘平台 (jobs for AI Agents): 岗位/校招/公告/HR评分 read-only; 检索需 X-API-Key, 无投递 no apply.
Search official job listings at Forbes Global 2000 companies and track new and removed jobs.
Search jobs on verified employer job boards. Every link is the employer's own posting.
Add one secure layer between your agents and this server.
