China state-owned enterprise campus recruitment: search jobs, deadlines, official source links.
Scored across 3 tools
search_jobs is the general filtered search, get_job_detail is a specific ID lookup, and list_deadlines is a dedicated time-based view. There is minor overlap between search_jobs and list_deadlines since both surface deadline information, but their intents are distinct enough.
All tool names follow a consistent lowercase snake_case verb_noun pattern: search_jobs, get_job_detail, list_deadlines. This makes the set predictable and easy to navigate.
Three tools is well-scoped for a focused campus-recruitment radar service. Each tool covers a necessary step: finding jobs, viewing details, and checking deadlines.
The core search-to-detail workflow is covered, and deadline-focused discovery is provided. Minor gaps exist, such as no pagination on list_deadlines and no separate detail view for non-job items like events, but agents can typically work around these.
按 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.
列出未来 N 天内截止的招聘项目/岗位（求职最刚需的"倒计时"查询）。
days_within: 往前看几天（默认 7，最大 90） include_events: 是否包含宣讲会信号（默认 False）
| Name | Required | Description | Default |
|---|---|---|---|
| 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 carries the burden. It effectively conveys the core query behavior and documents defaults and the maximum lookahead, but it does not explain ordering, pagination, what qualifies as a deadline, or how event signals are included beyond the toggle.
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 front-loaded, with a one-sentence purpose followed by terse parameter lines. The phrase '求职最刚需的倒计时查询' adds use-case flavor but is slightly promotional rather 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?
For a simple two-parameter list tool with an output schema, the description covers the invocation semantics, defaults, and constraints. It could be more complete about sorting, result limits, or the precise nature of '宣讲会信号', but nothing essential blocks correct invocation.
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%, yet the description documents both parameters with defaults and adds the important max-90 constraint and the meaning of include_events. This fully compensates for the schema's lack of parameter 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?
The description clearly states the tool lists recruitment projects/positions with deadlines within the next N days, which is a specific verb, resource, and temporal scope. It is easy to distinguish from siblings like search_jobs, though it never explicitly names an alternative.
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 use case is implied by the 'countdown query' framing and the days_within parameter, but the description gives no explicit guidance on when to prefer this over search_jobs or get_job_detail, and no when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按条件搜索国央企校招岗位/招聘项目。
参数： city: 工作地点关键词（如 "深圳"、"广东"；为空查全部） major: 专业关键词，对"专业要求原文"做包含匹配（如 "计算机"、"会计"） graduate_year: 届别，如 "2027"（为空查全部） keywords: 对岗位名/单位名做包含匹配 kind: "岗位" | "招聘项目" | "宣讲会"（为空查前两类） only_open: 只返回未截止的（默认 True） limit/offset: 分页（默认每页 20）
返回字段含截止日、截止状态、专业要求原文、原公告链接、数据复核日期。 未写明的条件留空（null），本服务不猜测；重大决策请打开 source_url 核对原文。
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| kind | No | ||
| limit | No | ||
| major | No | ||
| offset | No | ||
| keywords | No | ||
| only_open | No | ||
| graduate_year | 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 carries the full burden, and it delivers: it explains null handling ('未写明的条件留空（null），本服务不猜测'), advises verifying important decisions against source_url, and discloses returned fields such as deadline, status, and data review date. It lacks rate-limit/auth details, but these are less critical for a read/search operation.
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 purpose is front-loaded and the parameter list is compact and structured, with each line carrying operational meaning (defaults, matching behavior, return fields). Slight length is justified by the need to document 8 parameters at 0% schema coverage.
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 an 8-parameter search tool with no annotations, the description covers every parameter, defaults, kind semantics, open-status filtering, return fields, null policy, and source verification guidance. Since an output schema exists, detailed return-value documentation is not required.
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 document all 8 parameters—and it does, with examples (city, major, graduate_year), enum semantics (kind), default behavior (only_open, limit/offset), and matching rules (major matches 专业要求原文, keywords match job/company name). This fully compensates for the bare 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?
States a specific verb ('搜索') and resource ('国央企校招岗位/招聘项目'), with clear condition-based behavior. This naturally distinguishes it from siblings get_job_detail (single job detail) and list_deadlines (deadline-oriented listing).
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?
Implies use when searching or filtering job postings by conditions, and provides rich parameter guidance. However, it does not explicitly say when to use this tool versus get_job_detail or list_deadlines, nor does it state exclusions or alternative routing.
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_job_detaillist_deadlinessearch_jobsFind jobs, improve resumes, prepare for interviews, and manage your application pipeline.
Search job postings aggregated from companies' careers sites, plus each job's discussion thread.
Job search management: applications, interviews, offers, recruiter email, and company openings.
Add one secure layer between your agents and this server.
